MenuBarManager overwrites the item URL with the parsed
version. This causes the keyboard shortcuts of style
commands to no longer be found on subsequent opening of
the menu, because they have spaces, which in the parsed
version were replaced with "%20".
Change-Id: I80b559203742922f70b7cec54b5a5ae57d3ef7dd
The .uno:StyleApply command takes some arguments, which make
it possible to apply any style of any type. The problem is
that it doesn't provide toggle state to be used when placing
such commands on a toolbar or a menubar. The reason is that
sfx2, by design, can provide status updates only for the
.uno:StyleApply command as a whole, ignoring any arguments
that might be specified in the UI element description. This
behavior is even documented in the XDispatch idl.
wrt solution, changing the generic UI code to handle the
specifics of an individual command can never be a good idea.
The usual approach in such cases is to create separate
commands which will handle the status updates correctly. This
is however not possible in our case because styles can be
created by users, and we can't predict their names and create
separate commands for all of them (given that now it's easy to
add style commands to toolbars and menus - see tdf#106681).
One possible solution is to create a toolbar button controller
on top of .uno:StyleApply, which will be able to translate its
status update to a state compatible with the toolbar. The downside
is that it won't work when placing such command inside a menu, and
in general the menu code in framework doesn't provide any way to
control individual menu items, only a whole sub-menus via a
popup menu controller.
To fix the menu use-case too, this commit introduces a "proxy"
dispatch implementation, which can be used by MenuBarManager
in a transparent way, as if it was the "real" application-level
dispatcher. This means that the changes needed in MenuBarManager
are minimal and do not over-complicate the code, which is a good
thing (Alternatively, such dispatcher could be registered via
the dispatch interception mechanism, but it will add no gain,
given the current requirements, and just add more complexity).
And to make it easier to reuse the code, the new dispatcher
is also used for the toolbar solution.
Change-Id: Ia73b0fa70fd4d1d59360b255aa8fd19570b971ee
Reviewed-on: https://gerrit.libreoffice.org/37590
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
... after dispatch interception change.
To reproduce:
1. Open the testdoc of tdf#102355
2. If not under gtk3 - Open several menus or sub menus.
3. Click the "Intercept" button.
4. Tools > Customize.. > Menus, make some change, click OK.
Expected that old MenuBarManagers (except the top level) are
destructed, and new ones are created. Actually the dtors of
MenuBarManagers from step 2 aren't called (but they will be
eventually called after closing Writer).
The reason we keep active status listening is mainly for
Unity's HUD (see my comment in MenuBarManager::Activate).
But it assumes that Activate was called for all menus,
which is done by GtkSalMenu at application startup,
but not after dispatch interception change. Should we fix
that, or maybe we can just kill this hack (along with
some related code in GtkSalMenu) anytime soon, given
that Unity is officially dead?
Change-Id: Ia1cb24391b393e31c98355dc91833c7511a17cda
Reviewed-on: https://gerrit.libreoffice.org/37589
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
Similar to commit 3268092322 ("Fix the copy-paste").
The original code was using this to get URLTransformer,
but it was later switched to using m_xURLTransformer
in ca00697e3d ("CWS-TOOLING: integrate CWS oj18").
Change-Id: I05592915a651a9d8e0fc443f6adeb494704a99d8
Reviewed-on: https://gerrit.libreoffice.org/37588
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
accept that once initted that LibreOffice cannot be deinitted and reinited
(without lots of work), but allow the main loop to quit and restart so LOKs
thread can run and exit successfully, new LOK connections will restart the main
loop.
The buckets of global state continues to be valid the whole time this way
Change-Id: Ide54c0df2ce4065f7c192ae8c2cedfaaa2b58d72
Reviewed-on: https://gerrit.libreoffice.org/37399
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Use m_xUrlTransformer, and drop the now unneeded m_xContext.is()
check.
Here is the history of this:
- commit ef8f9cfb26 (CWS docking1) introduced this code in
ToolboxController::execute.
- commit a2bbbc5130 (CWS docking3) copy-pasted this into
GenericToolbarController::execute.
- commit 0fc90c8a06 (CWS insight02) changed the original
code, but not the copy-pasted one.
- commit d7afd8e128 (CWS toolbars2) That CWS didn't have
the above change yet, and copy-pasted the old code to yet
another place (GenericToolboxController::execute).
Change-Id: I7f4e8dfb52b96ea5285ea7b2bb3083847dd84932
don't create a menu in order to copy certain entries under certain
conditions to another menu, just insert the specific entries
from more elemental parts
Change-Id: I2254753fdc374742422afdb40fed7e78ae5dfbb2
with 506cab1a01
"take the .ui files from $BRAND_BASE_DIR/$BRAND_SHARE_SUBDIR"
in place .ui files are found and the count here changes,
reverting the above makes it pass, but also reverting
08cf2fd010 (framework: last dispatchInterceptor
gets asked first, 2016-05-20) that this test wants to test also passes
Change-Id: I01f5b77065e9562619412824bf69494b7b672b68
this modifies codemaker so that, for an UNO enum, we generate code
that effectively looks like:
#ifdef LIBO_INTERNAL_ONLY && HAVE_CX11_CONSTEXPR
enum class XXX {
ONE = 1
};
constexpr auto ONE = XXX_ONE;
#else
...the old normal way..
#endif
which means that for LO internal code, the enums are scoped.
The "constexpr auto" trick acts like an alias so we don't have to
use scoped naming everywhere.
Change-Id: I3054ecb230e8666ce98b4a9cb87b384df5f64fb4
Reviewed-on: https://gerrit.libreoffice.org/34546
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-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>
Maxim Monastirsky