| Age | Commit message (Collapse) | Author |
|---|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: If18c80fc64e55d797953e24e40e5d5e62bd9c625
Reviewed-on: https://gerrit.libreoffice.org/63453
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
These are all the cases where the warning doesn't suggest a direct replacement,
so the existing code is just wrapped in SAL_WNODEPRECATED_PUSH/POP for now. A
companion commit will cover cases where there is a direct replacement that can
probably be applied (even backwards-compatibly with our current baseline,
hopefully).
Change-Id: I899537cb36dd69e08b5442ad4af7ce69ce2ddaec
Reviewed-on: https://gerrit.libreoffice.org/61354
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I4382a45dcffb32c7c001ee722ac1deccb2b01c2d
|
|
Change-Id: Icda66259acf54e6771b926ce9d329287bd610e82
|
|
Change-Id: I925879cf8df630e4e20773c363b9a27a572f3093
|
|
...for now
Change-Id: I64a0a8f6a006d75b6f82d7aae570aef414984a78
|
|
... if based on MenuBarManager, because unlike context
menus, we reuse the same menu instead of creating from
scratch each time, so that it suffers from the same
"double activation" problem as in tdf#97665.
Note that for GtkSalMenu the problem is only for the
top level popup menu, as the Deactivate callback is
properly called when sub menus are closed.
The non-native case also had this problem, but only when
closing the menu by selecting one of its items, and was
fixed already in b41deb2ef057c3bd43fa61448bb4d7299138c8d4.
Change-Id: Iee037f7baba0f80c32fb3a45f16511f8585c203e
|
|
..."tdf#97527 - vcl: reference-count Menu"
Change-Id: I47457205ae99025d2ca13965dcf2fac79962124a
|
|
Change-Id: I4e605e7acfe9d4fe409d32f20880b4c0e85a0ea7
|
|
... because they are also used internally by vcl controls,
so we want let those controls handle them when they are
focused.
[VCL_NSApplication sendEvent] is more natural place for
this probably, but doing it there we'll lose the "blinking"
effect of the menu bar, even when the focus is in the
document area. So try harder, and handle it inside the menu
code. If this will create any trouble, we can always switch
to the simpler solution.
Change-Id: I827ab0585aabe1ed53fc31c5b8e1dddadef3361d
|
|
... with how framework::MenuBarManager works, following my
work of converting context menus to use it instead of
SfxPopupMenuManager (see tdf#93837).
MenuBarManager sets menu item properties/select handler
when the menu activates - in MenuBarManager::Activate, but
it was never called for submenus. The solution is to adapt
the menuNeedsUpdate delegate to call Menu::Activate.
This makes submenu items work, but doesn't update their
visual state (e.g. title). The reason is that
AquaSalMenu::ShowNativePopupMenu is creating a copy of the
NSMenu, so AquaSalMenu::SetItemText is modifying the wrong
NSMenu instance.
Another problem is that AquaSalMenu::ShowNativePopupMenu
tries to removes (via removeUnusedItemsRunner function)
all disabled items, but the correct state is set by
MenuBarManager only when the menu activates. So we must
handle disabled items only after MenuBarManager::Activate
did its job.
Turns out that we can just hide items in NSMenu instead
of removing them, so no need to clone the NSMenu anymore.
Change-Id: If0785b7f9d5f0ad98ced23585379039a51dc13bf
Reviewed-on: https://gerrit.libreoffice.org/21374
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
Tested-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: I90a955eb3e485723bb81e7164edcf60f7b0e94c7
|
|
Change-Id: I81990df584255f4a286cd078bcf15917c00ad504
Reviewed-on: https://gerrit.libreoffice.org/17687
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
(cherry picked from commit a8c471a7003fdac7d5e1c97e903f669da6bcf0c7)
Conflicts:
vcl/osx/salframe.cxx
vcl/osx/salframeview.mm
vcl/osx/salnsmenu.mm
vcl/osx/salobj.cxx
Change-Id: I379d80355d741dd28aad2e6119a8b82ac10159f5
|
|
Now with the ATSUI code gone is a good time for some
re-organisation. Get rid of "aqua" in file names and the separate
"coretext" folders. CoreText is all we use now for OS X (and has
always been so for iOS), so no need for a "coretext" folder, we can
keep the CoreText-using code under "quartz". Keep OS X -specific code
in "osx". Ditto for headers.
Keep "Aqua" as part of class names for now, though.
This is also preparation for planned further unification between OS X
and iOS code.
Change-Id: Ic60bd73fea4ab98183e7c8a09c7d3f66b9a34223
|
