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

2019-06-15 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

V Stuart Foote  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=12
   ||5939

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

2019-06-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

V Stuart Foote  changed:

   What|Removed |Added

 CC||79045_79...@mail.ru

--- Comment #29 from V Stuart Foote  ---
*** Bug 123494 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

2019-06-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

V Stuart Foote  changed:

   What|Removed |Added

 CC||serge...@gmail.com

--- Comment #28 from V Stuart Foote  ---
*** Bug 122666 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

2019-06-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #27 from Heiko Tietze  ---
(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.)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

2019-06-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #26 from Heiko Tietze  ---
*** Bug 122523 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

2019-06-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

Maxim Monastirsky  changed:

   What|Removed |Added

 CC||sedukhi...@gmail.com

--- Comment #25 from Maxim Monastirsky  ---
*** Bug 122523 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

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

2018-10-31 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

V Stuart Foote  changed:

   What|Removed |Added

   See Also|https://bugs.documentfounda |
   |tion.org/show_bug.cgi?id=10 |
   |6071,   |
   |https://bugs.documentfounda |
   |tion.org/show_bug.cgi?id=12 |
   |0392|

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2018-10-31 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

V Stuart Foote  changed:

   What|Removed |Added

 CC||pp887...@gmail.com

--- Comment #24 from V Stuart Foote  ---
*** Bug 121085 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2018-10-08 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

V Stuart Foote  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=12
   ||0392
 CC||edmund.laugas...@gmail.com

--- Comment #23 from V Stuart Foote  ---
*** Bug 120392 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2018-07-13 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

Regina Henschel  changed:

   What|Removed |Added

 CC||rgb.m...@gmail.com

--- Comment #22 from Regina Henschel  ---
*** Bug 118733 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2018-05-09 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

Maxim Monastirsky  changed:

   What|Removed |Added

 CC||libretraining.tutorials@gma
   ||il.com

--- Comment #21 from Maxim Monastirsky  ---
*** Bug 117528 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2018-01-03 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #20 from Yousuf Philips (jay)  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-12-19 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

Maxim Monastirsky  changed:

   What|Removed |Added

 CC||qqq...@gmeyer.df-kunde.
   ||de

--- Comment #19 from Maxim Monastirsky  ---
*** Bug 56811 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-11-04 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

Maxim Monastirsky  changed:

   What|Removed |Added

 CC||thomas.le...@gmail.com

--- Comment #18 from Maxim Monastirsky  ---
*** Bug 112826 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-11-02 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #17 from Maxim Monastirsky  ---
Created attachment 137469
  --> https://bugs.documentfoundation.org/attachment.cgi?id=137469=edit
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-30 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #16 from Maxim Monastirsky  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-30 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #15 from Yousuf Philips (jay)  ---
(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.


  
~Text Box
  
  
Insert Text Box
  
  
1
  


> 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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-30 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #14 from Maxim Monastirsky  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-30 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #13 from Yousuf Philips (jay)  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-30 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #12 from Maxim Monastirsky  ---
(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.

> 
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:

 
   
 ~Edit Style...
   
   
 1
   
 
 
   
 Edit
   
   
 .uno:EditStyle
   
   
 1
   
 

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.
> 
> 
>   
> Basic Shapes
>   
>   
> ~Basic
>   
>   
> Insert Basic Shapes
>   
>   
> 1
>   
> 
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).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-29 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

Yousuf Philips (jay)  changed:

   What|Removed |Added

 Blocks|113510  |

--- Comment #11 from Yousuf Philips (jay)  ---
(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.



> 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 

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

2017-10-28 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #10 from Maxim Monastirsky  ---
(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.

> 
>   
> Basic Shapes
>   
>   
> ~Basic
>   
>   
> Insert Basic Shapes
>   
>   
> TooltipLabel
>   
> 
> 
> 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

V Stuart Foote  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=11
   ||3488

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #9 from V Stuart Foote  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #8 from Yousuf Philips (jay)  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #7 from V Stuart Foote  ---
(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 ->
; or ) 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #6 from Yousuf Philips (jay)  ---
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


  
Basic Shapes
  
  
~Basic
  
  
Insert Basic Shapes
  
  
TooltipLabel
  


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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #5 from Maxim Monastirsky  ---
(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  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?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #4 from V Stuart Foote  ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #3 from Yousuf Philips (jay)  ---
(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  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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-10-27 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

--- Comment #2 from Maxim Monastirsky  ---
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.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-06-11 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

Yousuf Philips (jay)  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Blocks||41560
 Ever confirmed|0   |1

--- Comment #1 from Yousuf Philips (jay)  ---
(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.


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=41560
[Bug 41560] [META] Keyboard shortcuts tab of Customization dialog
-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs


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

2017-06-11 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=108458

V Stuart Foote  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=10
   ||6071

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs