[Libreoffice-ux-advise] [Bug 153127] "Book preview" should be separate from other page preview buttons in Print Preview toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=153127 Dieter changed: What|Removed |Added Whiteboard| QA:needsComment| CC||dgp-m...@gmx.de See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||2976 --- Comment #1 from Dieter --- I support that idea. I must admit, that it's the first time I've recognized print preview toolbar. I would also recommend to remove view options in status bar in print preview (but I will comment this in bug 152976). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153127] "Book preview" should be separate from other page preview buttons in Print Preview toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=153127 QA Administrators changed: What|Removed |Added Whiteboard|| QA:needsComment -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153344] The size of icons in the status bar should be increased to at least 16px and the height of the status bar adjusted to allow this.
https://bugs.documentfoundation.org/show_bug.cgi?id=153344 --- Comment #4 from John Mills --- Sorry, I should say the photo compares, Writer, Word and TextMaker. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153344] The size of icons in the status bar should be increased to at least 16px and the height of the status bar adjusted to allow this.
https://bugs.documentfoundation.org/show_bug.cgi?id=153344 John Mills changed: What|Removed |Added Attachment #185098|Comparison of Status bar|Comparison of Status bar description|Icons, LibreOffice, |Icons, LibreOffice, |MicrosoftOffice 365,|MicrosoftOffice 365, |Kingsoft Office 2021|Softmaker Office 2021 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153344] The size of icons in the status bar should be increased to at least 16px and the height of the status bar adjusted to allow this.
https://bugs.documentfoundation.org/show_bug.cgi?id=153344 --- Comment #3 from John Mills --- This shows the difference by default of the icons in LibreOffice, Microsoft Office and Kingsoft Office. Notice how much smaller the icons are in LibreOffice compared to the other two. >From Top to bottom: LibreOffice Microsoft Office Softmaker Office -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153344] The size of icons in the status bar should be increased to at least 16px and the height of the status bar adjusted to allow this.
https://bugs.documentfoundation.org/show_bug.cgi?id=153344 --- Comment #2 from John Mills --- Created attachment 185098 --> https://bugs.documentfoundation.org/attachment.cgi?id=185098=edit Comparison of Status bar Icons, LibreOffice, MicrosoftOffice 365, Kingsoft Office 2021 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153344] The size of icons in the status bar should be increased to at least 16px and the height of the status bar adjusted to allow this.
https://bugs.documentfoundation.org/show_bug.cgi?id=153344 V Stuart Foote changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vsfo...@libreoffice.org --- Comment #1 from V Stuart Foote --- The icons are of course not 10px they are 16px with padding. But, it could be helpful to provide an Icon Size option for the status bar--similar to the Tools -> Options -> View selectors for Toolbar, Notebookbar and Sidebar-- where UI responds to icons size of: Small (16px), Large (24px) or Extra Large (32px), or as scaled for HiDPI. On Large icon selection, text size should probably increase and more data elements would be hidden from view on the Status bar, continuing to use current element collapse sequence. So reasonable. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153352] Promote/Demote level list should be in the Tabbed interface
https://bugs.documentfoundation.org/show_bug.cgi?id=153352 V Stuart Foote changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vsfo...@libreoffice.org --- Comment #1 from V Stuart Foote --- +1, for lists in a textbox we do a layout adjustment rather than an outline adjustment now. So, would replace the Tabbed NB use of .uno:DecrementIndent .uno:IncrementIndent to instead use .uno:OutlineLeft .uno:OutlineRight to match usage in the SB Properties "Lists" panel. But do we still need the layout adjustment (e.g. for graphical bullets)? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153335] Establishing a keyboard shortcut is doubly counter-intuitive
https://bugs.documentfoundation.org/show_bug.cgi?id=153335 --- Comment #8 from V Stuart Foote --- While here a duplicate of bug 115527 (and its dupes), please note the UI function of the Customize dialog's Keyboard panel is equally to make shortcut assignments, but also to inspect assignments already in place. The listing of Keys (those available to Shortcut assign) is sequential and logically grouped. While filtering might be useful, a search against the Keys would be of limited use. Actions/Functions can be filtered by the Category a function is assigned/performs, and at the 5.4 release actions/functions can be searched by name. Where a function has an shortcut key assignment made that assignment is indicated in the lower right Keys panel following search--to help (along with the pop-up description) to identify the correct function. So in practice the Shortcut Keys panel on top makes the most sense: both to visually review existing assignments, and to select the shortcut that would be modified/assigned. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153335] Establishing a keyboard shortcut is doubly counter-intuitive
https://bugs.documentfoundation.org/show_bug.cgi?id=153335 V Stuart Foote changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Blocks||41560 --- Comment #7 from V Stuart Foote --- *** This bug has been marked as a duplicate of bug 115527 *** 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 on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153335] Establishing a keyboard shortcut is doubly counter-intuitive
https://bugs.documentfoundation.org/show_bug.cgi?id=153335 --- Comment #6 from V Stuart Foote --- (In reply to nicholasjoll from comment #4) And that is why it is documented, for when visual inspection may not be sufficient. Establishing or overriding/modifying keyboard shortcut navigation is NOT an inherently trivial or intuitive action. In other words we really do prefer that users RTM. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153335] Establishing a keyboard shortcut is doubly counter-intuitive
https://bugs.documentfoundation.org/show_bug.cgi?id=153335 --- Comment #5 from nicholasj...@mailfence.com --- Here is what I suggest. A) Move the 'Shortcut keys' section to the top of the window and rename it to: 'Keyboard shortcut to assign. (Select shortcut or type it.)'. Or something like that. B) Within that same section - the one currently entitled 'Shortcut keys' - have a box labelled, 'Type key(s)'; that box should accept key combinations and display them. (I imagine there might be some difficulty implementing this but other software has managed it.) C) Change the 'Modify' button to read 'Assign'. Better: have it read 'assign' when at present no function is assigned to they key combination, and have it read 'modify' otherwise. Or something like that. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153335] Establishing a keyboard shortcut is doubly counter-intuitive
https://bugs.documentfoundation.org/show_bug.cgi?id=153335 --- Comment #4 from nicholasj...@mailfence.com --- @V Stuart Foote Thank you for the links to documentation. I take it that by, 'Select Key to target' you mean: select the key from the list that appears under the heading, 'Shortcut Keys'. Forgive me, but I remain unconvinced that the current procedure is intuitive. Here is why. i) The procedure has one start at the _the bottom_ of the window (with 'Category' and 'Function') and subsequently move to the _the top_ of the window (to 'Shortcut Keys'. (Or such anyway was the order of actions that you proposed.) ii) In the 'Shortcut keys' box, one cannot _type_ a key combination. Rather one has to scroll (and scroll some more) and then select a key. iii) Clicking a button labelled 'Modify' in order to _create_ a keyboard shortcut _ex nihilo_ does not seem intuitive. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153335] Establishing a keyboard shortcut is doubly counter-intuitive
https://bugs.documentfoundation.org/show_bug.cgi?id=153335 V Stuart Foote changed: What|Removed |Added Status|NEW |UNCONFIRMED Severity|normal |enhancement Ever confirmed|1 |0 Component|Writer |UI --- Comment #3 from V Stuart Foote --- The workflow is already intuitive AND *documented* [1] [2] Select UI module to affect or Entire UI by Radio button Select action/control/function to be assigned Select Key to target Select Modify to Complete assignment IMHO => NAB and a => WF for any enhancement =-ref-= [1] https://help.libreoffice.org/7.6/en-US/text/shared/01/06140200.html?DbPAR=SHARED#bm_id2322763 [2] https://books.libreoffice.org/en/GS74/GS7413-CustomizingLO.html#toc15 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153335] Establishing a keyboard shortcut is doubly counter-intuitive
https://bugs.documentfoundation.org/show_bug.cgi?id=153335
--- Comment #2 from nicholasj...@mailfence.com ---
Regina: thank you for your comment; I believe that my previous post contains
the answer to your question. For, see the 'additional information' section of
that post. But in short: to my knowledge, other applications get one to choose
the function first and the shortcut second.
Also: I have been involved in a somewhat illuminating forum discussion about
the counter-intuitiveness, or otherwise, of LibreOffice's way of assigning
keyboard shortcuts. Here is something that I ended up writing there ('there'
being the following URL:
https://ask.libreoffice.org/t/i-cannot-see-how-to-enter-custom-keyboard-shortcuts/87362/7).
=== [Start of quotation] ===
I suspect that it is not the whole truth about intuitiveness that it is ‘only
the continuation of a previous habit’. I grant though that intuitiveness is at
least partly that. So my criticism was too blunt. That said: if most software
does some thing in some single way, and there is little net advantage in doing
it a different way, then surely it is best to, so to speak, go with the flow .
.
=== [End of quotation] ===
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 145324] I am missing the “Provide feedback with sound" Word feature
https://bugs.documentfoundation.org/show_bug.cgi?id=145324 Dieter changed: What|Removed |Added Keywords||needsUXEval CC||dgp-m...@gmx.de, ||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #3 from Dieter --- Since it is an enhancement request, let's ask design-team for further input and decision. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153335] Establishing a keyboard shortcut is doubly counter-intuitive
https://bugs.documentfoundation.org/show_bug.cgi?id=153335 Regina Henschel changed: What|Removed |Added Ever confirmed|0 |1 CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||rb.hensc...@t-online.de Status|UNCONFIRMED |NEW Keywords||needsUXEval --- Comment #1 from Regina Henschel --- I agree, the workflow is not intuitive. How is the workflow to define a short cut key in other applications? Would be interesting to know. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153334] Support/default to a non-white page background in Dark Mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153334 Eyal Rozenberg changed: What|Removed |Added Summary|Support/default to a|Support/default to a |non-white background in |non-white page background |Dark Mode |in Dark Mode Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED --- Comment #6 from Eyal Rozenberg --- I do not consider the color of _pages_ of content as a part of an application's UI theme. It's a different kind of setting. And I doubt - though I may be wrong - that page colors, as opposed to UI element colors, are part of the "system defaults". PS - I don't really have a dog in this fight personally since I don't use Dark Mode on my PC. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153322] RFE: Add Macro Security Settings button to macro infobar
https://bugs.documentfoundation.org/show_bug.cgi?id=153322 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Ever confirmed|0 |1 Blocks||107659 Keywords|needsUXEval | Status|UNCONFIRMED |NEW --- Comment #1 from Heiko Tietze --- Sounds reasonable. Could be labelled "Options" or better "Macro Security". Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=107659 [Bug 107659] [META] Macro bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153321] Notebook Bar (MUFFIN) separator color inconsistent in dark mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153321 --- Comment #5 from Heiko Tietze --- And I super dislike the hard contrast between full black and full white (it looks like high contrast mode; the Microsoft designers put surely a lot of effort into a good set of colors). We aim to follow the system default and should do it as well here. My take: BUG -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152184] Dark Mode: Application Colors > Color Scheme should automatically follow System Settings > Appearance
https://bugs.documentfoundation.org/show_bug.cgi?id=152184 Heiko Tietze changed: What|Removed |Added CC||eyalr...@gmx.com --- Comment #13 from Heiko Tietze --- *** Bug 153334 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] [Bug 153334] Support/default to a non-white background in Dark Mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153334 Heiko Tietze changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Heiko Tietze --- Using system defaults for the UI is mandatory, and the ability to override the default very much desirable (bug 153229). But I disagree with the *need* to match the two sets as we primarily do WYSIWYG editing - black ink on white paper. The option to change it back and forth makes sense in some scenarios and we made it possible. So the WF verdict on bug 152184 is still true, IMO. I envision a LibreOffice theme that allows to change both system and application colors at once, if both are defined otherwise it would use the automatic colors. And I'm not against a dedicated dialog to pick the color combination similar to the UI chooser. *** This bug has been marked as a duplicate of bug 152184 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153334] Support/default to a non-white background in Dark Mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153334 --- Comment #4 from steve --- I disagree with #152184 being wontfix. Automatically following OS system theme is standard behavior users have come to expect. This bug here seems to be yet another duplicate of what was requested in https://bugs.documentfoundation.org/show_bug.cgi?id=152184 proving that users expect document background to follow theming (as other apps do). @Eyal: If you agree, could you set to duplicate? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152184] Dark Mode: Application Colors > Color Scheme should automatically follow System Settings > Appearance
https://bugs.documentfoundation.org/show_bug.cgi?id=152184 steve changed: What|Removed |Added Summary|macOS: dark mode: |Dark Mode: Application |Application Colors > Color |Colors > Color Scheme |Scheme should automatically |should automatically follow |follow System Settings >|System Settings > |Appearance |Appearance -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153321] Notebook Bar (MUFFIN) separator color inconsistent in dark mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153321 --- Comment #4 from Stéphane Guillou (stragu) --- I misread the report and thought the request was to make the default toolbar use the brighter colour for separators, which I think makes more sense. Regarding consistency: the distinction between standard vs MUFFIN is disappearing and mainly relevant to developers. For users, it is not particularly relevant and the main visible distinction is the UI dialog's separation between the top two (standard and tabbed) and the rest below. That might be why the inconsistency can be more surprising to them. I think the standard toolbar could benefit from more visible separators... So maybe a solution is to use a consistent in-between colour for all? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152184] macOS: dark mode: Application Colors > Color Scheme should automatically follow System Settings > Appearance
https://bugs.documentfoundation.org/show_bug.cgi?id=152184 Stéphane Guillou (stragu) changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||3334 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153334] Support/default to a non-white background in Dark Mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153334 Stéphane Guillou (stragu) changed: What|Removed |Added CC||stephane.guillou@libreoffic ||e.org See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||2184 --- Comment #3 from Stéphane Guillou (stragu) --- I think this was discussed in bug 152184 and considered a "won't fix", at least for the automatic change as a default. But maybe there's a good argument for better discoverability of the combination of following OS dark mode + LO application colors' dark theme. -- You are receiving this mail because: You are on the CC list for the bug.
