After the recent menu reorganization, change case commands are nested 3 levels deep in the Format/Text/Change case submenu. That is absolutely inappropriate.
Thanks for filing this issue. I didn't look in any details of the change, but your comment looks valid to consider. Cheers - Cor
Find no substantive issues with the new placement. The sub menu has been reduced to the font effects as available from the Character dialog on the Format menu or a context menu for selection. The "case" effects can be applied from any. The Format -> Text -> Change Case sub menu is reasonable UI and meets HIG of reducing total count of menu items. Would move to resolve as invalid. =-=-= As an aside, labeling of tthe .uno commands for changing case do need to be normalized. And we look to need an .uno action for Small Capitals (available in the dialog but not as a button action). Change Case Font Effects .uno:Command menu dialog Sentence case (Without) .uno:ChangeCaseToSentenceCase lowercase Lowercase .uno:ChangeCaseToLower UPPERCASE Capitals .uno:ChangeCaseToUpper Capitalize Title .uno:ChangeCaseToTitleCase Every Word tOGGLE cASE not-provided .uno:ChangeCaseToToggleCase not-provided Small capitals --not defined chardlg.cxx/chardlg.hxx
(In reply to Urmas from comment #0) > After the recent menu reorganization, change case commands are nested 3 > levels deep in the Format/Text/Change case submenu. That is absolutely > inappropriate. Not sure why moving it from 2 levels deep to 3 levels deep is considered absolutely inappropriate, but here was my reasoning for doing so. 1) Space: There are over the recommended 20 items in the 1st level 2) Consolidation: Grouping all the character level effects under one menu ( Format > Text ) As there are only 12 entries in the Format > Text menu, the 5 entries from the Change Case submenu could be moved up a level. According to the OOo stats, Lowercase and Uppercase are the only entries in the 5 that are highly used, which is why both are now available, but hidden by default, in the formatting toolbar. (In reply to V Stuart Foote from comment #2) > As an aside, labeling of tthe .uno commands for changing case do need to be > normalized. And we look to need an .uno action for Small Capitals (available > in the dialog but not as a button action). > > Change Case Font Effects .uno:Command > menu dialog > Sentence case (Without) .uno:ChangeCaseToSentenceCase > lowercase Lowercase .uno:ChangeCaseToLower > UPPERCASE Capitals .uno:ChangeCaseToUpper > Capitalize Title .uno:ChangeCaseToTitleCase > Every Word > tOGGLE cASE not-provided .uno:ChangeCaseToToggleCase > not-provided Small capitals --not defined chardlg.cxx/chardlg.hxx The .uno:ChangeCaseToLower and .uno:ChangeCaseToUpper commands are permanent case changes that affect the characters' ascii values, while the 'Capitals' and 'Lowercase' effects are character style level effects and dont have equivalent uno commands to my knowledge.
You can make more space by moving 'Clear direct formatting' into the 'Styles' menu, where it makes more sense.
Clear <direct> formatting at the Styles menu wouldn't be the best fit, although it sounds good on the first glance. There have been good a couple of reasons to change the menu. When it has negative bearing on your personal workflow we apologize. But in general the function is not what the average user needs. And as an expert user you can easily modify your menu per Tool > Customize. Please don't understand the objection to your report as ignorance. It is a valuable contribution and will count for the next iteration, if there are more complaints.
(In reply to Urmas from comment #4) > You can make more space by moving 'Clear direct formatting' into the > 'Styles' menu, where it makes more sense. The 'Styles' menu is for creating, applying, and modifying paragraph and character styles, while the Format menu allows you to apply direct formatting (Bold, Text Alignment, Line Spacing, etc), so why would removing direct formatting be in a different menu? But even if we did move 'Clear direct formatting' to the 'Styles' menu, the Format menu would still be at 24 items.
(In reply to Yousuf (Jay) Philips from comment #3) @Jay, * > (In reply to V Stuart Foote from comment #2) > ... > The .uno:ChangeCaseToLower and .uno:ChangeCaseToUpper commands are permanent > case changes that affect the characters' ascii values, while the 'Capitals' > and 'Lowercase' effects are character style level effects and dont have > equivalent uno commands to my knowledge. Yes, I was wrong, you are correct. The Character dialog Font Effects apply a "revertable" style to selection, while the Change case UNO commands actually change the codepoint for the glyphs. Still seems like this could be made more consistent. And generating Small caps (for fonts that support them, or by style) should be available as an UNO command, but that is another issue. Sorry for the noise.
(In reply to V Stuart Foote from comment #7) > Yes, I was wrong, you are correct. The Character dialog Font Effects apply a > "revertable" style to selection, while the Change case UNO commands actually > change the codepoint for the glyphs. > > Still seems like this could be made more consistent. Yes ideally we should have UNO commands for those as well. > And generating Small caps (for fonts that support them, or by style) should > be available as an UNO command, but that is another issue. Small caps UNO command bug report (bug 87914). Maybe you can modify the enhancement to include making the Lowercase and Uppercase effect commands.
What kind of HIG can approve THREE-LEVEL DEEP menus? It is UNACCEPTABLE.
(In reply to Yousuf (Jay) Philips from comment #3) > According to the OOo stats, Lowercase and Uppercase are the only entries in > the 5 that are highly used, which is why both are now available, but hidden > by default, in the formatting toolbar. That is in line with what I remember from user feed back in all kind of situations. This might be a valid reason to let accessibility prevail over the length of the menu (which indeed is significant, but thanks to clear grouping, good to digest).
(In reply to Urmas from comment #9) > What kind of HIG can approve THREE-LEVEL DEEP menus? It is UNACCEPTABLE. If it was unacceptable, i would assume all office suites would agree with you, but all of these apps have 3-level deep menus - Google Docs, iWork, WPS, MS Office 2003, WordPerfect, AbiWord. It is our intent to include all functions within the menu and to do that in an organizable way, we would need atleast 3 levels. We try hard to keep it within 2 levels, but sometimes things spill over, e.g. Insert > Shape > Basic > Rectangle, but it will be easy to navigate as long as its well organized. (In reply to Cor Nouws from comment #10) > That is in line with what I remember from user feed back in all kind of > situations. This might be a valid reason to let accessibility prevail over > the length of the menu (which indeed is significant, but thanks to clear > grouping, good to digest). As Uppercase and Lowercase are more highly used than the rest and are not character style properties, it would be good to separate these from the other 3 (actually there are 4 others in the menu if you enable asian languages) and also move them up a level in order to reduce navigation. Another reason why is that these commands are now only accessible in the menu by default, as they were removed from the context menu in 5.2. https://gerrit.libreoffice.org/22028