| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
