[Libreoffice-ux-advise] [Bug 127157] Add the ability to store comments within palette files (.soc)
https://bugs.documentfoundation.org/show_bug.cgi?id=127157 --- Comment #2 from Jean-Francois Nifenecker --- Hi Stuart, I can certainly live without the UI tooltips. But such was not my primary question. The main concern is about adding comments. The XML commenting string exists but doesn't fit the whole bill as its granularity is too coarse: the XML commenting scheme is, IMO, meant to add information at the *file* level (in the attachment, there's such a comment showing how the file was generated). Commenting each color individually should be a property for that color which would make things easier to manage at the color data level. As for the global comment, here also, having a global comment property would be clearer that this information is data. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127157] Add the ability to store comments within palette files (.soc)
https://bugs.documentfoundation.org/show_bug.cgi?id=127157 V Stuart Foote changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||rb.hensc...@t-online.de, ||vstuart.fo...@utsa.edu Keywords||needsUXEval --- Comment #1 from V Stuart Foote --- Not true, XML commenting is already available and is extensively used to annotate the .SOC/.SOG within palette files. But beyond the text string assigned to Color name, nothing additional is exposed to the GUI. For additional detail in the GUI ODF 1.2 does not provide annotation for the draw:color; and beyond LO using the draw:name assigned to tooltip text on selection/mouse over nothing is provided. No draw:comment is provided and would require extending ODF. Not clear it is worth the effort--the installation share/palette directory is readily available to review the commenting, and not clear anything is gained exposing additional details to the GUI. IMHO => WF -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127174] Search dialog doesn't support "whole word only" option
https://bugs.documentfoundation.org/show_bug.cgi?id=127174 V Stuart Foote changed: What|Removed |Added Keywords||needsUXEval Severity|normal |enhancement CC||er...@redhat.com, ||libreoffice-ux-advise@lists ||.freedesktop.org, ||vstuart.fo...@utsa.edu --- Comment #1 from V Stuart Foote --- Hmm, we already use ICU libs for regex and word bounds are already integral. Imagine it would not be too much of a stretch to use ICU word bounds in a search option. @Eike? -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 125759] UI: Notes View: "Move element cursor" instead of "edit text cursor"
https://bugs.documentfoundation.org/show_bug.cgi?id=125759 --- Comment #5 from BottleOnTheGround --- An idea to reduce this problem: - mouse-up within the text area => go to text edit mode - mouse-down and hold within textbox area (, perhaps move cursor around) => select text box and drag around (no edit mode) - ctrl + mouse-up within textbox area => select text box (multiselect, if others were selected before) - mouse-down / up on border of text box => select text box If you're willing to think about it, I could provide a simple html example of that behaviour for UI experience testing. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 103694] Rename file without having to save again as a new file.
https://bugs.documentfoundation.org/show_bug.cgi?id=103694 --- Comment #13 from espinosa_cz --- > Simple solution: close -> rename -> reopen. And remember the current position. That was my implementation assumption too. If you deem it too complicated, I would have perhaps a simpler idea: "deferred renaming". The actual, physical renaming would be done after user closes the document. At least on platforms not supporting opened file renaming, like Windows. LO just need to display modified "Save changes to document" dialog informing that rename is going to happen and user can still have option to cancel and not go through. Also on the UI level the name should be displayed in a different font color indicating that the physical rename hasn't happened yet. I know, it's not ideal, but for most user, like me, it would still make my work much easier. I have lost of documents and I like consistent naming which is difficult to achieve, because you have to first, open the file and to see the content, to decide on the name, but you cannot, because it is open. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127123] Feature Request: Introduce Recently Used Fonts in Font Name drop-down list
https://bugs.documentfoundation.org/show_bug.cgi?id=127123 Maxim Monastirsky changed: What|Removed |Added CC||momonas...@gmail.com --- Comment #7 from Maxim Monastirsky --- As Stuart pointed out, we already have this feature of listing the last 5 chosen fonts. The list is stored in the user profile in the user/config/fontnameboxmruentries file, and we even have an expert config option to enable/disable this feature (org.openoffice.Office.Common.Font.View.History). So I'm not sure why it doesn't work for Pedro, maybe there's some bug involved here. I would suggest at first to check the expert config, or even reset the user profile completely, and see if that helps. One problem that I did notice while testing this, is what happens when there are several font name controls visible at the same time. This might be because of several open documents, but as well might be in a single document, if both the formatting toolbar and the sidebar are visible. It appears that each font name control manages the MRU list on its own, and they're not synced. Moreover, each control updates the fontnameboxmruentries file on its own when destroyed, so the final contents of the fontnameboxmruentries file determined by the control destroyed last, which might or might not be the one where the user selected his fonts last. In my testing I was selecting fonts in the toolbar control, and they appeared in the MRU list at first, but not after restarting Writer. The problem turned out to be with the sidebar. Everything went fine after I disabled the sidebar via View > Sidebar. So that's another thing to watch out. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127123] Feature Request: Introduce Recently Used Fonts in Font Name drop-down list
https://bugs.documentfoundation.org/show_bug.cgi?id=127123 --- Comment #6 from Pedro --- > Consider more than one projects where completely different fonts are used. > Would be annoying to list the arty Comic for your thesis, right? In the > other (more common) scenario you create similar documents where the > preferred font should always be at hand. So what actually is need is both, > per document and some kind of favorite. I would make this a duplicate of bug > 91130. What do you think, Pedro? I disagree. Bug 911130 refers to something completely different. >My idea is that the font name drop down list will begin with containing only a >>short list of fonts that are commonly used and available on a user's system >(e.g. >Liberation Serif, Times New Roman, Liberation Sans, Arial, etc) and >additional >fonts will be added to the list according to the following >scenarios. >1) A user opens a document which contains fonts not already shown in the list >2) A user clicks on a 'More Fonts...' entry at the bottom of the list and >selects >to use a particular font in the character dialog's font tab Now, the discussion over there drifted to overlap this bug. IMO, the use case you mention is something different. It's to have a list of preferred fonts at the top of the drop-down list, NOT the most recently used. That's something that could be done in a different manner: allow the user to pin fonts to the top of the drop-down menu. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127066] UI: Font size in input line (formular bar) larger than in other UI elements
https://bugs.documentfoundation.org/show_bug.cgi?id=127066 --- Comment #9 from Thorsten Wagner --- Change submitted to Gerrit: https://gerrit.libreoffice.org/78140/ -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127142] UI: Add 'Numbering Off' command to Format > Lists submenu
https://bugs.documentfoundation.org/show_bug.cgi?id=127142 --- Comment #10 from Maxim Monastirsky --- (In reply to Heiko Tietze from comment #9) > How about listing this particular user style, if active, among the > preselection plus Off? That's likely the solution, but my point was that it isn't possible to do as long as it's a static menu (i.e. fully defined in xml). For this we'll need a dynamic menu which we can change at runtime (much like File > Recent Documents, or View > Toolbars), to add/remove the user style. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127142] UI: Add 'Numbering Off' command to Format > Lists submenu
https://bugs.documentfoundation.org/show_bug.cgi?id=127142 --- Comment #9 from Heiko Tietze --- (In reply to Maxim Monastirsky from comment #7) > Because not all styles are listed there, and users can > create their own styles. So again there is a possibility for the "none > activated" state. How about listing this particular user style, if active, among the preselection plus Off? -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127115] language-agnostic styles
https://bugs.documentfoundation.org/show_bug.cgi?id=127115 --- Comment #8 from Heiko Tietze --- As for the feedback I'd hope to solve it with the style inspector proposed in bug 115311. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127115] language-agnostic styles
https://bugs.documentfoundation.org/show_bug.cgi?id=127115 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #7 from Regina Henschel --- The problem is this: Actually, language is a property of character portions. However, the paragraph can have a default language. This is used if the characters do not have their own language setting. The problem in your case is, that if you select an entire paragraph, then the choosen language is not applied to the characters, but it is set as default language into the paragraph. If you then apply a new paragraph style it will use the default of that new style. For to set a language to a portion of text, define a _character_ style with that language. To change the language of the text portion, apply that style. In this case the "portion" may be an entire paragraph. If you look into the generated file, the difference is, whether a element with a "Tn" (or your own character style name) style exists, or there is only the element with a "Pn" (or your own paragraph style name) style. There is indeed a UX problem: It is not clear, what happens, if an entire paragraph is selected and something is done with this selection. Sometimes the setting is uses as paragraph property, sometimes as character property. Only the assignment of a character style seems to reliably generate the elements, needed for multi-language documents. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127142] UI: Add 'Numbering Off' command to Format > Lists submenu
https://bugs.documentfoundation.org/show_bug.cgi?id=127142 --- Comment #8 from Maxim Monastirsky --- (In reply to Dieter Praas from comment #6) > Thanks for clarification, but can a new user (or also en exeprienced user) > be aware of that: There is no hint, that context menu affects styles: > - context menu => bullets and numbering => bullets and numbering doesn't > open list style dialog (the dialog is "Bullets and Numbering"). There is a similar situation with the Character and Paragraph sub menus of the context menu: Single direct formatting item on the top, followed by style commands. Confusing indeed. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127142] UI: Add 'Numbering Off' command to Format > Lists submenu
https://bugs.documentfoundation.org/show_bug.cgi?id=127142 --- Comment #7 from Maxim Monastirsky --- (In reply to Heiko Tietze from comment #4) > AFAIK, "Numbering Off" is a different command than the numbering styles but > would be required to toggle on/off with those. It doesn't need to interact with the other commands, just to provide an on/off state on its own (which then can be visually represented as a radio button). > Actually the current radio buttons list of styles has none > activated, which is wrong usability wise. True, but just want to point out that as long as this sub menu is static, it won't be possible to fully solve this problem by just providing the "Numbering Off" item. Because not all styles are listed there, and users can create their own styles. So again there is a possibility for the "none activated" state. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127142] UI: Add 'Numbering Off' command to Format > Lists submenu
https://bugs.documentfoundation.org/show_bug.cgi?id=127142 --- Comment #6 from Dieter Praas --- (In reply to Maxim Monastirsky from comment #5) > (In reply to Dieter Praas from comment #1) > There's some confusion here: The items in the context menu are applying > styles (they correspond to the same items under the Styles menu), while the > items in Format > List menu are about direct formatting Thanks for clarification, but can a new user (or also en exeprienced user) be aware of that: There is no hint, that context menu affects styles: - context menu => bullets and numbering => bullets and numbering doesn't open list style dialog (the dialog is "Bullets and Numbering"). According to your comment, this is a bug? - with the other option you change the style, but doesn't modify it In summary: Yes, confusing. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127142] UI: Add 'Numbering Off' command to Format > Lists submenu
https://bugs.documentfoundation.org/show_bug.cgi?id=127142 --- Comment #5 from Maxim Monastirsky --- (In reply to Dieter Praas from comment #1) There's some confusion here: The items in the context menu are applying styles (they correspond to the same items under the Styles menu), while the items in Format > List menu are about direct formatting (they correspond to the toolbar bullet and numbering toggle buttons). So: > different names: "Bullet list" ans "number list" in context menu; "bulleted > list" and "numbered list" in Format => list Given that they're not the same, not necessarily they need to have same names. > in Format => List you can remove list, if you click on marked "Bulleted > List"; in context menue this is not possible Right. "Bulleted List" in Format > List is about direct formatting, which you can toggle on and off, like any other direct formatting (e.g. Bold). While the context menu items are actually styles, and it doesn't make sense to "toggle" styles. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127115] language-agnostic styles
https://bugs.documentfoundation.org/show_bug.cgi?id=127115 l...@royal.net changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED|UNCONFIRMED --- Comment #6 from l...@royal.net --- Not Locale, but Default Language for Documents, but that's beside the point. Default language is applied to the whole document, changing it will comprehensively screw up language information of a multilingual document - exactly the issue I am trying to avoid. If you type a French word and assign it French language, then a German word and assign it German language, and then change Default language to English US it will be changed for both of these words. What I am looking for is the ability to change styles while preserving language information (content!) intact: apply heading style and keep one word German and another French. As for creating separate styles for each language, I sincerely hope you are joking. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127115] language-agnostic styles
https://bugs.documentfoundation.org/show_bug.cgi?id=127115 Heiko Tietze changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #5 from Heiko Tietze --- Language of styles is bound to Tools > Options > Language > Locale. Switching from English to French changes the default for Default (and styles based on it). Seems to be kind of agnostic since Default is not always English. And since we are bound to the open document format we cannot change much here. Fortunately you can create templates for all languages you use with the properties you need. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127115] language-agnostic styles
https://bugs.documentfoundation.org/show_bug.cgi?id=127115 Dieter Praas changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #4 from Dieter Praas --- cc: Design-Team for further input -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127140] Feature Request: Right click menu options for frequent documents in Windows 10 taskbar
https://bugs.documentfoundation.org/show_bug.cgi?id=127140 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEW CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Component|LibreOffice |UI OS|All |Windows (All) Keywords|needsUXEval | Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127140] Feature Request: Right click menu options for frequent documents in Windows 10 taskbar
https://bugs.documentfoundation.org/show_bug.cgi?id=127140 --- Comment #2 from Heiko Tietze --- Created attachment 153652 --> https://bugs.documentfoundation.org/attachment.cgi?id=153652=edit Screenshot of quick start on W10 I agree with the request. The quick starter has no recent documents, which is common on Windows. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127123] Feature Request: Introduce Recently Used Fonts in Font Name drop-down list
https://bugs.documentfoundation.org/show_bug.cgi?id=127123 --- Comment #5 from Heiko Tietze --- Consider more than one projects where completely different fonts are used. Would be annoying to list the arty Comic for your thesis, right? In the other (more common) scenario you create similar documents where the preferred font should always be at hand. So what actually is need is both, per document and some kind of favorite. I would make this a duplicate of bug 91130. What do you think, Pedro? -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 87695] SIDEBAR: Improvements to new track changes sidebar tab
https://bugs.documentfoundation.org/show_bug.cgi?id=87695 --- Comment #21 from Heiko Tietze --- (In reply to Heiko Tietze from comment #9) > UX team came up with a solution in... > http://user-prompt.com/de/tracking-changes-with-libreoffice/ It's replicated at https://design.blog.documentfoundation.org/2015/02/19/tracking-changes-with-libreoffice/ -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127098] Improve filter of Track Changes
https://bugs.documentfoundation.org/show_bug.cgi?id=127098 Heiko Tietze changed: What|Removed |Added Summary|Functions to Track and View |Improve filter of Track |Changes should really |Changes |become Useful | Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Heiko Tietze --- We mad a proposal for a TC sidebar deck in https://design.blog.documentfoundation.org/2015/02/19/tracking-changes-with-libreoffice/ and took filtering into account. The respective ticket is bug 87695. As your input tackle more that just the filter please join the discussion on this ticket. *** This bug has been marked as a duplicate of bug 87695 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 87695] SIDEBAR: Improvements to new track changes sidebar tab
https://bugs.documentfoundation.org/show_bug.cgi?id=87695 Heiko Tietze changed: What|Removed |Added CC||adalbert.hans...@gmx.de --- Comment #20 from Heiko Tietze --- *** Bug 127098 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127066] UI: Font size in input line (formular bar) larger than in other UI elements
https://bugs.documentfoundation.org/show_bug.cgi?id=127066 --- Comment #8 from Heiko Tietze --- (In reply to Thorsten Wagner from comment #7) > Preparing a patch to revert font size to 100% of UI font size Please add me to the reviewers. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 125759] UI: Notes View: "Move element cursor" instead of "edit text cursor"
https://bugs.documentfoundation.org/show_bug.cgi?id=125759 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Heiko Tietze --- The cursor changes to a pointer when outside the (note) shapes and to the "i-beam" when at the text area (only in this case you can directly switch to editing per single click otherwise you need to double click the shape). So the problem boils down to how we detect a text area under the cursor. This is a technical limitation not really a bug but admittedly unexpected as the shape is seen as a text box. Unfortunately it's not solvable - and in other situations the expected behavior. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 127142] UI: Add 'Numbering Off' command to Format > Lists submenu
https://bugs.documentfoundation.org/show_bug.cgi?id=127142 Heiko Tietze changed: What|Removed |Added CC||momonas...@gmail.com Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Heiko Tietze --- AFAIK, "Numbering Off" is a different command than the numbering styles but would be required to toggle on/off with those. Not an easy hack, right Maxim? And for the question whether to show or not, I vote for having it at both places. Actually the current radio buttons list of styles has none activated, which is wrong usability wise. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
