"Edit Style...", "Update Style..." and "New Style..." in menus, toolbars, sidebars, etc. should be renamend to "Edit Paragraph Style...", "Update Paragraph Style..." and "New Paragraph Style..." because they only apply to paragraphs and not to character or other styles although, for example, a frame and not a frame content is selected. The wording "style" simplifies the styles concept of LibO in a way that the user will be confused. Style is not only paragraph style. Steps to reproduce: See tooltips in Formatting toolbars or tooltips in the properties sidebar or the entry namings in the Styles menus.
thanks Thomas! > New
The problem is that these commands were previously only in the sidebar, and i added them to the menubar and toolbar, so they only took into account which tab of the styles and formatting deck of the sidebar was active, and that is what needs to be corrected. They need to work correctly based on where they are executed from based on context.
@Maxim: Would it be easy to add an argument to these commands so that they work with other style families, as the logic is already there for it based on which tab of the styles & formatting deck you are on. examples .uno:EditStyle?FamilyName:string=CharacterStyles .uno:StyleUpdateByExample?FamilyName:string=NumberingStyles .uno:StyleNewByExample?FamilyName:string=FrameStyles
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Thomas Lendo, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Adding Heiko and Andreas to CC list as they know about toolbar/sidebar/notebookbar command naming incl. tool tips and can change it. :) Is this something you can work on?
The UNO commands are used for both paragraph and character style, at least, at the sidebar. So we have to apply the label conditionally, or introduce different commands. However, I'm rather for not changing the label to keep the code clean. It's not much of a surprise that "Edit Style" shows the dialog with paragraph properties.
In reply to Thomas Lendo from comment #0) > the entry namings in the Styles menus. fwiw framework/dtd/menubar.dtd indicates "label" is an attribute for menuitem. It would be possible to change the command names in the Styles menubar for Writer without changing the .uno labels. I am willing to make changes in the Writer menubar (alone) -- if such a limited, ad hoc change, is not opposed. But have you considered that there are also many popup menus and menus (e.g., forms, report, web) that use these commands, so if an adhoc solution (beyond the main menubar) was required, then it would involve examining all these variations -- while yet another solution is required for all the notebookbars. (similar issues appear in Calc, Draw and Impress). > See tooltips in Formatting toolbars or tooltips in the properties sidebar This is difficult to address at present because the same tooltip is used in Calc (where cell styles are updated and created) and in Draw/Impress for objects. As noted in comment 2 and comment 7, contextual tests are needed, and more importantly, new functionality is required (see comment 3) for it to make sense to have these contextual tooltips. As for comment 7: > It's not much of a surprise that "Edit Style" shows the > dialog with paragraph properties. Hard to evaluate the reasons behind that assessment...but "surprise" usually involves violation of expectations. In the Style menubar context ....there are many characteristics that afford an expectation that "Edit Style..." can be used for all style families...which is what motivates the offer to change the Style menubar in Writer.
(In reply to sdc.blanco from comment #8) > fwiw framework/dtd/menubar.dtd indicates "label" is an attribute for > menuitem. > > It would be possible to change the command names in the Styles menubar for > Writer without changing the .uno labels. > > I am willing to make changes in the Writer menubar (alone) -- if such a > limited, ad hoc change, is not opposed. Please don't. This "menu:label" thing is not translatable, and only meant to store user customization, not to be used during development.
Thanks for clarification Maxim. iiuc, then there is no easy way at present to satisfy the OP request (in the sense of adjusting a few labels somewhere). Is it fair to say that new (nontrivial?) backend functionality is required?
(In reply to sdc.blanco from comment #10) > iiuc, then there is no easy way at present to ... adjusting a few labels > somewhere). That's why we introduced the "TargetURL" property for commands. With it you can create as many shortcuts as you want, with different labels and icons, all pointing to the same underlying "real" command. The only problem is that it doesn't work for buttons in the NB (but it does for menu buttons there), and that part might need some development. The other thing you should keep in mind is that "commands" created using "TargetURL" are just shortcuts not real commands, so they won't appear as available commands in the customization dialog.
With insight from comment 11, it should be possible (and not ad hoc) to: 1. make new ”shortcuts” in officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu - using TargetURL pointing to the current .unos that appear in the Styles menu in Writer. - with desired labels for Styles menu in these shortcuts 2. Modify sw/uiconfig/swriter/menubar/menubar.xml to point to these new shortcuts. Concretely in relation to Styles menubar in Writer, the new labels could be: ”Edit Style…” → ”Edit Selected Paragraph Style” ”Update Selected Style” → ”Update Selected Paragraph Style” ”New Style from Selection” → ”New Paragraph Style from Selection” too long labels? Use ”current” instead of ”selected” ? (because for paragraph style, only need to have cursor placed in paragraph)