[Libreoffice-ux-advise] [Bug 93837] Allow customization of the Context Menus

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Sun Feb 21 18:51:46 UTC 2016


https://bugs.documentfoundation.org/show_bug.cgi?id=93837

--- Comment #41 from Maxim Monastirsky <momonasmon at gmail.com> ---
(In reply to Yousuf (Jay) Philips from comment #40)
> @Maxim: If possible, it would be nice to have a means of including an xml
> file inside and an xml file, so that if we needed to make a change, it could
> be done in a single file rather than every file. (e.g. cut, copy, paste)

- For the duplicate sub-menus, like Anchor, Wrap etc., it's possible to extract
them to separate files, and then use ResourceMenuController to include them in
context menus or menu bar (like I did with conditional formatting). It's
already on my TODO list, but with somewhat low priority.

- For a sequence of commands (cut, copy, paste) there isn't currently a way (at
least that I know). Surely we can think of some solution (change the parser to
support includes, use XSLT, or other pre-processing, or even introduce a
concept of menu fragments) - but I wonder if this really worth the effort, esp.
if this is only about cut-copy-paste (and maybe one or two more such cases).
And replacing identical sequence of commands - if ever needed - surely could be
done using some automation.

Also, while I fully understand your concerns, I actually think that the current
situation has _some_ advantage over what we had before, as it's now much easier
to see the whole menu structure at once and modify it, instead of getting lost
in the forest of #includes and #defines.

In wrt. to cut-copy-paste in particular, there is much simpler solution: I can
easily hardcode it in the C++ code for any context menu. That's what we're
doing for .src context menus as you probably know, so it will be no worse if we
continue with this in the new implementation. (The downsides are that some
menus shouldn't ideally have clipboard functions (e.g. print preview), and also
that users won't be able to customize this part of the menu. But we might find
some solutions for those.)

Anyway - if you (or anyone else) have any bright (technical) idea on how to
improve the current implementation - please share it. I - as always - open for
suggestions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Libreoffice-ux-advise mailing list