[Libreoffice-ux-advise] [Bug 151430] Groupedbar Compact UI : missing "columns..." entry of the "format" menu of the menu bar
https://bugs.documentfoundation.org/show_bug.cgi?id=151430 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||mentoring@documentfoundatio ||n.org Status|UNCONFIRMED |NEW Keywords|needsUXEval |difficultyBeginner, ||easyHack, skillDesign, ||topicDesign Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #5 from Heiko Tietze --- We discussed the topic in the design meeting. The columns seems to be relevant enough to be accessible via the primary UI. We suggest to add it into the Insert menu. Code pointer: sw/uiconfig/swriter/ui/notebookbar_groupedbar_compact.ui Underneath add a similar child with the command .uno:PageColumnType -- 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 Heiko Tietze changed: What|Removed |Added Severity|minor |enhancement Keywords|needsUXEval | Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||c...@nouenoff.nl --- Comment #17 from Heiko Tietze --- We discussed this topic in the design meeting. The convincing argument to not resolve WF likewise bug 152184 is using the night shift with the expectation that app colors (AC) follow. The AC are a user-defined list filled from hard-coded values (some like hyperlinks taken from the OS). Users can add schemes, modify colors, and delete any. We cannot trust in the existence of any scheme and the proposal was to remove AC in favor of hard-coded light and dark colors. (Nothing to say against a customization in terms of personalization aka LibreOffice theme later.) However, there are users who want to change the AC; the idea was to use the shipped AC schemes despite the mentioned issues and just inform the user if something is missing. We could also separate the light/dark AC schemes, add an option to follow the system color, and provide an option to use the user-defined AC. Wouldn't be a simplification but an acceptable compromise. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153727] Calc inputwin for formula bar using system font, too small for CJK input
https://bugs.documentfoundation.org/show_bug.cgi?id=153727 Heiko Tietze changed: What|Removed |Added Hardware|x86-64 (AMD64) |All OS|Windows (All) |All CC|libreoffice-ux-advise@lists |c...@nouenoff.nl, |.freedesktop.org|heiko.tietze@documentfounda ||tion.org Keywords|needsUXEval | --- Comment #20 from Heiko Tietze --- We discussed this topic in the design meeting. a) some comments here are towards resolving as NAB The UI should be kept clean; however, at least based on the number of requests the desire is clear b) add an option to tools > options > calc > view This would be a simple solution but likely not usable as the needed font size in the formula bar depends on cell content. Plus, it inflates the options dialog further. c) have some kind of interaction on the control, could be a drop down with a couple of font sizes or some ctrl+wheel response specifically on the control This possible solution was not prioritized as it would be hard to figure out. d) follow the selected cell's font (maybe all attributes not just the size) Needs some work to make it working reliable (multi-selection) but will always end up in a jumping UI; was removed for bug 127066 e) follow the zoom factor on the sheet Not necessarily what users expect; but would be a straight-forward solution, easy to understand f) show the content somewhere else (or in a tooltip) Was not welcome as a good solution. The question is what issue exactly should be resolved. Make more content visible in the formula bar (the bar has an expander to show almost a novel) or make it better readable. Please elaborate the issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153727] Calc inputwin for formula bar using system font, too small for CJK input
https://bugs.documentfoundation.org/show_bug.cgi?id=153727 Heiko Tietze changed: What|Removed |Added CC||de...@speakeasy.net --- Comment #19 from Heiko Tietze --- *** Bug 88141 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 153561] Rename "Chapter -> Heading" and "E# -> H#" in Entries tab of Insert Table of Contents, Index, Bibliography dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153561 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | Severity|normal |enhancement CC|libreoffice-ux-advise@lists |c...@nouenoff.nl, |.freedesktop.org|heiko.tietze@documentfounda ||tion.org --- Comment #13 from Heiko Tietze --- We discussed this topic in the design meeting. If the modification is consistent for all type of indices the suggested label H# instead of E# (and HI instead of CI) is welcome. (In reply to Mike Kaganski from comment #11) > The E corresponds to "Entries" tab name. It's all about E# / Chapter No (now Heading No). I could live with Entry No too. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152189] styles list "new", plus "DUPLICATE" !
https://bugs.documentfoundation.org/show_bug.cgi?id=152189 Dieter changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||3634 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153634] Page styles: create new "duplicate" copy style
https://bugs.documentfoundation.org/show_bug.cgi?id=153634 Dieter changed: What|Removed |Added CC||dgp-m...@gmx.de, ||libreoffice-ux-advise@lists ||.freedesktop.org Whiteboard| QA:needsComment| Blocks||108576 Keywords||needsUXEval See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||2189 Summary|styles: create new |Page styles: create new |"duplicate" copy style |"duplicate" copy style --- Comment #1 from Dieter --- Since LO doesn't know inherited page styles (feature request in bug 41316), the method described in bug 152189 doesn't work. So we should rethink previous decision - at least for page styles cc: Design-Team Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108576 [Bug 108576] [META] Writer page style bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152775] [Enhancement] Emphasize the entry the mouse pointer is over in the Writer Navigator content tree
https://bugs.documentfoundation.org/show_bug.cgi?id=152775 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | Severity|minor |enhancement CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152775] [Enhancement] Emphasize the entry the mouse pointer is over in the Writer Navigator content tree
https://bugs.documentfoundation.org/show_bug.cgi?id=152775 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO --- Comment #11 from Heiko Tietze --- We discussed this topic in the design meeting (only the bold font weight). First of all it is unclear if the weight changes on hover or on click. Highlighting happens on both events. But more relevant is the missing use case. What problem is resolved by this special handling of tree nodes? Basically it's very clear what node is in focus/hovered. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153561] Rename "Chapter -> Heading" and "E# -> H#" in Entries tab of Insert Table of Contents, Index, Bibliography dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153561
--- Comment #12 from Mike Kaganski ---
And the already made change of the button [Chapter No.]->[Heading No.], and
tooltip (Chapter number->Heading number) would best be "Entry No." ("Entry
number") for consistency.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153561] Rename "Chapter -> Heading" and "E# -> H#" in Entries tab of Insert Table of Contents, Index, Bibliography dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153561 --- Comment #11 from Mike Kaganski --- I definitely dislike [E#]->[H#] change. The E corresponds to "Entries" tab name. It corresponds to "Insert->Table of Contents and Index->Index Entry" menu. It corresponds to [E] (and the relation is unambiguous and natural: "first entry number, then entry text"). It is neutral. The [E] is used in other types of the index (Alphabetical, Table of Figures, ...), so should not be changed itself. The entry can also be created from other types of paragraphs, which may not be headings, but contain numbering. Overall: indexes consist of entries. Introducing "heading" term here does nothing good, but complicates and confuses things. -- 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 --- Comment #15 from Sierk Bornemann --- FYI, just for info, maybe it might help to orientate and maybe follow the same way, because it's not bad and has proved its worth: Microsoft Support document: Dark Mode in Word – Word for Microsoft 365, Word for Microsoft 365 for Mac, Word 2021 https://support.microsoft.com/en-us/office/dark-mode-in-word-e17b79a3-762f-4280-a81c-a15a859a693a#ID0EDD=MacOS Incl. what and how to change the settings to change/adjust the defaults. Sidenote (see screenshots and text in the document): for example, among other things: the default page background in dark mode is: a _dark_ page background, not a white one per default. Dark Mode in Word offers a dark color scheme for both the menu controls and the document background. Dark Mode can help to reduce eye strain and also provides a more modern feel to Word. The dark page background does not convey how your document will print, or the default view your collaborators will see when they open it. … Turn on Dark Mode To turn on Dark Mode in the Word, you need to enable Dark Mode for Mac OS. 1. Go to Settings > General 2. In the Appearance options, select Dark [Screenshot] Alternatively, you can select Auto, which will switch between Light and Dark modes based on your specified Night Shift schedule in MacOS. [Screenshot] 3. To turn off Dark Mode, go to Word > Preferences > General > Personalize and select Turn off Dark Mode [Screenshot] inclusive this section: Personalize ● Turn off Dark Mode ○ Dark mode has a dark page color ○ Dark mode has a white page color … Set the page background color Once Dark Mode has been turned on, you can toggle between the dark and light page background colors. 1. In the ribbon, go to the View tab. 2. Select Switch Modes to change the page background color. Word will remember the state of this toggle for future Dark Mode sessions. [Screenshot] Disable the dark page background You can disable the dark page background in Dark Mode and keep the page light. Go to Word > Preferences > General > Personalize. Select Dark Mode has a white page color. [Screenshot] Check the appearance Regardless of your Dark Mode settings, your document will print with the light mode page color. Also, your Dark Mode settings do not impact your collaborators, and Word will respect individual view preferences. To preview your document for printing and sharing, use the Switch Modes button to change the page background to light. … -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152775] [Enhancement] Emphasize the entry the mouse pointer is over in the Writer Navigator content tree
https://bugs.documentfoundation.org/show_bug.cgi?id=152775 Jim Raykowski changed: What|Removed |Added Severity|enhancement |minor --- Comment #10 from Jim Raykowski --- The thought was that it might be useful to match the content brought to attention on the visible canvas to the entry in the navigator content tree. Possibly only have this behavior when the feature is active? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152775] [Enhancement] Emphasize the entry the mouse pointer is over in the Writer Navigator content tree
https://bugs.documentfoundation.org/show_bug.cgi?id=152775 --- Comment #9 from Buovjaga --- (In reply to sdc.blanco from comment #3) > I am assuming that nothing has changed from demo 1 and demo 2 -- but demo 2 > shows a new dimension -- of highlighting the relevant items in the document. A note as I did not notice this bit before: the highlighting in doc canvas is already in 7.5: https://wiki.documentfoundation.org/ReleaseNotes/7.5#Writer Bug 152029 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152775] [Enhancement] Emphasize the entry the mouse pointer is over in the Writer Navigator content tree
https://bugs.documentfoundation.org/show_bug.cgi?id=152775 Cor Nouws changed: What|Removed |Added CC||c...@nouenoff.nl --- Comment #8 from Cor Nouws --- (In reply to Buovjaga from comment #7) > (In reply to Heiko Tietze from comment #6) > > Why should one do this? > > Should or should one not do this is exactly what is being asked from UX team. or the one coming up with the proposal... That would help us to judge, I think :) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153901] Add support for comment tooltips on table cell content
https://bugs.documentfoundation.org/show_bug.cgi?id=153901 V Stuart Foote changed: What|Removed |Added Summary|Add support for tooltips on |Add support for comment |table cells |tooltips on table cell ||content -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153901] Add support for tooltips on table cells
https://bugs.documentfoundation.org/show_bug.cgi?id=153901 V Stuart Foote changed: What|Removed |Added Blocks||114019 CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vsfo...@libreoffice.org Keywords||needsUXEval --- Comment #1 from V Stuart Foote --- Distinct from Writer usage and formatting tooltips of bug 116297--this would be commenting on a Writer Table cell. Not clear we can get there without major rework of Table cell handling for Writer. While present for the Calc UI, where an inserted comment will show as pop-up on mouse over, a comment on Writer is not individually exposed via pop-up. They are all exposed to an annexed Comments area of canvas, or they can be reviewed via the Navigator. So Comments serve a different purpose between the two document types--though I expect the comment in a text document table cell could be handled the same as a comment in a spreadsheet--the ODF can accommodate. Not clear a departure from current UI presentation is merited. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=114019 [Bug 114019] [META] Tooltip bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147219] Keyboard short cut to traverse over open modules
https://bugs.documentfoundation.org/show_bug.cgi?id=147219 --- Comment #3 from Heiko Tietze --- (In reply to dlingard2002 from comment #2) > Writer and Calc open documents are not tabbed Exactly, they are stand-alone windows. And your OS shortcut to switch between open windows is likely alt+tab. Overwriting system functions is dirty, but admittedly beneficial in this case. So my proposal was to implement the feature but not hard-code a short cut. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153888] Very bad formatting when importing pdf
https://bugs.documentfoundation.org/show_bug.cgi?id=153888 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #12 from Heiko Tietze --- (In reply to V Stuart Foote from comment #11) > @Heiko, please take this to ESC. Getting tired of rehashing resolved issues > with Eyal and others regards the scope of our filter handling of PDFs > source. We do what we can with what is an "un-editable" format. It is > untenable for the project to suggest otherwise. The developers don't care about naming it "un-editable" or "badly working". I totally agree with your POV but that does not spare us from fixing import issues. If reported in an actionable way, which is not the fact here. Something like "word wrap not correctly applied" could work (to my knowledge we cannot read the font from PDF and it will never be pixel-perfect aka not an editor; PDF is a lossy format). As for the UX I don't see what we could contribute. @Eyal, please keep an open and friendly tone in comments. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153888] Very bad formatting when importing pdf
https://bugs.documentfoundation.org/show_bug.cgi?id=153888 V Stuart Foote changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #11 from V Stuart Foote --- @Heiko, please take this to ESC. Getting tired of rehashing resolved issues with Eyal and others regards the scope of our filter handling of PDFs source. We do what we can with what is an "un-editable" format. It is untenable for the project to suggest otherwise. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146922] Groupedbar Compact UI : share a few creation templates with the standard menu
https://bugs.documentfoundation.org/show_bug.cgi?id=146922 Maxim Monastirsky changed: What|Removed |Added CC||momonas...@gmail.com --- Comment #2 from Maxim Monastirsky --- (In reply to Jérôme from comment #0) > For example, the comment #10 of the bug #142990 proposes to add a sub menu > entry to the "insert" group that is identical to the "field" sub menu of the > standard "insert" menu ? > > In order to decrease the discrepancies between the 2 sub menus, could we > possibly use the same template in order to create the 2 sub-menus ? This is already the case. The "Field" submenu is defined in a separate xml file at sw/uiconfig/swriter/popupmenu/insertfield.xml, and from there pulled to both the main menu and the toolbar by .uno:InsertFieldCtrl. Moreover, .uno:InsertFieldCtrl is already present in Groupedbar Compact but under the "References" menu, so Bug 142990 appears to be WFM (unless we want to move it to the insert menu, which might be more familiar to some users). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147219] Keyboard short cut to traverse over open modules
https://bugs.documentfoundation.org/show_bug.cgi?id=147219 --- Comment #2 from dlingard2...@gmail.com --- Yes, that's how CTRL+Tab works in a browser but in writer and calc open documents are not tabbed - or have I missed something? I'm no expert and there are so many options I may well have missed the chance to have separate open documents as tabs. If so please forgive my igorance and point me towards the answer. Thanks for your help. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146922] Groupedbar Compact UI : share a few creation templates with the standard menu
https://bugs.documentfoundation.org/show_bug.cgi?id=146922 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 --- Comment #1 from Heiko Tietze --- The notebookbar variants are based on ui files maintained via Glade. I don't see how a kind of template could work. Or am I missing the point? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153509] Offer easy-to-invoke split screens with a minimally visible user interface in Writer, using already existing LO functionality
https://bugs.documentfoundation.org/show_bug.cgi?id=153509 --- Comment #6 from Heiko Tietze --- (In reply to Stéphane Guillou (stragu) from comment #5) > Thank for the reply. > > My assumption is that the possible implementation of a split screen would > allow both same-document and comparison views, which is why I thought that > would cover your case. > > In any case, I'm sure the UX/UI team has given the topic some thought in the > past, so I am copying them here to see what they think. There is bug 149374 (made a duplicate of 31481 as well). And I understand 31481 as exactly what is asked in #3, a split view for one single document (we have this feature in Calc). See all the duplicates, for example bug 42428. Showing two different files like one document separated by a splitter makes not much sense. Sidenote: Bug 37134 asks for a tabbed UI where switching between open documents would be as easy as in browsers. Bug 101788 discusses "Split button for display modes". -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153880] Make Calc text hyperlinks stand out more
https://bugs.documentfoundation.org/show_bug.cgi?id=153880 --- Comment #5 from Gabor Kelemen (allotropia) --- Created attachment 185663 --> https://bugs.documentfoundation.org/attachment.cgi?id=185663&action=edit The example file under Windows - Dark theme There is indeed a bit of difference in color under Windows depending on the light/dark theme setting. Still: I think adding automatic underlining here would be probably helpful. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153880] Make Calc text hyperlinks stand out more
https://bugs.documentfoundation.org/show_bug.cgi?id=153880 --- Comment #4 from Gabor Kelemen (allotropia) --- Created attachment 185662 --> https://bugs.documentfoundation.org/attachment.cgi?id=185662&action=edit The example file under Windows - Light theme -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147219] Keyboard short cut to traverse over open modules
https://bugs.documentfoundation.org/show_bug.cgi?id=147219 Heiko Tietze changed: What|Removed |Added Summary|Feature request keyboard|Keyboard short cut to |short cut |traverse over open modules Blocks||86899 --- Comment #1 from Heiko Tietze --- Ctrl+Tab usually traverses over tabs, like in any browser. Abusing this shortcut for windows even from one application makes not much sense to me. But since we have a list of open modules under the Windows entry I assume it's not too difficult to add a UNO command that can be customized individually. Opinions? Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=86899 [Bug 86899] [META] Requests for the addition of UNO commands -- You are receiving this mail because: You are on the CC list for the bug.
