[Libreoffice-ux-advise] [Bug 149254] Make the selection behavior when double-clicking a word a user preference.
https://bugs.documentfoundation.org/show_bug.cgi?id=149254 --- Comment #11 from Chris --- Heiko Tietze, you are correct of course. I'm looking for a consistent experience that I can adjust to my needs. If I could adjust it, double-clicking a word would act like MS-Word which selects the word plus the trailing space. A delete or a backspace removes the word, plus the trailing space. Overtyping preserves the space, or more correctly, replaces the trailing space. There may be some other options, but this is something that I've grown used to, and I'd prefer not to have to re-learn how to use the word processor as I'm trying to write or edit a document. Thanks for your consideration. I don't want to add to bloat, and I really don't want to complicate configuration menus, but this one feature would be really helpful as I edit my writing. Chris -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149411] It's difficult to reach text area properties
https://bugs.documentfoundation.org/show_bug.cgi?id=149411 Rafael Lima changed: What|Removed |Added CC||rafael.palma.l...@gmail.com --- Comment #3 from Rafael Lima --- Some of the options in the Text dialog (right-click the text inside the shape and go to "Text attributes" could be on its own section in the Properties sidebar. The section could be named "Text Attributes" and we could have: - Spacing to borders - Wrap and resize options - Number of columns and spacing between columns - Effect (maybe) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149407] Proposal for slight change in position and label of controls in the Position dialog for objects
https://bugs.documentfoundation.org/show_bug.cgi?id=149407 Eyal Rozenberg changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||8593 --- Comment #2 from Eyal Rozenberg --- I guess Heiko is referring to what I wrote in bug 148593. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149414] Change submenu label for formatting textboxes and shapes in Calc and Impress
https://bugs.documentfoundation.org/show_bug.cgi?id=149414 Heiko Tietze changed: What|Removed |Added CC||momonas...@gmail.com --- Comment #3 from Heiko Tietze --- The Writer-specific command was introduced resp. derived from Generic with https://gerrit.libreoffice.org/c/core/+/20167/ for bug 91781. If all modules use the same label you can just delete it from WriterCommands. It was split in https://gerrit.libreoffice.org/c/core/+/20630 probably to deal with the fact that Draw/Impress has one more option. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 41542] FORMATTING: Allow "Spacing to contents" for edges without a line
https://bugs.documentfoundation.org/show_bug.cgi?id=41542 Justin L changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||9397 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149414] Change submenu label for formatting textboxes and shapes in Calc and Impress
https://bugs.documentfoundation.org/show_bug.cgi?id=149414 --- Comment #2 from sdc.bla...@youmail.dk --- (In reply to Heiko Tietze from comment #1) > I never struggled with "Object and Shape". Ack. Reasons for change are: (a) trying not to use the generic "object" in the UI (in part because "object" ≠ "OLE object, such as noted in bug 149018) and (b) consistency across modules. > .uno:ObjectMenue I guess. What is the difference between the two? Edit > OLE Object (in all modules) is .uno:ObjectMenue (e=Edit) > it's in GenericCommands as > ~Object and Shape That is what the patch in OP changed. Alternative solutions: 1. Leave "Object and Shape" unchanged in Impress, and use that label in Calc as well. 2. Leave "Object and Shape" unchanged in Impress, and make a pseudo .uno for Calc with "TargetURL" with a different label (e.g., "Text Box and Shape") No strong opinion in any direction, beyond the following main issue that motivated this ticket: - Calc should be changed (because Format > OLE Object is wrong. - The obvious .uno for Calc is in GenericCommands and used already in Impress. - If consistency across modules is not important here, then maybe just take the Alternative Solution 1. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149411] It's difficult to reach text area properties
https://bugs.documentfoundation.org/show_bug.cgi?id=149411 --- Comment #2 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #1) > If you have the (classic) toolbar in mind I disagree that all commands need > to be present all the time. What else? I somehow "misplaced" it in the main toolbar. So, I take back the claim that it's missing. Still, I feel it doesn't stand out. Line spacing has its own submenu, and so does "a bunch of actual text properties", bullets and numbering has 2 top-level main menu items (a submenu and an item for opening the dialog) - and all those are very well represented on the toolbars. Plus, we have two menu top-level items for "Name" and "Description" (Why are those not together, by the way? and Why is there both a title and a name?). But the padding is relegated to an ambiguously relegated tab in a dialog on a submenu? Not fair. The other claims stand; especially this being absent from the side-bar. About the toolbars - if this was better available otherwise, adding this to the main toolbar is not necessary, and the text formatting toolbar is not quite quite the right place, so not sure about that. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149407] Proposal for slight change in position and label of controls in the Position dialog for objects
https://bugs.documentfoundation.org/show_bug.cgi?id=149407 Heiko Tietze changed: What|Removed |Added CC||eyalr...@gmx.com --- Comment #1 from Heiko Tietze --- Eyal had a similar idea to make the content readable. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149406] What is expected behavior of padding for characters, with and without borders?
https://bugs.documentfoundation.org/show_bug.cgi?id=149406 Heiko Tietze changed: What|Removed |Added CC||mikekagan...@hotmail.com, ||vmik...@collabora.com --- Comment #4 from Heiko Tietze --- The question is whether an object anchored horizontally left To Character and vertically at the Bottom should follow the bottom padding/spacing of this character. I'd say yes. Opening this document in MSO breaks the position of blue/aqua rectangles. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149411] It's difficult to reach text area properties
https://bugs.documentfoundation.org/show_bug.cgi?id=149411 Heiko Tietze changed: What|Removed |Added CC|heiko.tietze@documentfounda |libreoffice-ux-advise@lists |tion.org|.freedesktop.org --- Comment #1 from Heiko Tietze --- Context menu: Text Attributes... Main menu: Format > Object and Shape > Text Attributes... and at some of the Notebookbar variants If you have the (classic) toolbar in mind I disagree that all commands need to be present all the time. What else? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 126530] Tabbed Notebook Bar Usability Issues on Windows 10
https://bugs.documentfoundation.org/show_bug.cgi?id=126530 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Status|REOPENED|NEW Keywords|needsUXEval | --- Comment #8 from Heiko Tietze --- So let's keep it open as bug. We aim for a ticket per patch so the Continuos integration can be linked to the reported issue. Does not work wit multiple reports in one ticket. And the summary "usability issues" is nondescript too. It will be hard to find volunteers. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149414] Change submenu label for formatting textboxes and shapes in Calc and Impress
https://bugs.documentfoundation.org/show_bug.cgi?id=149414 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||9018 --- Comment #1 from Heiko Tietze --- (In reply to sdc.blanco from comment #0) >(b) because the contents of its submenu are applied >only to Text Boxes and Shapes. Insert > Object > Formula - and change the background via this menu and Area. Or set the position for a bar code. I never struggled with "Object and Shape". (In reply to sdc.blanco from comment #0) > 2. Change in Calc, .uno:ObjectMenu to .uno:FormatObjectMenu .uno:ObjectMenue I guess. What is the difference between the two? Btw, WriterCommands redefines uno:FormatObjectMenu Text Box and Shap~e it's in GenericCommands as ~Object and Shape -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 135501] Change the default UI (summaries in comment 67, comment 89, comment 133)
https://bugs.documentfoundation.org/show_bug.cgi?id=135501 --- Comment #134 from John Mills --- > > Those who are not involved with LO development and news simply have not > > heard of it and the way to change it is not very prominent so that new > > users will easily learn that it exists. > > Bug 137931 seems like the solution to that problem... Hi Eyal, I think this is a very reasonable request and was raised a while back, the interim solution was to highlight the UI availability as a tip of the day dialog. While better than nothing it does not have the same emphasis as a user choice on first startup. @Heiko : Is this something that could be revisited while future work is undertaken on the Tabbed UI? Also to this point: > To summarize, we more or less agree on the need to finalize the Notebookbar. > Stuart's task list in comment 110 could be a start to get developers' wisdom > into the discussion. Point is that we have a functionally pretty well-working > Standard UI and we should balance the effort for a Ribbon-like interface with > the benefit. Possibly the comments in 110 should be the basis of a 2 step approach for a longer term solution to aim for. However is there anything that could be done in the short term so we do not have to wait months or years for discussion and then developer support/funding? @Pedro makes a valid statement in comment 126. > I am a proponent of the switch WHEN two blockers are solved: > 1 - Extension support, > 2 - Get a dev dedicated to work on the UI for proper support. Is there anything that can be done to support this shorter term approach while the longer term one is planned for? Cheers, John -- You are receiving this mail because: You are on the CC list for the bug.
