| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Direct Screen Access (DSA) allows a client to request notification
from the window server when drawing is performed by other threads,
into a specified region of the screen. This allows DSA rendering
- for example video - to be suspended when notifications are
drawn, preventing the video content from overwriting the
notification.
If the drawing originates from the same thread as that which holds
the DSA session, DSA must be suspended while drawing takes place.
This change allows a widget to request notification when native
drawing is about to be performed by QSymbianControl::Draw.
Task-number: QTBUG-5467
Reviewed-by: Jason Barron
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On the Symbian platform, the Qt raster paint engine targets an
off-screen buffer owned by the Font & Bitmap server (FBSERV).
When an area of the screen needs to be refreshed, the window
server (WSERV) asks the control environment (CONE) to redraw the
control(s) intersecting that screen region. Each Qt native
widget has an associated Symbian control, whose Draw function
blits the required region of the backing store via WSERV.
Use cases involving Direct Screen Access (DSA) may require this
behaviour to be modified, to either of the following:
- Disable: the Draw function does nothing. In this case,
the output of paint events, rendered to the backing store,
is not blitted to the screen. This mode was introduced by
change 8f445e13.
- Zero fill: the Draw function fills all pixels within the
redraw region with zeroes.
This change allows the widget implementation to select either of
these alternative modes by setting a flag in its QWExtra structure.
Note that these alternative modes are only suitable for native
widgets, because they act on a per-control rather than per-widget
basis.
Task-number: QTBUG-5467
Reviewed-by: Jason Barron
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The window activation hack is not needed anynmore since
AppUi()->RemoveFromStack() ensures the next visible window will get
the keyboard focus.
Hack removal also required change to window title setting logic.
Since window title (and icon) are associated to top-level windows,
the logical place to set them is the same place where active window is
changed i.e. QApplication::setActiveWindow is called.
At the same time also window icon setting from show_sys was move to
focusChanged to make icon/title setting more consistent.
When changing orientation or switching to different statuspane
mode we receive KInternalStatusPaneChange events for each window in
QSymbianControl::HandleResourceChange. When receiving such event
we only need to reset the icon for focused/visible window. If we don't
handle it like this, it might happen that invisible widget added to
control stack resets the global icon/title.
Task-number: QTBUG-5780
Reviewed-by: Axis
|
| |\
| |
| |
| | |
4.6-staging2
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If maximized dialog had minimum size that didn't fully fit to
the screen, it lost its maximized status when orientation was switched,
because of the logic that assumed that if a window is resized, it must
no longer be maximized. Skipped this assumption for cases where resize
occurs because enforcement of the minimum size of the window.
Task-number: QTBUG-4671
Reviewed-by: Janne Anttila
Reviewed-by: Sami Merila
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| | |
The word 'module' was missing.
Reviewed-By: TrustMe
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Docs say: "Note that only visible widgets can grab mouse input.
If isVisible() returns false for a widget, that widget cannot call
grabMouse()."
qwidget_x11.cpp uses the similar condition in grabMouse as symbian
after this commit.
Task-number: QTBUG-5658
Reviewed-by: Jason Barron
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The native FEP handles the 'pencil' key on some platforms by opening an
edit menu on the screen that contains things like 'Insert Symbol' and
'Writing Language' for text input widgets. This was previously not
working in the Qt input method implementation because in order for the
FEP system to open the menu, it must be able to access the menu bar
(CBA). This is done my using the object provider mechanism (MOP) and
an implementation of the MopNext() function was missing. Adding this
and also setting the AppUi as the MOP parent for top level widgets
allowed the FEP framework to find it's way to the menubar and thus
open a menu.
Task-number: QTBUG-5606
Reviewed-by: axis <qt-info@nokia.com>
Reviewed-by: mread <qt-info@nokia.com>
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There were TODOs in code to remove the temporary solution for creating
native CFbsBitmap out of QPixmap. Now when QPixmpa has native backed
and it provides toSymbianCFbsBitmap, it it preferred to use
toSymbianCFbsBitmap since in best case it can only duplicate the bitmap
handle instead of copying the data.
Task-number: QTBUG-4948
Reviewed-by: Jani Hautakangas
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
visible after activating the window.
This change was required in order to be able to run the test case
for the below task; however, it is more generally required. Without
it, the contents of the descendents of this widget will not be
visible, until they are explicitly hidden and then re-shown.
Task-number: QTBUG-4787
Reviewed-by: axis
|
| |
|
|
|
|
|
| |
Since raising toplevel widget nowdays brings the whole app to top,
logically lowering toplevel widget should put the app to background.
Reviewed-by: axis
|
| |
|
|
|
|
|
|
| |
If toplevel window is raised, the whole application is now raised to
foreground.
Task-number: QT-2162
Reviewed-by: axis
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/kernel/qcoreevent.cpp
src/corelib/kernel/qcoreevent.h
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Incorrect optimisation - for popup windows, Qt's focus is moved before
hide_sys is called, resulting in the popup window keeping its elevated
position in the CONE control stack.
This can result in keyboard focus being in an invisible widget in some
conditions - e.g. QTBUG-4733
Task-number: QTBUG-4733
Reviewed-by: axis
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
until control returns to the event loop.
This is necessary because reparenting can be triggered from the context
of a control's event handler. If reparenting causes that control to be
deleted, a crash can result.
Task-number: QTBUG-4664
Reviewed-by: axis
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both reparenting and modification of window flags are done by calling
QWidget::setParent. If either the parent changes, or a non-top-level
widget becomes top-level (as a result of OR-ing Qt::Window into its
window flags), a new native window ID is created for the widget. The
Symbian implementation of setParent_sys had a flaw which manifested
itself in the following situation:
1. We start with a native widget X, and its child Y, which is also
native. There exist parent-child relationships between the associated
CCoeControl instances, and the native windows (represented by RWindow
handles).
2. X gets a new native window created as a result of a call to
setParent.
3. QWidgetPrivate::reparentChildren calls SetParent on Y's control, to
re-establish the parent-child relationship.
The problem is that the window owned by Y's control now has no parent,
so if we try to re-size the widget, the window server panics the client
thread (WSERV-52).
Because Symbian does not allow existing windows to be re-parented, and
nor does it allow a window-owning control to re-create a new window,
the only way to provide Y's window with a parent is to destroy the
control and create a new one, passing in X's new window to the
CCoeControl::CreateWindowL function.
The changes made are as follows:
a) QWidgetPrivate::reparentChildren is therefore modified to call
create_sys, with destroyOldWindow set to true.
b) QWidgetPrivate::create_sys is modified to take account of the value
of this flag in all cases. (Previously it only did so if a new WId was
passed in by the caller).
c) The call to setWinId is delayed until the control and window are
fully initialized. This is to allow us to emit a new event,
WinIdChanged, from setWinId, in order to inform the widget that its
winId has changed.
d) QWidgetPrivate::activateSymbianWindow is modified in order to
support this change of call ordering.
Note that QWidgetPrivate::create_sys requires some re-factoring in
order to remove the redundancy between the top-level and child widget
cases.
Task-number: QTBUG-4664
Reviewed-by: axis
|
| |\
| |
| |
| |
| | |
Conflicts:
src/gui/kernel/qwidget_s60.cpp
|
| | |
| |
| |
| | |
This reverts commit fafd16474aee5bbf47ee37e1ba739f3b3ceb9c33.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
When dialog is shown on top of a top level window,
the focus does not get back to top level window
when dialog is closed. This is a fix for that.
Reviewed-by: Shane Kearns
|
| | |\
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/gui/kernel/qwidget_p.h
src/gui/kernel/qwidget_s60.cpp
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There are really two bugs that are fixed in this commit:
- SetFocus() in Symbian does not automatically clear focus on the
previously focused control, so we have to remember that control and
clear it ourselves.
- Symbian assumes that it is always the control at the top of the
control stack that should have focus, and if this isn't the case,
focus may or may not work depending on whether Symbian has had a
chance to reset the focus or not. Therefore, whenever we change
focus on a control, we have to also readd that control to the top
of the stack, to ensure that it stays focused.
RevBy: Janne Anttila
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit b6377f43410b14125a66ffd02acde69cfb6e455e.
The asynchronous handling caused too many headaches with input
methods, which expect the focus status to be updated immediately.
This may break the test case that was originally fixed by this patch
(I cannot find out which one at the moment), but that will have to be
solved in a different way.
Conflicts:
src/corelib/kernel/qcoreevent.cpp
src/corelib/kernel/qcoreevent.h
src/gui/kernel/qwidget.cpp
src/gui/kernel/qwidget_p.h
src/gui/kernel/qwidget_s60.cpp
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| | |
already-visible widget
If a widget is visible when winId() is called on it, this change means that the newly-created native window will be activated immediately.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
child widget owns a native window
|
| |/
|
|
| |
This reverts commit 9345d47c3945b61a27724508e8b3d0aaf7b57bcf.
|
| |
|
|
|
|
|
|
|
| |
The advanced pointer events are only available on Symbian^3 and higher
so we need to make sure these are protected by an #ifdef. We might have
to re-factor this later into a plugin in order to get this running on
older versions.
Reviewed-by: axis
|
| |
|
|
|
|
|
|
| |
Turning this attribute ends up calling
RWindow::EnabledAdvancedPointers(), which tells Symbian to send us
multiple pointer events with extended info.
Reviewed-by: Jason Barron
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewed-by: Alessandro Portale
Squashed commit of the following:
commit dae5eda6996d48c12c4a5efd3f6042eb293bacbf
Author: Jason Barron <jbarron@trolltech.com>
Date: Fri Sep 18 10:32:26 2009 +0200
Only update soft keys when KEYPAD_NAVIGATION is enabled.
For 4.6, let's just call these functions when keypad navigation is
defined to minimize the impact on other platforms. They should
probably get thier own define some day.
commit 30a730553531f0f138de5eddb30413936a34fa36
Author: Jason Barron <jbarron@trolltech.com>
Date: Fri Sep 18 10:30:23 2009 +0200
Add/remove the menu bar action when menu bar is added/removed.
commit a83343a2870b34c228c8bc5e6274607b0e97baf6
Author: Jason Barron <jbarron@trolltech.com>
Date: Fri Sep 18 10:28:55 2009 +0200
Compile fix for other platforms
commit 39c9e3a0a1d3d62bf6ebd3212cfd2a81b86b9b2a
Author: Jason Barron <jbarron@trolltech.com>
Date: Thu Sep 17 21:37:59 2009 +0200
Fix 'softkeys' example after API re-factoring.
Clean up this example and use the simplified soft key API. Now the
actions are only allocated in the constructor and dynamically updated
by calling addAction and removeAction.
commit 314e45c33f40552db74e61755c2a3b0f8c77a41a
Author: Jason Barron <jbarron@trolltech.com>
Date: Thu Sep 17 21:30:32 2009 +0200
Re-factor and simplify the soft keys API.
Several things here:
- Move all the logic into QSoftKeyManager
- Move the files into 'kernel' since it is not a widget
- Remove QWidget::setSoftKey*(). Use addAction/removeAction instead
- Made soft keys update on focus, window activation, and action
changes.
- Fixed several memory leaks where QAction's were created too often
- QAction ownership pushed out to widget's
- Added Select/Cancel soft keys for comboboxes and menus to be more
consistent to platform look-and-feel.
commit fb4c240d970262e9872dc5737df6808879143c75
Author: Jason Barron <jbarron@trolltech.com>
Date: Mon Sep 7 15:49:31 2009 +0200
Merge the Symbian implementation with the other platforms nativeMenuBar
It seems this has been refactored to share more code across the various
platforms that support native menubars so the Symbian code can be
mostly removed.
commit aa55e4bcd1f009ab35c9519e18aa325fd212dd23
Author: Jason Barron <jbarron@trolltech.com>
Date: Wed Aug 26 17:00:34 2009 +0200
Change filenames and move softkey stuff from 'widgets' to 'kernel'.
This thing isn't a widget and therefore should not be in the 'widgets'
subdirectory of gui. Also rename the files in preparation for
refactoring and extending.
|
| |
|
|
|
|
|
| |
Added some missing #ifdef QT_NO_CURSOR, so the symbian port still
compiles if this feature is configured out.
Reviewed-by: Jason Barron
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewed-By: Jason Barron
Reviewed-By: Alessandro Portale
Summary:
QT_NO_CURSOR is now not defined for symbian builds
Existing QCursor APIs are all supported
New public API, QApplication::setNavigationMode, to allow the navigation
mode to be set. I.E. on an S60 3.2 phone, some applications will want a
virtual mouse cursor (web browser), while others are designed for keypad
navigation.
Symbian HAL is used for detecting input capabilities.
Fix DND, code cleanup & comment
QCursor visibility now uses a refcount, and is called from DND and the
setNavigationMode so they are both simpler and don't interfere with each
other.
QApplication::setNavigationMode
New public API for configuring cursor/keypad navi style.
This links in with ongoing work on the 4-way keypad navi branch, but
2-way and 4-way modes both act as 2-way mode until that is integrated
Some of the demos/examples have cursor switched on (those that were not
usable with keypad)
Virtual mouse support for non touch, non mouse phones (tested on N78)
add *.d and .metadata (carbide debug file / workspace dir) to .gitignore
System pointers are unavailable when using sprite workaround, so the
system cursor shapes are compiled into qtgui as resources.
MAC port does this also for shapes that aren't standard on the MAC.
Refactor Drag'n'Drop to use QCursor
Add test case to check all system cursor shapes
Simply a mainwindow containing a label widget for each cursor shape,
with the cursor property set appropriately
QCursor(QBitmap,QBitmap) supported
Fixed problem with the image & mask being inverted when using the
QCursor constructor that takes two mono bitmaps.
add .make.cache files to .gitignore
Correct implementation of QApplication::setOverrideCursor
QApplication::restoreOverrideCursor and QApplication::setOverrideCursor
are now working correctly on Symbian platform.
Performance will be slower compared with other platforms, because the
Symbian window server has a cursor associated with each native window.
Add test case for custom cursors
Create a pixmap cursor and associate it with a widget.
No changes to production code, since test passed 1st time ;)
Add manual test for QCursor
Make cursor independent of construction order
Updated to work around window server issue where contruction order
affects what cursor is displayed in child windows.
Also changed to effectiveWinId following review comments
Also fixed a problem which would make qcursor not link if configured
with QT_NO_CURSOR
Moved some multiply declared extern functions from cpp to _p.h files
Implemented Symbian versions of the cursor functions.
Merged in work I'd done based on tower.
Fill in bits of stub functions based on windows port
Removed QT_NO_CURSOR from list of config options forced on symbian
Recompiled configure.exe
Added stub functions for the missing functions in s60 port
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
activeWindow documentation says: "active window is a visible
top-level window that has the keyboard input focus" and "If you want to
ensure that the window is stacked on top as well you should also call
raise(). Note that the window must be visible, otherwise activateWindow
has no effect."
What we were doing earlier was basically raise. Now we just set the
keyboard focus to underlying native window.
Task-number: 260685
Reviewed-by: Jason Barron
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit calling setWindowState(Qt::WindowFullScreen) on
a widget instance affected all new widget instances created after this
method.
This bug happened due to fact that window decorations i.e. statuspane
and softkeys visibility was only changed when switching to or from
fullscreen state. In the reported bug it happened that second widget
was initially in Qt::WindowNoState and it was changed to Maximized.
Since window decorations are global not window specific at the moment,
the default decoration visibility for second window is the one to which
previous window has set them. In this case previous window was in
fullscreen and that's why the decorations were visible also for
second maximized window.
Probably the right fix would be to change the decoration to window
specific but that is quite a big change and for now the bug is fixed
with this commit.
Autotest: Excluding new test case, same results before and after.
Task-number: 261048
Reviewed-by: Jason Barron
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This way we avoid having a lot of code in a static (and
unmaintainable) library. The s60main static library now currently has
only one task: to call main().
To move the initialization into QtGui also meant a change in how the
S60 framework is created, because we can no longer use the trick
where we create and start the the S60 event loop and then have the
framework call us back to start main(). The initialization now
follows the creation and destruction of QApplication, which is a lot
more in line with how other platforms do it.
Since S60 doesn't support creating the environment, and *then*
starting it (both are executed by the same call), we had to open up
the S60 framework construction classes and just mirror what they do.
This means that after QApplication construction is done, the S60
framework is initialized, but nothing will run yet and control will
return to main(), where the user can start the event loop himself.
One of the quirks of this approach is that the construction of the
S60 framework makes a new cleanup stack. This means that any active
traps will not be active anymore, and leaving without setting a new
trap will most likely panic. This shouldn't be a problem for us,
since Qt is never supposed to leave, but it means that if anyone uses
the cleanup stack without setting a new trap, they will receive a
panic.
It was considered to add a trap mark in QApplication construction and
then removing it on destruction, but it was dropped because leaving
from main() is still undefined (even if the old cleanup stack would
be restored in the destructor, we wouldn't be able to stop the
exception from unwinding the stack, and the cleanup stack would then
be unbalanced).
RevBy: Jason Barron
RevBy: Janne Anttila
AutoTest: QWidget passed with same failure count
|
| |/
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
RevBy: Trust me
|
| |
|
|
| |
due to http://qt-reviews.europe.nokia.com/r/67/
|
| |\
| |
| |
| |
| | |
Conflicts fixed:
src/corelib/io/qdiriterator.cpp
|
| | |
| |
| |
| | |
RevBy: Trust me
|
| | |
| |
| |
| | |
RevBy: Trust me
|
| |/ |
|
| |\ |
|
| | | |
|
