[Libreoffice-bugs] [Bug 108458] Label changes for Toolbar use degrade function listing in the Customize dialog--have duplicate entries on the list

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #2 from Maxim Monastirsky <momonasmon at gmail.com> ---
Here is what I think about the whole situation:

Storing command labels in a central place such as the officecfg module, as
opposed to specifying them in the toolbar/menu xml directly, has the advantage
of having a single string for each command. The disadvantage is that it makes
it impossible to fine-tune labels in certain places, such as different kinds of
ui elements.

This led to the introduction of several "kinds" of labels: ContextLabel,
PopupLabel and TooltipLabel. Given that for most commands the label is the same
for all kinds of ui elements, and to avoid duplicating strings, a layering
scheme was developed: All types of labels inherit from the regular Label, and
use it as a last-chance fallback. Also, as a higher priority fallback,
TooltipLabel inherits from PopupLabel, and PopupLabel inherits from
ContextLabel. In addition, menu commands usually have keyboard accelerators,
and commands that lead to a dialog have also ellipsis, but toolbar buttons
shouldn't have any of those. And in many cases the presence of an accelerator
and/or ellipsis is the only difference between the menu and toolbar label. The
solution was to have accelerator & ellipsis in "Label", but strip them at
runtime for toolbar buttons. This "stripped" variation is also what we use for
the customization dialog.

This layering thing besides being just terribly confusing and complex, is far
from solving our problems, as in some cases we want a different label for the
same command in the same kind of ui element, but in a different location. The
most famous example is slide/page commands in Impress/Draw. To solve this I
introduced what I call "command aliases", which allow having a different
identifier for the same underlying command. The idea is similar to shortcuts in
Windows: Putting an alias on a toolbar/menu is like putting a shortcut on the
desktop. It's not the real command, and therefore can have different
label/icon. Basically it tries to bring the best of all worlds: Having a
centralized storage of labels, while still be able to override the default
label of a specific toolbar/menu item. What's good is that the override is
stored inside officecfg/ instead of in a toolbar/menu xml file, so the same
override can be reused in other places too.

But now that we have aliases, it makes the ContextLabel and PopupLabel
properties largely unnecessary, as they can't solve all problems, at the same
time that aliases can do the same and even more. The more I think about it, I
come to the conclusion that the whole idea of several label properties and
their complex fallback mechanism was a big big mistake. Besides not being able
to handle the Impress/Draw case it has several other problems. Let's take an
example: "Paste Special" is called "More Options..." in the context menu, and
if one customizes the context menu and adds "Paste Special" somewhere else, by
default it will be called there also "More Options...", because that's what
PopupLabel dictates, although it doesn't make any sense. In addition, because
TooltipLabel inherits from PopupLabel, if one customizes the toolbar with
"Paste Special", its tooltip will be "More Options". To avoid that, we can add
an explicit TooltipLabel="Paste Special" override, but then both Label and
TooltipLabel will have the same string. In general, the duplicate strings
problem arises a lot with PopupLabel, as in many cases it's actually the same
as Label, but still has to be explicitly added to override ContextLabel.

So my suggestion is:

1. "Label" always contains the complete command name, thus suitable for the
customization dialog (It can also have accelerator & ellipsis which we can
strip at runtime if needed).
2. "TooltipLabel" should fallback then to "Label" directly, instead of the
weird PopupLabel->ContextLabel->Label fallback path.
3. "ContextLabel" will override "Label" for all kinds of ui elements
(toolbar/menubar/popupmenu). Typical use case is having a shortened label
(assuming that if all need a shortened label, probably it will be the same).
4. In case not all ui elements want the same label, then those that need the
long variation will use the original command, and the special (e.g. short)
variation will be handled using an alias.
5. "PopupLabel" becomes unused and will be removed.
6. To make it easier to identify aliases, they can just append a context to the
original command (e.g. ".uno:EditStyle:stylesmenu"), instead of inventing new
command names each time.

Thoughts?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20171027/55ec123b/attachment.html>