| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
TabletLeaveProximity events
Merge-request: 788
Reviewed-by: Norwegian Rock Cat <qt-info@nokia.com>
|
| |
|
|
|
|
|
|
|
|
| |
Tablet events should set the qt_button_down, otherwise if the tablet
moves onto a widget that does not accept a tablet event, it will set
qt_button_down and effectively "grab" the mouse. However, we should only
do this if we accept the tablet event.
Merge-request: 788
Reviewed-by: Norwegian Rock Cat <qt-info@nokia.com>
|
| |
|
|
|
| |
Merge-request: 788
Reviewed-by: Norwegian Rock Cat <qt-info@nokia.com>
|
| |\
| |
| |
| |
| | |
Conflicts:
src/gui/kernel/qapplication_x11.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
These are used enough (at least on the mac) to justify them being
accessible in a private header. As a bonus it "hides" the actual
container being used, so we could potentially sway it out with something
different.
Reviewed by: Jens Bache-Wiig
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsscene_p.h
|
| | |\ |
|
| | | |
| | |
| | |
| | | |
Reviewed-by: Trust Me
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We've had a problem with a stale cache for color profiles this should
make things work well. We get the callback for each display whether it
needs it or not, but honesly I would rather that we update this a few
times too many when people change their display profile than not at all.
FWIW, this code is inspired from Apple's Tech Note TN2035.
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
external event generators
This introduces QEvent::RawTouch event type, which should be used by the low-level
translator. This raw QTouchEvent can be sent to either QApplication or to a window,
and Qt will do the rest to dispatch the touch points to the correct place.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I'm tired of these "hidden" functions. We have an
AA_MacPluginApplication, but sometimes you may have a legitimate reason
for setting this outside of "plugin applications." In the footsteps of
the menu icon attribute, the attribute is the main leader, but menubars
can disable/enable this locally the new QMenuBar::setNativeMenuBar()
property. Otherwise, the menubars take their que from the application
attribute.
This also works for Windows CE. So, there is a bit on convergence as
well.
Task-number: 236757
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
src/gui/itemviews/qabstractitemview.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In general, Cocoa handles the the Apple Events for us. However, this is
time between creating the NSApplication and Cocoa has set everything up,
usually after the event loop is running. This means that until that
time, the events are dropped on the floor :-/. The workaround is to use
the same handler that we use for Carbon, but to only have it enabled for
until Cocoa is ready to handle things. This will result in not stepping
on the toes when used in a plugin (if it does, we can conditionalize
it).
Task-number: 252795
Reviewed-by: Richard Moe Gustavsen
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Carbon, we did show/hide menubar, on Cocoa we used SetSystemUIMode.
But SetSystemUIMode is available to both, so why not just do that and
make everything consistent. We now act more like other fullscreen apps
(i.e., we show the menu and dock when the mouse is close to them). The
good thing is that it should be easier to override this behavior as
well. I also removed some code in our mouse handler where we were
calling HideMenuBar as I don't see a great reason for it at the moment
in any case, it would be inconsistent between Carbon and Cocoa.
Task-number: 249655
Reviewed-by: Prasanth Ullattil
|
| |
|
