Under gtk/gtk3 we send CommandEventId::ModKeyChange on
key down, to support the auto-accelerator feature. But
at least the handler in SwEditWin::Command must get it
on key up, in order to not interfere with other
ctrl+shift+X shortcuts, which work on key down.
To achieve that, we need:
- On key up pass the key that was just released, instead
of the current state of nothing being pressed.
- Have a flag of whether it's a key down or up event, so
it can be checked by the application code.
Change-Id: If188d6ccdc3b214a2c3ed20aad291d74d46b358f
Reviewed-on: https://gerrit.libreoffice.org/37275
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
The rare crashes in MenuFloatingWindow::ImplGetStartY() and
MenuFloatingWindow::ImplScroll(bool) likely happen because
of a disposed Menu.
Let's guard against invalid accesses.
Change-Id: Ie31240abbc48c06edd40d0a95f319725cdb3db16
Reviewed-on: https://gerrit.libreoffice.org/36026
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Mostly generated using
make check COMPILER_EXTERNAL_TOOL=1 CCACHE_PREFIX=clang-rename-wrapper RENAME_ARGS="-qualified-name=Rectangle -new-name=tools::Rectangle"
Except some modules have their own foo::tools namespace, so there have
to use ::tools::Rectangle. This commit just moves the class from the
global namespace, it does not update pre/postwin.h yet.
Change-Id: I42b2de3c6f769fcf28cfe086f98eb31e42a305f2
Reviewed-on: https://gerrit.libreoffice.org/35923
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
because now it tracks the global menu too, but all we need
here is to hide the in-window menubar widget.
Change-Id: Ic3c8c20b88d37430e80b682333ca384bccc3f697
... if that toolbox is in popup mode (e.g. shapes toolbar
dropdowns, or the toolbar overflow floater). Same behavior
was introduced for non menu based dropdowns in
81d4fbc0da ("tdf#42029 Use a
floating toolbar to show clipped items"), and is similar
to what we had already in ToolBox::Select, i.e. when the
user made a selection, the floating windows should close.
This must be done before executing the menu selection
handler, because such handler might execute stuff
synchronously (e.g. MenuBarManager::Select), and if it
will open a modal dialog, the floating toolbox will stay
visible after the dialog shows.
Change-Id: Ie93e71fa4dea80ba444aebccacf6adb926a39224
The change in PopupMenu::ImplExecute is needed because
MenuBarManager dispatches commands synchronously, and a
command can try to dispose the parent window of the
MenuFloatingWindow (e.g. right clicking inside the report
header, and choosing "Delete Header"), which will lead to
Application::Abort in a debug build. So we must get rid of
the MenuFloatingWindow before handling menu selection.
Change-Id: I1657cd16a005207abc31f4b65595ab78ed235e37
Reviewed-on: https://gerrit.libreoffice.org/34407
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
so no Invalidate will be called if auto accelerators are not enabled
so there should be no blinking under windows
Change-Id: Iccc5dad7af41f39ac02d3be93e935f2d926a82a6
This reverts the following commits:
commit 722f4e1d86
tdf#104573 - Assertion failed: SolarMutex not locked
commit f04ec99f5e
tdf#104573 - Assertion failed: SolarMutex not locked
commit 71b1e3ff63
tdf#104573 - Assertion failed: SolarMutex not locked when trying
commit e794ce1eef
verify that we hold the SolarMutex when ref-counting VclPtr
IRC discussion:
<noelgrandin> sberg, maybe I should revert this whole "VclPtr assert" series, I don't have mental bandwidth to sort this out properly now
<sberg> noelgrandin, what I fear is that you'll end up adding lots of SolarMutex locks to small places, where the proper fix would be to add it further out; and once such a dreaded recursive SolarMutex lock is in place (but needlessly so, once the proper fix is done), it's hard to clean that up again
<noelgrandin> sberg, yeah, in that case I'll just remove all of this, leave it for another day
Change-Id: Ie4f84b72b79a1b7e80164b5c7693af398c2c569a
Reviewed-on: https://gerrit.libreoffice.org/31946
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Inspired by a recent bug report where we were assigning the result
of VclPtr<T>::Create to a raw pointer.
As a consequence, we also need to change various methods that were
returning newly created Window subclasses via raw pointer, to
instead return those via VclPtr
Change-Id: I8118e0195a5b2b4780e646cfb0e151692e54ae2b
Reviewed-on: https://gerrit.libreoffice.org/31318
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
this is exposed through uno however, so move it into VCLXMenu to continue to
support it doing nothing of great value there
Change-Id: I6888e61cbec85faa2d1fcca8731ab42023e594c6
This adds support for 32 pixel icons - mainly to get them into
the toolbar.
Most changes made are to change the behavior of having only small
and large icons as a boolean choice, but not every code path was
converted to non-boolean choice yet.
Breeze icon theme has the 32px variants so it can be used already.
Change-Id: Iadf832a87826c16b3a83522104dd6c35d61a0f87
Reviewed-on: https://gerrit.libreoffice.org/30398
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
(I'm not sure about how good are the changes from ScopedVclPtr
to non-scoped, and disposeAndClear to clear. They aren't really
needed, because of the VclReferenceBase::mbDisposed logic. But
at least they should be safe, as long as we have disposeOnce
calls in Menu's dtor.)
See also previous commits:
4433d95b37
("MenuItemData now properly disposes the submenu")
89c23b4aae
("Sub menus no longer need manual disposing")
Change-Id: I9d455a94590f5eec9b097947f6984f1b3e477b52
We don't need to scale images for HiDPI mode anymore - this is now
done automatically when the image is loaded.
Change-Id: Ie285cf4d672f4c098a468d3f7560ee2700365b92
Reviewed-on: https://gerrit.libreoffice.org/30340
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
...which was introduced with 3ead3ad52f "Gradually
typed Link" to distinguish the new, typed versions from the old, untyped ones,
but is no longer necessary since 382eb1a23c
"remove untyped Link<>" removed the old versions.
Change-Id: I494025df486a16a45861fcd8192dfe0275b1103c
the problem being that the attempt to restore the focus in the document in the
floatingwindow tear down is blocked because the menus have set that window as
modal so the focus isn't set.
The attempt to set the focus in the floatingwindow teardown causes the
SavedFocus in the menufloatingwindow to be dropped, so the extra layer of code
to restore focus after modality is removed doesn't do anything
this is fallout from...
commit dd46727b99
Author: Caolán McNamara <caolanm@redhat.com>
Date: Tue Apr 5 15:27:38 2016 +0100
Resolves: tdf#87120 no keyboard navigation inside floating windows
which allows the focus to "truly" enter the menus, triggering the
floatingwindow attempt, which fails but blocks the menufloatingwindow attempt
easiest thing seems to make the restoring modality, and then restore focus,
something that MenuFloatingWindow does before it finishes
Change-Id: I97a4ac71419dcb04709e4667586d8343e89ddbeb
KDE theme engines can explicitly support rollover menubars via
styleHint( QStyle::SH_MenuBar_MouseTracking ).
So this adds support for this feature to the vcl::Menu.
Change-Id: Ica923ff2d06cfd54e548ba858b3d90f70d9c255a
some places are marked with "dodgy"- need to check those to see
what is going on, because they are leaving dangling pointers behind
in the Menu class
Change-Id: I41d5c7c0fec2f70ce9e3ffdc48cd03d26c0a869b
Reviewed-on: https://gerrit.libreoffice.org/26516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
