Created attachment 121026 [details] text box and shape entry in Format (top) and Insert (bottom) menu In both Insert and Format menu in Writer, there is "Text Box and Shape" submenu item which should be labelled as "Object" instead. Observed in 5.1 beta 2, Ubuntu 15.10.
Confirmed. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: 81fa5340191baf8687f9c82f1f414f5afc86b529 Threads 4; Ver: Windows 6.1; Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-03_21:19:19 Locale: fi-FI (fi_FI)
The Insert menu item was changed back to "Object" in 900a22c9ef53d8597570ccd1fa8a7a6106006f32, but the Format menu still has "Text Box and Shape".
(In reply to Maxim Monastirsky from comment #2) > The Insert menu item was changed back to "Object" in > 900a22c9ef53d8597570ccd1fa8a7a6106006f32, but the Format menu still has > "Text Box and Shape". Yes that is what i have changed it to in the Format menu. :D
Ok, so the name under Format is intentional.. Let's set this to FIXED concerning Insert, then.
> Yes that is what i have changed it to in the Format menu. :D This is wrong - because the submenu applies also to e.g. formula (which is not text box or shape). Setting to reopened.
(In reply to Stanislav Horacek from comment #5) > This is wrong - because the submenu applies also to e.g. formula (which is > not text box or shape). Submenu's labels cant always cover everything that is available in the submenu and the only entry in Format > Text Box and Shape related to formulas and other objects is 'Area...'. Writer treats objects differently than in other apps, which is why having a different submenu label was chosen.
> Submenu's labels cant always cover everything that is available in the > submenu and the only entry in Format > Text Box and Shape related to > formulas and other objects is 'Area...'. Writer treats objects differently > than in other apps, which is why having a different submenu label was chosen. I disagree. Of course labels can't be totally descriptive, but taking a small subset of actual meaning is not wise at all. As user I don't care how Writer treats objects, I just want to find commands in menu in a consistent way. And now I insert my formula by Insert -> Object, format it by Format -> Text Box and Shape in Writer and by Format -> Object in Calc - simply confusing. I'm afraid that such arbitrary changes will only cause that next time someone else will change it other way round with all negative consequences (translations, docs, etc.).
I agree with comment #7 by Stanislav. "Text Frame and Shape" will say nothing to users willing format other kind of object like formula. Please keep consistency with other menus and modules. Reopening and adding ux-advise ML for its opinion. Additionally, please take care of translators when you play with menu and button labels. Best regards. JBF
(In reply to Stanislav Horacek from comment #7) > As user I don't care how Writer treats objects, I just want to find commands > in menu in a consistent way. And now I insert my formula by Insert -> > Object, format it by Format -> Text Box and Shape in Writer and by Format -> > Object in Calc - simply confusing. No in Writer you format objects with Format > Frame and Object > Properties, which previously was Format > Frame/Object.
To NEW rather than REOPENED. @Maxim, Jay (In reply to Maxim Monastirsky from comment #2) > The Insert menu item was changed back to "Object" in > 900a22c9ef53d8597570ccd1fa8a7a6106006f32, but the Format menu still has > "Text Box and Shape". Not sure the "_Object" label revert was in there. Otherwise believe this rework is the correct handling. Revert to "Object" label on the Insert menu, and the grouped label(s) on the Format menu as implemented. But, I would suggest duplicating the Area button to the "Frame and Object" split button. And, could Text Box and Shape format sub-menu then be contextually "disabled" when selection being formatting is not of that variety? And, is there any scenario with work on SdrObjects that Writer's use of Text Box and Shape objects will gain a properties dialog? May need to accommodate that as well on the sub-menu, even if it is inactive. =-ref-= https://gerrit.libreoffice.org/#/c/20167/
(In reply to V Stuart Foote from comment #10) > Not sure the "_Object" label revert was in there. Yep it was and you can test master to confirm. :D > But, I would suggest duplicating the Area button to the "Frame and Object" > split button. And, could Text Box and Shape format sub-menu then be > contextually "disabled" when selection being formatting is not of that > variety? Area isnt needed to be duplicated in 'Frame and Object' as the Frame and Object Properties dialog has an Area tab. Regarding the disabling of submenus, no that isnt possible as the menu bar doesnt function that way of hiding/disabling submenus based on context. > And, is there any scenario with work on SdrObjects that Writer's use of Text > Box and Shape objects will gain a properties dialog? May need to > accommodate that as well on the sub-menu, even if it is inactive. Didnt understand what you meant here.
(In reply to Yousuf (Jay) Philips from comment #11) > (In reply to V Stuart Foote from comment #10) > > Not sure the "_Object" label revert was in there. > > Yep it was and you can test master to confirm. :D > Yep, it is there on the TB62 2015-12-08_23:31:1 build at 6fd3f3caad1a559165dc9332249cbd0d84930775 Can see it now, I missed how changing the .uno:ObjectMenu in the WriterCommands.xcu to .uno:FormateObjectMenu would revert the label to use the .uno:ObjectMenu in the GenericCommands.xcu > > But, I would suggest duplicating the Area button to the "Frame and Object" > > split button. And, could Text Box and Shape format sub-menu then be > > contextually "disabled" when selection being formatting is not of that > > variety? > > Area isnt needed to be duplicated in 'Frame and Object' as the Frame and > Object Properties dialog has an Area tab. Regarding the disabling of > submenus, no that isnt possible as the menu bar doesnt function that way of > hiding/disabling submenus based on context. > Yes Area is integrated into the Properties dialog(s). But the UI glitch on the Format sub-menu is that the Area button (.uno:FormatArea) in the "Text Box and Shape" menu goes active when either a Frame or an OLE object is selected. Should there be a set of .uno commands for the Area formatting by object type? Now they're all using the generic .uno:FormatArea > > And, is there any scenario with work on SdrObjects that Writer's use of Text > > Box and Shape objects will gain a properties dialog? May need to > > accommodate that as well on the sub-menu, even if it is inactive. > > Didnt understand what you meant here. Sorry, just thinking out loud... the DrawingLayer SdrModel and SdrObjects/SdrPage are getting a hard look, although it is probably premature to worry too much about changes to the UI. But a good chance the DrawingLayer object controls will be unified--and that draw elements could individually get properties dialogs both in Draw, and when used in the other components as we're doing here with lines, shapes and symbols. There still would be the different object types--but they'd could potentially have consistent controls and behavior. Discussions around bug 95812 and various notes on Armin Weiss's preliminary work in his aw080 branch of OpenOffice
Going to set this Resolved Fixed. The label on the Insert menu has been corrected, and the additional grouped sub-menus on the Format menu are reasonable to purpose. Doing something clever with the Area control widget would be better as a new enhancement.
Now I see reasoning behind the change: objects in Writer are divided into "text boxes and shapes" and other object. As Stuart pointed out, this is not clear when "Text Box and Shape" item and "Area" subitem are enabled for other objects. But still - this way of thinking: in Writer: object is Formula, Chart, OLE Object, etc. in other modules: object is Text Box, Shape, Formula, Chart, OLE Object, etc. is something which reflects rather software implementation than user's point of view and breaks consistent experience within all modules.
(In reply to V Stuart Foote from comment #12) > Yes Area is integrated into the Properties dialog(s). But the UI glitch on > the Format sub-menu is that the Area button (.uno:FormatArea) in the "Text > Box and Shape" menu goes active when either a Frame or an OLE object is > selected. Yep Area should likely be disabled when selecting a frame or ole object. > Should there be a set of .uno commands for the Area formatting by object > type? Now they're all using the generic .uno:FormatArea Didnt follow. > Sorry, just thinking out loud... the DrawingLayer SdrModel and > SdrObjects/SdrPage are getting a hard look, although it is probably > premature to worry too much about changes to the UI. But a good chance the > DrawingLayer object controls will be unified--and that draw elements could > individually get properties dialogs both in Draw, and when used in the other > components as we're doing here with lines, shapes and symbols. There still > would be the different object types--but they'd could potentially have > consistent controls and behavior. Went right over my head. ;D (In reply to Stanislav Horacek from comment #14) > Now I see reasoning behind the change: objects in Writer are divided into > "text boxes and shapes" and other object. Well actually the main issue is that only in Writer have different categories of objects have been defined, which is why Writer has for example image objects and its properties are in Format > Image > Properties, while in other apps you have find the properties in Format > Object.