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
This reverts commit 939abe5a79.
This causes styles to not appear as having keyboard
shortcuts in Tools > Customize... > Keyboard, and style
buttons that were added using tdf#106681 to not have
their keyboard shortcuts in their tooltips.
Given that the original bug is a local problem in
MenuBarManager, I prefer to fix it there, rather than
put workarounds all over the place, including those ugly
"%20".
Change-Id: I797f463df2b37ab69f73f357ab9d120697e0ff33
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>
After commit 2308bea5ba (sw: change
SwCursorShell::Pop() parameter from meaningless bool to enum,
2017-05-12).
Change-Id: I64ecdf3ea16383c3938b32acdf69a78a31938ae6
Crashed in a11y code with a SwFootnoteFrame that survived a JoinNode and
subsequent deletion of its reference-containing SwTextFrame and thus had
a stale "pRef" member; presumably the SwTableFrame needs to delete an
empty footnote frame like the SwTextFrame does from SwContentFrame::Cut(),
called from DelFrames(), called from CutImpl().
Change-Id: I5a30357ecd3bf474bfc4a5451de89beb245fb0ae
The problem here is that for a table in a footnote on page 42,
SwTabFrm::MakeAll() calls Split(), which first creates a
follow-table-frame and then reformats the last row of the table;
somehow the SwTextFrame id="4636" in that row doesn't fit and wants
to split and then move to the following page with that page's footnote
container as its parent.
So this doesn't work currently.
commit 971adcd9e1 tried to prevent just
the moving forward of the table itself, but the table can still be split;
if IsMoveable() returns false then that also prevents splitting the table.
Change-Id: I1977c65f97cb0f66dbe5b89d7ef7e2cd05125331
Corresponding bug is already fixed in tdf#107104. However created
tests do care only for width, but not for height, like we have in
this testcase.
Change-Id: I6f24e66e3c5e9289e158e0ca043ef01a3ea42880
Reviewed-on: https://gerrit.libreoffice.org/37538
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Obviously after FormulaTokenArray::Assign() or the copy-ctor for that matter,
new tokens can not be added anymore to the shrunk code array. We don't do it,
but ensure that it isn't done in future..
Change-Id: Ibc0115f9f38e9745028a7459c61408c188783d03
