Have an unintended issue in the Customize dialog's Keyboard tab, with the Format category functions listing, where the "Label" assigned to commands are used multiple times. From 5.3.0.3 we have duplicates of Increase/Decrease for: Paragraph Spacing, Font Size, & Indent Because commands are named the same, the Customize dialog Keyboard tab's Category "Format" and Function listing has duplicated entries of "Increase" and "Decrease" with no means to identify the element being formatted by the custom key assignment. If the labels have to remain short for use with Toolbar buttons, could the entry in the customize Function list be pulled from the "Tooltiplabel" instead? =-ref-= http://opengrok.libreoffice.org/more/core/officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu?full=increase+decrease+indent https://gerrit.libreoffice.org/28742 https://cgit.freedesktop.org/libreoffice/core/commit/?id=37ad8daabf596e039b4ca62e06e91d5a83128b7c
(In reply to V Stuart Foote from comment #0) > If the labels have to remain short for use with Toolbar buttons, could the > entry in the customize Function list be pulled from the "Tooltiplabel" > instead? So the *Command.xcu files has 4 labels that it can pull from (Label, ContextLabel, TooltipLabel, PopupLabel) and with changes in the menu, toolbar, and notebookbar, labels have been modified recently. I guess Tooltiplabel could be used, but it would have a descriptive label like 'Paste Clipboard Contents', while a label of 'Paste' would be sufficient. Also Tooltiplabel isnt always defined, so it will need to be able to fallback on Maxim: What is your take on this, as this issue did popup before.
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?
(In reply to Maxim Monastirsky from comment #2) > 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). +1 as it focuses on the entry that is always assigned and targeting the menu bar > 2. "TooltipLabel" should fallback then to "Label" directly, instead of the > weird PopupLabel->ContextLabel->Label fallback path. +1 as tooltip will be descriptive form of Label string > 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). Toolbar label will normally need the shorter form, while menubar and popupmenu normally dont. > 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. Dont really like the idea of separating this. > 5. "PopupLabel" becomes unused and will be removed. PopupLabel will always be useful as it can have a different accelerator key than the menubar or a completely different label, e.g. 'More Options...', 'Close Preview' (.uno:PrintPreview) > 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. i think aliasing should be done within a <prop> element rather than with a new node. So here is my suggestion :D 1. Label - same as maxim's (will normally be either suitable for the toolbar, menubar, or tooltip label) 2. TooltipLabel - same as maxim's 3. ContextLabel will be used when Label is suitable for toolbar and will be used for menubar and context menu, else fallback on Label 4. PopupLabel for context menu, when a different accelerator or label is needed than what is found in ContextLabel or Label 5. ToolbarLabel will be used when Label is suitable for menubar and will be for the toolbar and notebookbar, else fallback on Label 6. We also need a mechanism to assign any of these entries to another label without having to type its label again, as this would reduce translation work.
That rework seems reasonable, but please consider the a11y requirements in this. Have to be sure the "Label"/"TooltipLabel" (or the correct descriptive entry from local help) appropriate for the action gets consistently assigned to respond when our Assistive Technology (AT) accessibility support is enabled. Would a more verbose "AccessibilityLabel" (merging the label/tooltiplabel with the extended description from the help article) over improved consistency rendering the UI for AT?
(In reply to Yousuf Philips (jay) from comment #3) > > 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). > > Toolbar label will normally need the shorter form, while menubar and > popupmenu normally dont. Are you sure? I got the impression that the menu usually uses the shorter form. e.g. open the insert menu, you have there "Image...", "Chart...", Fontwork...", and most of those don't appear in context menus anyway. > > 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. > > Dont really like the idea of separating this. Is it really worse than adding the label directly into xml files? I understand that this requires writing the command name again in officecfg, but for that you get the possibility of reusing that label somewhere else, something you couldn't do if the label was in xml. > > 5. "PopupLabel" becomes unused and will be removed. > > PopupLabel will always be useful as it can have a different accelerator key > than the menubar or a completely different label, e.g. 'More Options...', So basically we shouldn't care about users adding paste special to a different place, and still getting there "More Options..." by default? That's why I suggested that a completely different label should go to alias. > i think aliasing should be done within a <prop> element rather than with a > new node. Don't see much benefit in doing this, but will research if that's easily possible. > So here is my suggestion :D Thanks. I will take the time to think about it, and reply later. Anyway, some inline comments for now: > 4. PopupLabel for context menu, when a different accelerator or label is > needed than what is found in ContextLabel or Label During my work on context menus, I noticed that in many cases (esp. in Calc) PopupLabel is the same as Label, and needed only because ContextLabel uses the shorter form. So as long as we have PopupLabel fallback to ContextLabel, there will be no solution for the string duplication in this case. Similarly, if PopupLabel will fallback to Label, surely it will require duplicates for other cases. Which just shows us that the whole idea of relying on fallbacks is just broken by design. > 6. We also need a mechanism to assign any of these entries to another label > without having to type its label again, as this would reduce translation > work. That's already possible with aliases, but you seem to not like it for some reason. Maybe we should clearly define what are the problems of the current aliases implementation, and just try to address them?
Sorry Stuart, didnt fully get the a11y issue you were trying to address. Where you saying that in addition to whatever tooltip that is read by the screen reader, some additional instructions should be read? (In reply to Maxim Monastirsky from comment #5) > Are you sure? I got the impression that the menu usually uses the shorter > form. e.g. open the insert menu, you have there "Image...", "Chart...", > Fontwork...", and most of those don't appear in context menus anyway. It maybe 50/50 between which one uses the shorter form, but that all depends on how much work i've been doing to improve the organization of the menu. ;D > Is it really worse than adding the label directly into xml files? I > understand that this requires writing the command name again in officecfg, > but for that you get the possibility of reusing that label somewhere else, > something you couldn't do if the label was in xml. Didnt fully get what you meant here, but adding labels directly into the XML file means that they wont be translatable (e.g. bug 101566). > So basically we shouldn't care about users adding paste special to a > different place, and still getting there "More Options..." by default? > That's why I suggested that a completely different label should go to alias. I know i should have written this down in my last comment but i had to rush out. :D So if a user uses the customization dialog, the PopupLabel text wont be used when adding it to the context menu, the Label text will be used. > During my work on context menus, I noticed that in many cases (esp. in Calc) > PopupLabel is the same as Label, and needed only because ContextLabel uses > the shorter form. So as long as we have PopupLabel fallback to ContextLabel, > there will be no solution for the string duplication in this case. > Similarly, if PopupLabel will fallback to Label, surely it will require > duplicates for other cases. Which just shows us that the whole idea of > relying on fallbacks is just broken by design. Which is why i suggested number 6, which allows string duplication. Let me give an example, which i wanted to as well before but had to rush out. :D <node oor:name=".uno:BasicShapes" oor:op="replace"> <prop oor:name="Label" oor:type="xs:string"> <value xml:lang="en-US">Basic Shapes</value> </prop> <prop oor:name="ContextLabel" oor:type="xs:string"> <value xml:lang="en-US">~Basic</value> </prop> <prop oor:name="TooltipLabel" oor:type="xs:string"> <value xml:lang="en-US">Insert Basic Shapes</value> </prop> <prop oor:name="PopupLabel" oor:type="xs:string"> <value>TooltipLabel</value> </prop> </node> So in this example, PopupLabel is pulling in the label from TooltipLabel as both the Label and ContextLabel aren't suitable and this wont require the translation team to translate the tootlip string a second time. > That's already possible with aliases, but you seem to not like it for some > reason. Maybe we should clearly define what are the problems of the current > aliases implementation, and just try to address them? Aliases require additional translation, they dont appear in the customization dialog and would also separate labels from all appearing under a single uno command node, which will likely complicate things more. Would be great if we could have a jitsi meetup and discuss all these issues once by live voice/text as i can see things will likely be miscommunicated by comments. If you have time, would be great if you can jump on telegram[1] or irc[2] when you are free, so we could find a suitable meetup time, or you can join the weekly design meeting[3] on thursday at 1pm UTC. You are free to do any of these outside of this issue as well, you to Stuart. :D [1] https://t.me/joinchat/B-szpERIwOCjY_97ehftHA [2] https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-design [3] https://meet.jit.si/LibreOfficeDesign
(In reply to Yousuf Philips (jay) from comment #6) > Sorry Stuart, didnt fully get the a11y issue you were trying to address. > Where you saying that in addition to whatever tooltip that is read by the > screen reader, some additional instructions should be read? > What I'm asking is that however the labeling is reworked--that function for a11y be taken into account and made consistent as well. For a11y we probably should be reading the descriptive tooltip for menu and button objects. But currently 5.4.3, with keyboard movements (F10 -> F6 -> <Tab/ShiftTab>; or <UP,DOWN,LEFT,RIGHT>) just the short button/menu label is exposed. This contrasts to mouseover behavior which gets the descriptive tooltip--or the extended tooltip pulled from offline local help when installed (and auto-enabled when an AT is in use). Differences between keyboard and mouseover event triggers are probably unavoidable--but as the labeling controls what is exposed to AT, it needs to considered as well while reworking label structure--and ideally make keyboard and mouseover expose the same tooltip/enhanced tooltip when traversing menus, context menus, and toolbars when Assistive Technology tool support is enabled.
I get the issue now Stuart and you should file an enhancement bug for a11y that it should read the button tooltip and not the labels in the toolbars, as this wont be something solved in this issue.
(In reply to Yousuf Philips (jay) from comment #8) > I get the issue now Stuart and you should file an enhancement bug for a11y > that it should read the button tooltip and not the labels in the toolbars, > as this wont be something solved in this issue. Will do, just want to be sure that while refactoring the labeling that we don't complicate what is needed for a11y support--and ideally facilitate it as tooltip/extended tooltip from help should be derived from the label structure in some fashion.
(In reply to Yousuf Philips (jay) from comment #6) > It maybe 50/50 between which one uses the shorter form, but that all depends > on how much work i've been doing to improve the organization of the menu. ;D I think the rule is this: If the upper menu (either top level or the menu item which points to the current sub menu) says the context, then it's dropped from its sub menu items. i.e. in my example - because the top level menu says "Insert", the word "insert" doesn't need to be repeated in its menu items, so it's sufficient to just say "Image" or "Comment". If this is true, we might build on this rule (see below). > Didnt fully get what you meant here, but adding labels directly into the XML > file means that they wont be translatable (e.g. bug 101566). Yes, I know. What I meant was "_if_ that was possible to do w/o translation problems". As we had similar possibility back in the days menus were in .src files, and I can't remember any complaints about it. > So if a user uses the customization dialog, the PopupLabel text wont > be used when adding it to the context menu, the Label text will be used. The way to do this is probably to store the "Label" contents in the customized xml file (as we can't just ignore PopupLabel for customized menus, as it will affect the whole menu). But doing this will reintroduce Bug 101374. > <node oor:name=".uno:BasicShapes" oor:op="replace"> > <prop oor:name="Label" oor:type="xs:string"> > <value xml:lang="en-US">Basic Shapes</value> > </prop> > <prop oor:name="ContextLabel" oor:type="xs:string"> > <value xml:lang="en-US">~Basic</value> > </prop> > <prop oor:name="TooltipLabel" oor:type="xs:string"> > <value xml:lang="en-US">Insert Basic Shapes</value> > </prop> > <prop oor:name="PopupLabel" oor:type="xs:string"> > <value>TooltipLabel</value> > </prop> > </node> > > So in this example, PopupLabel is pulling in the label from TooltipLabel as > both the Label and ContextLabel aren't suitable and this wont require the > translation team to translate the tootlip string a second time. Will need to check in the config reading code, if that's OK to have non-translatable string, inside an otherwise translatable property. Also will need to check how bad it will affect performance, as this will require to compare each and every string with a known set of property names. > Aliases require additional translation Why? Suppose there is a long string and a short string. The original command gets the long string, and everything that needs the long string uses the original command. The alias gets the short string, and everything that needs the short string uses the alias. I don't see any additional translatable strings. > they dont appear in the customization dialog This is by design. Alias is just another identifier for the same underlying command. How useful it is to have in the list several items pointing to the same command, but with a slightly different title? And anyway aliases should *not* appear in the keyboard tab, as aliases can't have kb shortcuts by their own, as allowing this will make it impossible to show the kb shortcut next to an alias menu item, because you can't assign the same kb shorcut to several command. > and would also separate labels from all appearing under > a single uno command node, which will likely complicate things more. Don't see much problem here, as long as we put the alias next to the original command (or if we find a way to have the alias as a property inside the original command). > Would be great if we could have a jitsi meetup and discuss all these issues > once by live voice/text as i can see things will likely be miscommunicated > by comments. I will consider this, but usually I try to avoid live discussions, as my live communication abilities aren't that good. ---- Anyway I would like throw an additional idea: 1. Label - always full name, used for menus. 2. ContextLabel - always short name (where applicable), used for toolbars, fallback to Label. (And such usage aligns well with the name "ContextLabel", as short names are about dropping the context when it's obvious.) 3. PopupLabel - used for context menus, fallback to Label. (Ideally only for slight changes, like a different accelerator. Completely different name like "More Options" I would prefer to have in alias, and hopefully there will be no that much of them.) 4. Each context menu or a menu item which opens another menu (including top level menu) gets a new optional property "menu:contextlabel". When set to true, that menu will be forced to use ContextLabel instead of PopupLabel or Label. This is based on the rule I suggested in the beginning of this comment, that menus have a short label only when their parent item clearly says the context, so we will be able to mark those parents with the new property.
(In reply to Maxim Monastirsky from comment #10) > I think the rule is this: If the upper menu (either top level or the menu > item which points to the current sub menu) says the context, then it's > dropped from its sub menu items. i.e. in my example - because the top level > menu says "Insert", the word "insert" doesn't need to be repeated in its > menu items, so it's sufficient to just say "Image" or "Comment". If this is > true, we might build on this rule (see below). Yes ContextLabel is normally short when the top level or sub menu give the context, but you also have entries where the hierarchy only helps with organization and the string is independent like File > Preview in Web Browser, Edit > Select All, View > Hide Whitespace, Format > Spacing > Increase Paragraph Spacing, Table > Merge Cells, Tools > Mail Merge Wizard. > Yes, I know. What I meant was "_if_ that was possible to do w/o translation > problems". As we had similar possibility back in the days menus were in .src > files, and I can't remember any complaints about it. So which xml files did you want to do this in (menus, context menus, toolbars)? > The way to do this is probably to store the "Label" contents in the > customized xml file (as we can't just ignore PopupLabel for customized > menus, as it will affect the whole menu). But doing this will reintroduce > Bug 101374. If we added the label into the xml as mentioned above, we'd also have the same problem when changing the UI. Maybe we could use the 'Label' contents and it works in whatever UI the user switches to something like this. <menu:menu menu:id=".uno:InsertFormMenu" menu:use_default_label="true"> > Will need to check in the config reading code, if that's OK to have > non-translatable string, inside an otherwise translatable property. Also > will need to check how bad it will affect performance, as this will require > to compare each and every string with a known set of property names. Check and see if there is a performance hit. If so, i know you'll figure out a way to do it without one :D > Why? Suppose there is a long string and a short string. The original command > gets the long string, and everything that needs the long string uses the > original command. The alias gets the short string, and everything that needs > the short string uses the alias. I don't see any additional translatable > strings. Could you give an xml example of this so i can better get it. :D > This is by design. Alias is just another identifier for the same underlying > command. How useful it is to have in the list several items pointing to the > same command, but with a slightly different title? And anyway aliases should > *not* appear in the keyboard tab, as aliases can't have kb shortcuts by > their own, as allowing this will make it impossible to show the kb shortcut > next to an alias menu item, because you can't assign the same kb shorcut to > several command. True that its just another identifier, but when users open up the customization dialog and search for example 'new slide' in impress as it appears in the Slide menu and dont find the entry and dont have any indication that its the same as 'new page', this isnt an easy issue for users to deal with. > Don't see much problem here, as long as we put the alias next to the > original command (or if we find a way to have the alias as a property inside > the original command). Yes i was trying to have the alias in the same original command in my example xml code. :D > I will consider this, but usually I try to avoid live discussions, as my > live communication abilities aren't that good. Your text communications seem to be perfect, so dont know why your live communications would be any different. No need to be shy, you dont have to turn on your webcam if you dont want to. ;D > Anyway I would like throw an additional idea: > > 1. Label - always full name, used for menus. > 2. ContextLabel - always short name (where applicable), used for toolbars, > fallback to Label. (And such usage aligns well with the name "ContextLabel", > as short names are about dropping the context when it's obvious.) > 3. PopupLabel - used for context menus, fallback to Label. (Ideally only for > slight changes, like a different accelerator. Completely different name like > "More Options" I would prefer to have in alias, and hopefully there will be > no that much of them.) > 4. Each context menu or a menu item which opens another menu (including top > level menu) gets a new optional property "menu:contextlabel". When set to > true, that menu will be forced to use ContextLabel instead of PopupLabel or > Label. This is based on the rule I suggested in the beginning of this > comment, that menus have a short label only when their parent item clearly > says the context, so we will be able to mark those parents with the new > property. Having somethings in the .xml files and some in the .xcu files means that you'd have to modify things in multiple places, which will make this task more difficult. I'm assuming you forgot to include TooltipLabel or is Label supposed to have the full descriptive name that would go into TooltipLabel. So using this proposal, how would the the xml look for this current entry. <node oor:name=".uno:BasicShapes" oor:op="replace"> <prop oor:name="Label" oor:type="xs:string"> <value xml:lang="en-US">Basic Shapes</value> </prop> <prop oor:name="ContextLabel" oor:type="xs:string"> <value xml:lang="en-US">~Basic</value> </prop> <prop oor:name="TooltipLabel" oor:type="xs:string"> <value xml:lang="en-US">Insert Basic Shapes</value> </prop> <prop oor:name="Properties" oor:type="xs:int"> <value>1</value> </prop> </node> For me, defining a different entry for each place the string can appear in ensures that we always get exactly what we define.
(In reply to Yousuf Philips (jay) from comment #11) > Yes ContextLabel is normally short when the top level or sub menu give the > context, but you also have entries where the hierarchy only helps with > organization and the string is independent like File > Preview in Web > Browser, Edit > Select All, View > Hide Whitespace, Format > Spacing > > Increase Paragraph Spacing, Table > Merge Cells, Tools > Mail Merge Wizard. True. That's why my second proposal includes a way to mark those items which need their submenus to drop the context, and those which don't. (Unless we have both short and long labels in the same level of the hierarchy, in which case this proposal won't help.) > > Yes, I know. What I meant was "_if_ that was possible to do w/o translation > > problems". As we had similar possibility back in the days menus were in .src > > files, and I can't remember any complaints about it. > > So which xml files did you want to do this in (menus, context menus, > toolbars)? Nowhere. I was just saying that using aliases gives us the same flexibility as if we were putting labels in xml, as we're not restricted with having just one possible label for a given ui element type, and we don't need to fight with a complex fallback mechanism. Instead we define a label with an unique identifier, and just use that label where we need it. If we need another label, then again we define it with another unique identifier, and use it where needed. > <menu:menu menu:id=".uno:InsertFormMenu" menu:use_default_label="true"> So if we're about introducing this per-item property to force the usage of "Label", what stops us from using this property in our default xmls (not just after customization), and that way resolve the short vs long strings problem in menus? > > Why? Suppose there is a long string and a short string. The original command > > gets the long string, and everything that needs the long string uses the > > original command. The alias gets the short string, and everything that needs > > the short string uses the alias. I don't see any additional translatable > > strings. > > Could you give an xml example of this so i can better get it. :D Right now it can be like this: <node oor:name=".uno:EditStyle" oor:op="replace"> <prop oor:name="Label" oor:type="xs:string"> <value xml:lang="en-US">~Edit Style...</value> </prop> <prop oor:name="Properties" oor:type="xs:int"> <value>1</value> </prop> </node> <node oor:name=".uno:EditStyle:toolbar" oor:op="replace"> <prop oor:name="Label" oor:type="xs:string"> <value xml:lang="en-US">Edit</value> </prop> <prop oor:name="TargetURL" oor:type="xs:string"> <value>.uno:EditStyle</value> </prop> <prop oor:name="Properties" oor:type="xs:int"> <value>1</value> </prop> </node> But we'll be able to optimize it, so e.g. "Properties" could be inherited from the main command. > True that its just another identifier, but when users open up the > customization dialog and search for example 'new slide' in impress as it > appears in the Slide menu and dont find the entry and dont have any > indication that its the same as 'new page', this isnt an easy issue for > users to deal with. True. Which suggests that using aliases for the page/slide commands wasn't the ideal solution. Ideally we need a way to override the "Page" string, not to introduce a separate "Slide" string, and just switch the UI to it. But at least I hope that we can agree that there shouldn't be an additional "More Options" entry in the list, as "Paste Special" is already there, and so aliases fit perfectly in this particular use-case. > Having somethings in the .xml files and some in the .xcu files means that > you'd have to modify things in multiple places, which will make this task > more difficult. If you feel this will be more difficult, maybe we can do something similar in .xcu instead, so e.g. .uno:InsertMenu will be marked somehow as being a context command. > I'm assuming you forgot to include TooltipLabel It wasn't needed, as we have already reached an agreement about it (comment 3). > So using this proposal, how would the the xml look for this current entry. > > <node oor:name=".uno:BasicShapes" oor:op="replace"> > <prop oor:name="Label" oor:type="xs:string"> > <value xml:lang="en-US">Basic Shapes</value> > </prop> > <prop oor:name="ContextLabel" oor:type="xs:string"> > <value xml:lang="en-US">~Basic</value> > </prop> > <prop oor:name="TooltipLabel" oor:type="xs:string"> > <value xml:lang="en-US">Insert Basic Shapes</value> > </prop> > <prop oor:name="Properties" oor:type="xs:int"> > <value>1</value> > </prop> > </node> It can stay the same, except that there will be a change in behavior, so the toolbar button label (not the tooltip!) will be "Basic" (but I assume this is good, as we're moving towards short toolbar labels). Will also need to mark .uno:ShapesMenu as contextlabel=true, so an additional change will be required in menubar.xml (or in .xcu, see above).
So let me be more clear about the issue of translation. What i'm hoping we can do is limit the amount of changes to the existing elements if they are not needed, as renaming the strings or moving them using your aliasising mechanism will require the translation teams to retranslate them, which was the primary reason for my string referencing mechanism mentioned in comment 2.
(In reply to Yousuf Philips (jay) from comment #13) > So let me be more clear about the issue of translation. What i'm hoping we > can do is limit the amount of changes to the existing elements if they are > not needed, as renaming the strings or moving them using your aliasising > mechanism will require the translation teams to retranslate them, which was > the primary reason for my string referencing mechanism mentioned in comment > 2. Ah OK, I get your point now, but: 1. As we both agree that "Label" will have the full name, and that isn't the case for now, all those short names currently in "Label" will need to be re-translated anyway, even according to your proposal. 2. I know nothing about how translations work, but as we don't plan to change the strings themselves, only their context, maybe it will be possible to script the change, so it won't require re-translation of anything? If yes, I think that it worth spending the time on such script, if as a result we'll get a system that will better serve us in the long run. Anyway, that's a good point. We shouldn't accept any solution that doesn't have a clear migration path for existing translations, and we shouldn't push any change before we have the solution for translations already in place.
(In reply to Maxim Monastirsky from comment #14) > 1. As we both agree that "Label" will have the full name, and that isn't the > case for now, all those short names currently in "Label" will need to be > re-translated anyway, even according to your proposal. I skimmed through 1/4 of GenericCommands.xcu and the majority of entries only had Label, while the ones that had Label and ContextLabel, the majority of them wouldnt need to be changed according to my proposal. When you say "full name" in Label, would that mean for example 'Insert Text Box' (which i would have under TooltipLabel) or just 'Text Box' for .uno:Text. <node oor:name=".uno:Text" oor:op="replace"> <prop oor:name="Label" oor:type="xs:string"> <value xml:lang="en-US">~Text Box</value> </prop> <prop oor:name="TooltipLabel" oor:type="xs:string"> <value xml:lang="en-US">Insert Text Box</value> </prop> <prop oor:name="Properties" oor:type="xs:int"> <value>1</value> </prop> </node> > 2. I know nothing about how translations work, but as we don't plan to > change the strings themselves, only their context, maybe it will be possible > to script the change, so it won't require re-translation of anything? If > yes, I think that it worth spending the time on such script, if as a result > we'll get a system that will better serve us in the long run. I dont fully grasp the concept myself, but each string is given a reference ID which is used to translate that particular string into whichever language. This reference ID can be found in the qtz UI and help language packs, but i dont fully grasp how this reference ID changes sometimes. I think moggi, cloph and/or kendy will have better info that you can get. > Anyway, that's a good point. We shouldn't accept any solution that doesn't > have a clear migration path for existing translations, and we shouldn't push > any change before we have the solution for translations already in place. Or ideally have a solution that has limited string changes. :D
(In reply to Yousuf Philips (jay) from comment #15) > When you say > "full name" in Label, would that mean for example 'Insert Text Box' (which i > would have under TooltipLabel) or just 'Text Box' for .uno:Text. Anything that fits the customization dialog is fine for "Label", so I believe "Text Box" is OK. The problem is mostly around some verb-only labels, like "Edit" for edit style, "Clear" for clear formatting, or "Increase" (which repeats 3 times in the list, for increase font, increase paragraph spacing, and increase indent). There is also a problem with "Left"/"Right" which repeat 3 times in the list, for paragraph align, and for object align.
Created attachment 137469 [details] dirty patch to demonstrate a concept, don't push! Jay: So I was playing with improving our aliases offering, and I'm attaching now a patch that shows a few new ideas. The code there is horrible, and isn't mean to be pushed in its current state, but it should be otherwise functional. Would be great if you could give it a try, and give feedback about the new ideas (can be applied to your tree using 'git am 0001-aliases-WIP.patch'). What it tries to do is: 1. Define alternative labels inside the same node, instead of a separate alias. (Example is .uno:AddDirect in Writer's toolbar and menu). 2. Use this to fix the slide command names in the customization dialog. (Example is .uno:InsertPage). In this case the label of the original command is changed, no new identifier is created.
*** Bug 112826 has been marked as a duplicate of this bug. ***
*** Bug 56811 has been marked as a duplicate of this bug. ***
Maxim: Sorry that i didnt have time to try out your patch, but glancing at the code, the alternative labels on the same node seem like an interesting way to reference a particular label if one is needed, but didnt really see the point in it if we are defining specific labels as ContextLabel, TooltipLabel, etc. The alias idea for the slide commands seems great as it would fix the customization dialog, but wouldnt solve the problem of a different icon needed for the alias command. But now that 6.0 has been branched and nearly out the door, you can begin working on improving this issue for the next release with the stuff we've already agreed upon, so that the kinks can be smoothened out over the next 6 months, and translators will have sufficient time to fix any changes that are made.
*** Bug 117528 has been marked as a duplicate of this bug. ***
*** Bug 118733 has been marked as a duplicate of this bug. ***
*** Bug 120392 has been marked as a duplicate of this bug. ***
*** Bug 121085 has been marked as a duplicate of this bug. ***
*** Bug 122523 has been marked as a duplicate of this bug. ***
(In reply to Maxim Monastirsky from comment #25) > *** Bug 122523 has been marked as a duplicate of this bug. *** Since we got many of these issues not being sure ourself what exact command is behind the name we could also show the command name in a tooltip perhaps together with other information. Meaning you hover over a function name in the customize dialog and the tooltip shows: Label: Highlight color Name: uno:CharBackColor Tooltip: Source: GenericCommands.xcu (Maybe the last is a bit too much.)
*** Bug 122666 has been marked as a duplicate of this bug. ***
*** Bug 123494 has been marked as a duplicate of this bug. ***
Changing priority to 'high' since the number of duplicates is 5 or higher
*** Bug 129102 has been marked as a duplicate of this bug. ***
*** Bug 129122 has been marked as a duplicate of this bug. ***
Please give me a code pointer how to show the quickhelp depending on the treeview content under the cursor. Tried to enhance weld.hxx and also to put connect_help() at SvxConfigDialog constructor. Nothing works ;-(
(In reply to Heiko Tietze from comment #33) > Please give me a code pointer how to show the quickhelp depending on the > treeview content under the cursor. Tried to enhance weld.hxx and also to put > connect_help() at SvxConfigDialog constructor. Nothing works ;-( Hi Heiko, Here is a code-pointer: https://gerrit.libreoffice.org/#/c/84555/ You just need to add what you want to have displayed in the help message in the IMPL_LINK(CuiConfigFunctionListBox, DoRequestHelp, const weld::TreeIter&, rIter, OUString). The patch should probably be broken into two parts. The part that makes custom tool tips work for TreeView and the part that connects query tooltip signal to the TreeView in CuiConfigFunctionListBox along with setting has_tooltip true for the TreeView to let custom tooltips be used.
gtk3 query-tooltip handling part: https://gerrit.libreoffice.org/#/c/84587/ sal handling is WIP
(In reply to Jim Raykowski from comment #35) > gtk3 query-tooltip handling part: > https://gerrit.libreoffice.org/#/c/84587/ > > sal handling is WIP non-gtk3 handling has been added to the patch
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6303f8ac291233b1f6888a8d71e769debe0f9fb0 tdf#108458 related: Add tooltip handling to TreeView It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c29fa13bd050134e751b01d0c4178538c4c20f69 Related tdf#108458 if no TooltipHdl set use usual tooltip It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fdb5ce011cb043475869d0b607ea25b8f32b4314 tdf#108458 Show tooltips in CuiConfigFunctionListBox It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The tree has now individual tooltips with Label (eg "About"), Name (eg .uno:About), and Tooltip (eg. "Show the about dialog") all data taken from the command.
(In reply to Heiko Tietze from comment #40) > The tree has now individual tooltips with Label (eg "About"), Name (eg > .uno:About), and Tooltip (eg. "Show the about dialog") all data taken from > the command. Nice solution; thanks Jim! However, testing with Version: 6.5.0.0.alpha0+ (x64) Build ID: fdb5ce011cb043475869d0b607ea25b8f32b4314 CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL in Writer's Customize (Keyboard tab), hovering over *every* function in All commands category, I couldn't find a single function with non-empty Tooltip: field - even for known-to-have one, like "Table" (defaulting to Ctrl+F12, having a button on toolbar, with "Insert Table" tooltip). And the Label: field seems redundant, since that's exactly what is displayed in the Function list?
Also "Assigned Commands" lists on Manus, Toolbars, Notebookbar, and Context menus likely also need those tooltips?
Only the command trees for main menu, toolbar, and context menu provide the tooltips.
(In reply to Heiko Tietze from comment #43) That only means that missing data could be added to other boxes, copying what is done in CommandCategoryListBox::FillFunctionsList; e.g. CuiConfigGroupListBox::FillFunctionsList for the list on Keyboard tab. Or be queried on demand when showing tooltip (and filled into the pData to avoid repeated queries).
(In reply to Mike Kaganski from comment #41) > in Writer's Customize (Keyboard tab), hovering over *every* function in All > commands category, I couldn't find a single function with non-empty Tooltip: > field - even for known-to-have one, like "Table" (defaulting to Ctrl+F12, > having a button on toolbar, with "Insert Table" tooltip). > I repro. Debugging in progress.
(In reply to Jim Raykowski from comment #45) > (In reply to Mike Kaganski from comment #41) > > in Writer's Customize (Keyboard tab), hovering over *every* function in All > > commands category, I couldn't find a single function with non-empty Tooltip: > > field - even for known-to-have one, like "Table" (defaulting to Ctrl+F12, > > having a button on toolbar, with "Insert Table" tooltip). > > > I repro. Debugging in progress. Patch for this is here: https://gerrit.libreoffice.org/#/c/85776/
*** Bug 129549 has been marked as a duplicate of this bug. ***
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/444f0d256957544d26b9af9a0898364e829df1b5 tdf#108458 related: Make command tooltip show in tooltip It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Xisco Faulí from comment #47) > *** Bug 129549 has been marked as a duplicate of this bug. *** Tested with: Version: 6.5.0.0.alpha0+ (x64) Build ID: 444f0d256957544d26b9af9a0898364e829df1b5 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; Locale: da-DK (en_DK); UI-Language: en-US Calc: CL but still same problem as reported in bug 129549 – though now it is easier to see the situation with the the new tooltips.
So the multiline tooltips Heiko & Jim worked up clearly resolves this issue of ambiguous labels. As a sidebar, opened bug 129720 to use this multiline tooltip as text for the Description box (absent a Local Help installation).