| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\ |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
| |
Contains some smaller fixes and renaming of macros. Looks big,
but isn't scary at all ;)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Task: 249995
The window title in S60 is global entity, i.e. is located in application
status pane. When top level window, for example mesage box is closed,
the window title has to be restored for window which is getting the focus.
This way we don't leave title from destroyed window to title bar.
It is also into question, whether the non-maximized dialogs should set
title to statuspane at all. For now they will, but things may change if
we switch to use native dialogs.
|
| |
|
|
|
|
|
|
|
|
| |
This code was inialy added before we had s60main. Since that time we
did not had S60 application framework classes constructed we had to
associate application UID to wserv manually to get fast swap window (FSW)
working correctly.
Now application frameworks take care of associating the UID to wserv
window group.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Task: 258504
This commit fixes the problem that background widgets do not get
orientation change events, and thus will not be correctly layouted after
the foreground windget is closed.
See also: c17c1c101cbe09d4c6149ef8e76a9bb792222456
At the time when commit c17c1c101cbe09d4c6149ef8e76a9bb792222456 was
created there were no SetFocus calls in hide_sys and show_sys.
I think that has been the root cause why focus change event has not
been generated. I.e. hiding a CCoeControl in Symbian (MakeVisible)
does not generate focus event but setFocus(false/true) generates.
I tried this code with Drilldown example. In city detaisl view the
combobox was working fine with keypad navigation.
The change had no effects to qcombobox autotest results and qwidget
autotest resutls were better on some run and a bit worse on some run.
There was variation in 2-4 qwidget autotest results on each run.
Note also that screensaver seems to affect to test results.
|
| |
|
|
|
|
|
|
|
| |
Task: 258582
All S60 versions does not have context pane in status bar area, that's
why the window icon was not shown on those devices. Fortunately there
was another API (CAknTitlePane::SetSmallPicture) whicch can be used to
put graphics next to title.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is more a cleanup of the usage of Q_WS_S60 vs. Q_OS_SYMBIAN than
anything else. One of the side effects of this work was that it was
relatively little work to get QtGui compiling when Q_WS_S60 is not
defined.
Based on this we introduce two new configure options that control S60
integration. Currently the -no-s60 option will not work entirely
because the 's60main' module has not yet been refactored and still has
a dependancy on the S60 libraries.
Reviewed-by: axis <qt-info@nokia.com>
|
| |\
| |
| |
| |
| | |
Conflicts:
src/gui/kernel/qkeysequence.cpp
|
| | |
| |
| |
| |
| | |
It's probably not complete, and most of them were found by trial and
error, so feel free to fix any issues.
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/kernel/qcoreevent.cpp
src/corelib/tools/qdumper.cpp
src/gui/kernel/qwidget.cpp
src/gui/kernel/qwidget_p.h
src/gui/kernel/qwidget_s60.cpp
src/gui/text/qfontdatabase.cpp
src/network/access/qnetworkreplyimpl.cpp
src/sql/drivers/ibase/qsql_ibase.cpp
src/testlib/qtestcase.cpp
src/testlib/testlib.pro
tests/auto/network-settings.h
tests/auto/q3sqlcursor/tst_q3sqlcursor.cpp
tests/auto/qobjectrace/tst_qobjectrace.cpp
tests/auto/qsqldatabase/tst_qsqldatabase.cpp
tools/configure/configureapp.cpp
translations/qt_ru.ts
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was done in order to be more in line with what other platforms
(at least X11) do. In addition, it prevents show() from entering
event handlers in Qt. That should only happen in processEvents().
This required the introduction of a new event,
SymbianDeferredFocusChanged, which we post whenever there is a focus
change.
RevBy: Jason Barron
AutoTest: Passed
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
configure.exe
src/network/access/qhttpnetworkconnection_p.h
tests/auto/qstyle/qstyle.pro
tests/auto/qstyle/tst_qstyle.cpp
tools/configure/configureapp.cpp
configure.exe will be recompiled in next commit. Took ours.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Argh! It's divide by 256 not 265. The worst part was that I used the
same values in Cocoa as well, so they were both "damaged." It should be
good now.
Task-number: 257499
Reviewed-by: Prasanth Ullattil
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
OK. this is a bit strange. It seems the topdata->resizer value is used
to control whether or not we should show a resize handle based on a
count (0 no, non-zero yes). Since we somehow decided that this value
will never be larger than 15, we made it 4-bits wide. There's a "Qt/Mac"
API, QWidgetPrivate::qt_mac_update_sizer(QWidget *, int = 0) which
would adjust this value by the int passed in.. We use that in several places, not excluding
the QStatusBar where we would pass 1 if we want to show, and -1 if we
didn't. Now if you subtract -1 from zero when you are 4 bits wide, well,
bad things happen. Therefore protect that (since if it's at zero we have
succeeded, we don't want to show the resizer). This seems to work well.
The private API is certainly an interesting way of solving the problem,
but is easy to abuse (for example, this code will break if resizer = 1
and we are passed -2 in the function.
Task-number: 257485
Reviewed-by: Prasanth Ullattil
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Seems this was a victim of our cursor fixing. Cocoa does a lot for us
with setting cursors. This meant that we didn't need to do as much
meddling and as a result qt_mac_set_cursor does nothing in Cocoa.
Unfortunately, this broke setOverrideCursor. Luckily Cocoa has a stack
that works exactly like Qt, so we can just use that.
Task-number: 257507
Reviewed-by: Prasanth Ullattil
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
After we implemented hitTest for QCocoaView, this function is no longer
used.
Reviewed-by: Norwegian Rock Cat
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Drag and drop events should consider the WA_TransparentForMouseEvents
attribute like the mouse events. If this attribute is set for a widget,
the event has to be passed to right widget under mouse. The widget is
identified by calling hitTest. In such cases the leave event has to be
delivered to the widget which actually accepted the enter event.
Task-number: 252088
Reviewed-by: Norwegian Rock Cat
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Cocoa calls hitTest on our view to determine if
the view should get the mouse press. We always
said, "yes" and did all the logic ourselves. Turns
out that we can say "no" if I'm transparent to
mouse events and remove all that code where we do
all the work ourselves. Big maintenance win!
For the time being I've kept the
"transparentViewForEvent" method since it might be
useful for others, but no one is using it at the
moment and we may just kill it soon. HitTest should
handle this situation correctly.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Tracking of mouse events was only enabled when enableMouseTracking or
Hover or a tooltip had been set explictly on the item, but this meant
that the dynamic QEvent::Tooltips would never get dispatched. So, in
order to help out people that might use this feature, all QCocoaViews
must pay the mouse move event tax *sigh*.
I added comments in the proper places so that we DO the right thing for
a release where we can force the change in behavior.
Task-number: 257320
Reviewed-by: Denis
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There was a bug in the Carbon code when an item went in full-screen,
than out with a unified toolbar. In those cases the toolbars would end
up getting but into the mainwindow area. The reason this was happening
was that we were calling transferChildren() after we had set up our
toolbar. This cause problems because we end up pulling the QToolbars
right out of the unified toolbar. The easiest way to solve this is to
just update the status on it again. This should solve any issues. I also
added some logic to avoid calling this too many times in that one case.
Luckily, this seems to only affect Carbon.
Task-number: 254462
Reviewed-by: Jens Bache-Wiig
|
| | | |
| | |
| | |
| | |
| | | |
Task-number: 256818
Reviewed-by: Trenton Schulz
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The windowDidResize notification now differentiates an internally
triggered resize from a user triggered resize.
Task-number: 256269
Reviewed-by: Norwegian Rock Cat
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Frameless windows wouldn't get shadows in Cocoa, which they do in
Carbon. You can argue over who is more correct, but the fact is they
can't be inconsistent. Since Cocoa is the newcomer, I'm bending that.
Though it would seem useful to have an ability to provide some developer
control over the shadow. At the moment, the only thing we have to ensure
is that we always turn on the shadow.
Task-number: 254725
Reviewed-by: Denis
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This saves memory and prevents warnings from RVCT.
|
| | | | |
|
| | | | |
|
| | |\ \
| | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
.gitignore
src/gui/dialogs/qfiledialog_p.h
src/gui/painting/qpaintengine_raster.cpp
src/gui/text/qfontdatabase.cpp
tests/auto/network-settings.h
tests/auto/qitemdelegate/tst_qitemdelegate.cpp
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Need these symbols for linking QtGui.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
.gitignore
configure.exe
src/corelib/concurrent/qtconcurrentthreadengine.h
src/corelib/global/qnamespace.h
src/gui/graphicsview/qgraphicssceneevent.h
src/gui/kernel/qapplication.cpp
src/gui/kernel/qapplication.h
src/gui/kernel/qapplication_p.h
src/gui/kernel/qapplication_qws.cpp
src/gui/kernel/qwidget.h
src/gui/painting/qpaintengine_raster.cpp
src/gui/text/qfontdatabase.cpp
src/network/access/qnetworkaccesshttpbackend.cpp
tests/auto/network-settings.h
tests/auto/qscriptjstestsuite/qscriptjstestsuite.pro
tests/auto/qvariant/tst_qvariant.cpp
|
| | | | |
| | | |
| | | |
| | | | |
On some systems, math.h still doesn't define M_PI.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Commercial license headers belong in source packages only. The repo
must have the pre-release license headers.
Reviewed-by: Trust Me
|
| | | | |
| | | |
| | | |
| | | | |
Reviewed-by: Trust Me
|
| | |\ \ \
| | | |/
| | |/| |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is mainly a stop-gap solution for 4.5.x. It trades painting performance
for correct painting.
Commit 7988d05da changed the opaque test from q->testAttribute(Qt::WA_OpaquePaintEvent)
to qt_widget_private(w)->isOpaque in qt_mac_update_widget_posisiton. This means
we'll do optimized moves in more cases. Unfortunately it also causes painting errors
in some cases (see the task).
Revert the commit for now to put the 4.5 branch in a god shape.
Task-number: 252295
Reviewed-by: nrc
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Fixes error:
src/gui/kernel/qevent_p.h:62: error: invalid use of incomplete type ‘struct QKeyEvent’
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Replace the SIZE constant with an Enum with a Qt-ish CamelCased name
(since SIZE conflicts with the system headers).
Reviewed-by: TrustMe
|
| | | | |
| | | |
| | | |
| | | | |
We don't want to pull in too much if we can avoid it.
|
| | |\ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This significantly improves the support for
higher DPI-values on these platforms by
ensuring that common pixelmetrics are
scaled accordingly. In addition we mark all
Qt apps as DPI-aware on Windows 7 by calling
SetProcessDPIAware. We also changed the
way we draw pixmaps on the mac paintengine
when using dpi scaling > 1 to ensure smooth
pixmap scaling.
Reviewed-by: nrc
Task-id: 242417
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
10.6 does a lot of image synthesis for us when we put up a tiff, which
is great because we don't have to do a thing and it will work with all
the applications out there. This means we don't need our PICT convertor
on 10.6 for 32-bit apps. However, this magic doesn't exist in earlier
versions of Mac OS X, so we have to keep it around (along with the
QuickTime symbol resolving) there.
Reviewed-by: Morten Sørvig
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
WM_NCHITTEST has to return the location type based on the position,
instead of returning just true or false.
Reviewed-by: Marius Storm-Olsen
|
| | |\ \ \ \
| | |/ / /
| | | | |
| | | | |
| | | | | |
Conflicts:
src/gui/kernel/qapplication_x11.cpp
|
