This reverts the previous attempt of commit
250ad9311a ("tdf#115227 svtools:
suppress UNO notifications for color selectors"), in favor of
a different fix. The advantage of this new approach is that
is doesn't affect events other than activate/deativate, and that
it covers more cases: Toolbar popups even if not based on
svtools::ToolbarPopup, or if closed by clicking outside them,
font name/size and paragraph style toolbar controls, notebookbar,
context and main menus (for the non gtk3 native case, the gtk3
native menus left for a future investigation). For now, keep this
logic inside toolkit, but ideally it should be in vcl (after
reviewing vcl internal listeners).
One side effect that I noticed after this change, is that there is
a deactivation/activation pair which suppressed when e.g. opening a
new document from the start center. But I'm not sure if that's a
problem, given that the focus state of the top window as a whole
wasn't changed, only its contents, and there are other APIs to track
activation of document components. This happens because the source
and the target windows of those events are the same, and we need to
suppress this case to fix the font name/size style controls, and also
the color picker after 27473d1c0f
("tdf#114935 Move the focus back to the document"). Otherwise we'll
need to find another way to move the focus to the document w/o
triggering listeners.
Another case that will see a change in behavior, is document event
listeners in dbaccess, as the Focus/UnFocus events there are based
on top window activation/deactivation. However, I think it's a good
change, as currently just opening of a toolbar popup or main/context
menus there triggers those document events, making them useless.
I would like to also mention here, that in fact those top window
activation events never really worked as tdf#115227 expects them, as
the superfluous events for at least the font name/size, style and
color toolbar buttons existed already in OOo. The behavior of the
color buttons changed in LO for a few years, but regressed again in
the work on a real focus grabbing for floating windows starting with
commit dd46727b99 ("Resolves; tdf#87120
no keyboard navigation inside floating windows"). That work also
introduced superfluous events when using menus.
And a note about the change in menubarwindow.cxx: When a menubar
popup is closed it's deleted using the lazydelete mechanism, which
reparents the popup window, so it doesn't appear anymore in the
hierarchy of the document window. Moreover, I suspect that at some
point the lazydelete thing will be replaced by a VclPtr mechanism,
which might break this even further, so the event won't appear as
coming from the popup window (which might be already disposed at
this stage). So instead, temporarily set the menubar window as the
current focus window, so the activation will appear as if it was
coming from the menu bar window itself.
Change-Id: I292232adfcbd1a31d66ce394cd2f1bf42a013ecb
Reviewed-on: https://gerrit.libreoffice.org/48746
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
Tested-by: Jenkins <ci@libreoffice.org>
This is nominally a regression from commit
43bc303148 (unify color selectors,
2016-10-28), but that just changed the Writer color picker to behave the
same way as the Impress one.
The Impress one started to emit these events with
daeed90f45 (re-base on ALv2 code.
Includes:, 2012-11-15), to fix i#118707, improving accessibility.
That means either the focus changes and then accessibility is happy or
the focus does not change and then the UNO API client only gets events
when the user actually switches to an other window.
Fix the problem with suppressing UNO-level notifications for the
problematic events, by moving the existing VclListenerLock to a public
header and using it at two more places in svtools.
This should address not just color selectors, but in general other
toolbar menus / popup windows.
Change-Id: If427708c5b9fe4fa49cb8f00ec04b32cb28eb391
Reviewed-on: https://gerrit.libreoffice.org/48570
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
I can only imagine the weird bugs that must have periodically resulted
when we had a hash value collision.
In the process, fix hasElements() to return a useful value
Change-Id: I1d9a052e73332b4b2bbc9c1fd8142c13eb22f1be
Reviewed-on: https://gerrit.libreoffice.org/40226
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
...from function definitions occurring within class definitions. Done with
a rewriting Clang plugin (to be pushed later).
Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8
Reviewed-on: https://gerrit.libreoffice.org/34874
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit e387b69967.
It breaks toolkit.subsequentcheck with
propertyChangeListener wasn´t called for ´TypedItemList´
Back to the drawing board for the twisted property logic of forms and
toolkit uno control models.
This adds a menu button that can use a popup menu controller
to manage its menu. It supports 2 cases:
- Use any controller that is registered in Controller.xcu,
by specifing its .uno command.
- Manage an arbitrary popup menu with MenuBarManager
(assuming its items have proper .uno commands in their
MenuItemData::aCommandStr). It means that a menu that
was defined in a .ui file, can be used inside that .ui
file without any additional code.
This commit uses the new control to fix some currently
non-working buttons in Calc's Notebookbar (but there are
more that can be fixed the same way). It's not clear how
long we will continue to use buttons (instead of
toolboxes) for the Notebookbar, but hopefully this control
will be useful in other places too.
Change-Id: Ie00cde7cd7e39948948960ca2eff76e9db837109
Reviewed-on: https://gerrit.libreoffice.org/34103
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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
Tomaž Vajngerl