| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Reviewed-by: Fabien Freling
|
|\ |
|
| |
| |
| |
| |
| | |
Task-number: QTBUG-13714
Reviewed-by: Trust Me
|
|/
|
|
| |
Reviewed-by: Olivier Goffart <olivier.goffart@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Every time [NSApp setMainMenu:] is called, Cocoa will add the 'Special
Characters' item to the 'Edit' menu. Before adding a new entry it will
make sure that menu items list doesn't contain an item with the selector
'orderFrontCharacterPalette' & a 'nil' target. We need to return the
index for the first entry (we have QCocoaMenuLoader as target).
Task-number: QTBUG-12842
Reviewed-by: Denis
|
|
|
|
|
|
| |
Cocoa would not build with namespace. This patch fix makes the day.
Reviewed-by: prasanth
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A behavior change was introduced by the commit
97b8727635a73197fac4f5edb8a1122733933db4. The menu items with menuRoles
will now be translated like Native Mac applications. Translations/merging
of menu items are done as follows:
1) AboutRole ==> "About <Application>"
2) PreferencesRole ==> "Preferences..."
3) QuitRole ==> "Quit <Application>"
Task-number: QTBUG-4463
Reviewed-by: mortens
|
|
|
|
|
|
|
|
|
|
|
| |
The application menu is loaded from the qt_menu.nib which only has
English strings. These will now be translated using Qt's own translation
mechanism. Every time a new translator is installed, the menu will now
try to get the new string. Modification of qt_xx.ts files are done in a
different patch.
Task-number: QTBUG-4463
Reviewed-by: MortenS
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you use the menu bar for a window to open up
another window woth no menu bar, the first menu bar
stays highlighted once it is set as current again.
The reason is that we remove the first menu bar before
cocoa gets a chance to update it correctly. This patch
implements a system for us to post a message/call to
cocoa, so we delay removing the toolbar until after
cocoa has finished closing it properly.
NB: Rather than posting the call to a window on screen, it
would have been better and safer to post it no window, and
then receive the event in the event handler of NSApplication.
But for the moment, we have decided not to subclass NSApplication...
Rev-By:prasanth
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason is that the test first creates a menu bar with an exit item
The exit item gets merged into the appmenu (together with a QAction)
Then we destroy the menu bar, but leave the exit item in the appmenu untouched.
Then we create a new menubar _without_ an exit item
macUpdateMenubar will then, at one point, try to access the old exit item's
QAction, wich is destroyed a long time ago; crash!
This patch will make sure we clear out all actions in the menu bars appmenu
when the menubar gets destroyed.
Reviewed-by: Prasanth
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you have two window, each with its own menu bar that
has a 'Quit' action, we reuse the quit menu item when
switching between the windows. Now, it we deleteLater one of
the menu bars, the new menubar will update the 'Quit' item
just before deleteLater will come along and remote the update
again. This patch will fix this.
Task-number: QTBUG-4684
Reviewed-by: Prasanth
|
|
|
|
|
|
|
|
|
|
| |
The deleteLater was beeing created with loopLevel of 1, causing
it to be defferd until QApplication::exec() returned.
Add a QScopedLoopLevelCounter to increase the loopLevel while
triggering the action.
RevBy: Brad
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
| |
It seems that Vim or Xcode or whatever I was using to paste these
in messed up and added an extra space. Now we should be consistent with
the .cpp files and I found a file that we missed too.
|
|
|