[Libreoffice-ux-advise] [Bug 155200] As of version LO 7.4.x.x large branding icon in the thumbnails of the last used documents.
https://bugs.documentfoundation.org/show_bug.cgi?id=155200 --- Comment #15 from V Stuart Foote --- Created attachment 187366 --> https://bugs.documentfoundation.org/attachment.cgi?id=187366=edit LO 7.5.3 on a 4K system win10 os/DE at 175% scale -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155200] As of version LO 7.4.x.x large branding icon in the thumbnails of the last used documents.
https://bugs.documentfoundation.org/show_bug.cgi?id=155200 --- Comment #14 from V Stuart Foote --- Created attachment 187365 --> https://bugs.documentfoundation.org/attachment.cgi?id=187365=edit LO 7.5.3 on a 4K system win10 os/DE at 325% scale compare the attached clips of SC from a Win10 w/4K display system--one at 325%, and the other at 175% os/DE scaling amount the thumbnails are scaled differs from amount the mime type icons are scaled. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155200] As of version LO 7.4.x.x large branding icon in the thumbnails of the last used documents.
https://bugs.documentfoundation.org/show_bug.cgi?id=155200 --- Comment #13 from V Stuart Foote --- (In reply to Stéphane Guillou (stragu) from comment #12) > (In reply to Ransom from comment #11) > > [...] the branding icons take up so much space that there’s not much > > left of the actual preview thumbnails. > > As I said in comment 10, I think the issue is that you document previews are > not scaled up when they should, just like all other UI element do. If they > did, the relative size of the icon would remain the same. > > Stuart, would you agree? Are the thumbnails not scaling up when the OS > scaling is increased? Actually, they do scale. But not at the same rate. The MIME type icons stamped onto the backing window thumbnails are sized the same as the icons on the SC sidebar. But the thumbnails on the backing window scale less. So by 175% or OPs 300% they are rather out of sync. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155200] As of version LO 7.4.x.x large branding icon in the thumbnails of the last used documents.
https://bugs.documentfoundation.org/show_bug.cgi?id=155200 --- Comment #12 from Stéphane Guillou (stragu) --- (In reply to Ransom from comment #11) > [...] the branding icons take up so much space that there’s not much > left of the actual preview thumbnails. As I said in comment 10, I think the issue is that you document previews are not scaled up when they should, just like all other UI element do. If they did, the relative size of the icon would remain the same. Stuart, would you agree? Are the thumbnails not scaling up when the OS scaling is increased? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155200] As of version LO 7.4.x.x large branding icon in the thumbnails of the last used documents.
https://bugs.documentfoundation.org/show_bug.cgi?id=155200 --- Comment #11 from Ransom --- (In reply to Heiko Tietze from comment #9) > But isn’t this wanted? That is quite possible. But maybe the programmers didn’t realize that in most cases the branding icons take up so much space that there’s not much left of the actual preview thumbnails. I have always appreciated the latter, but with this new feature, the branding icons are pushed to the foreground, which destroys the preview. And I find that very unfortunate. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155373] Feature request impress: editing slides and notes at the same time
https://bugs.documentfoundation.org/show_bug.cgi?id=155373 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added Blocks||107817 Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=107817 [Bug 107817] [META] Impress UI/UX bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 90989] Simplified options dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=90989 --- Comment #9 from Eyal Rozenberg --- Separating/removing document-specific and template-specific options from this dialog (bug 144814, and my comment 16 there specifically) would go a long way towards resolving this bug. What assumptions were the students making about all that? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 143037] Relative size setting overwritten only after closing dialog when image size changed in the Crop tab (see comment 3)
https://bugs.documentfoundation.org/show_bug.cgi?id=143037 Stéphane Guillou (stragu) changed: What|Removed |Added Blocks||103152, 108280 Version|7.0.6.2 release |Inherited From OOo Summary|Editing an Image Objects|Relative size setting |Settings in Writer on the |overwritten only after |Type and Cut Pane, the Type |closing dialog when image |Panes Changes are lost, |size changed in the Crop |when clicking OK|tab (see comment 3) CC||libreoffice-ux-advise@lists ||.freedesktop.org See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||3324 Keywords||needsUXEval --- Comment #3 from Stéphane Guillou (stragu) --- Steps for what the OP describes: 1. Open Writer, insert image 2. Insert an image 2. Right-click on image > Properties... > Position and Size, activate "Relative to Entire paragraph area" for width 3. Go to Crop tab, change the width in "Image Size" 4. Back in "Position and Size" tab, see that Relative option is still active 5. Click OK; see image width changed 6. Right-click > Properties... > Position and Size Result: Relative setting off, overwritten. But I think the overarching issue here is how the fields sync inconsistently in the Crop tab (and beyond), since OOo 3.3 times. Currently, changing values in the "Crop" section: - updates the values in the "Image Size" section if "Keep scale" is used; or - updates the values in the "Scale" section if "Keep image size" is used. So far, so good: my logical interpretation of the two bottom sections is "the size of the crop area with different units", i.e. another method to define the cropping area. However, as soon as you touch the values in the "Image Size" or "Scale" sections, the values are not synced anymore with the "Crop" section, and are only used to stretch or shrink the image accordingly. This is unexpected: it goes against the selected "Keep scale / Keep image size" setting, has no effect on cropping, and is a duplication of the "Position and Size" tab. Furthermore, changing those bottom values does not update the preview whatsoever. I think there is too much complexity in this tab, and that we should either: A. improve it by properly syncing the values across sections + making the preview always update, including with the stretching of the image; or B. simplify it by removing the two bottom sections and the "original size" button. (The preview would ideally still need to update for when the image size is preserved, i.e. shrinking / stretching the image) UX team, what are your thoughts? Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103152 [Bug 103152] [META] Writer image bugs and enhancements https://bugs.documentfoundation.org/show_bug.cgi?id=108280 [Bug 108280] [META] Image crop bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154140] Bring back the transparency option
https://bugs.documentfoundation.org/show_bug.cgi?id=154140 V Stuart Foote changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Ever confirmed|1 |0 CC||vsfo...@libreoffice.org Resolution|NOTABUG |--- Severity|minor |enhancement --- Comment #12 from V Stuart Foote --- NAB -- the global options were reworked/dropped in 2015 for https://gerrit.libreoffice.org/c/core/+/17481/ as worked up in https://wiki.documentfoundation.org/Design/Whiteboards/Options/Global At this point, the 'TransparentSelection' option when set in expert configuration is much less drastic than "Automatic" --> "Enabled" setting of the 'Options for High Contrast Appearance'. Toggling off transparent selection, only inverts the rendering of the selection. While the HC options mode toggles the entire UI response (icon theme, document bg/fg)--users not already on an os/DE HC theme would not like the outcome. Middle ground, bcz bringing the 'TransparentSelection' out of expert configuration would be useful Assistive Technology as a visual aid, how-about adding it to the Tools -> Options -> Accessibility panel? Place it the "Miscellaneous Options" block as 'Disable transparent selection' -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154140] Bring back the transparency option
https://bugs.documentfoundation.org/show_bug.cgi?id=154140 Heiko Tietze changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEEDINFO|RESOLVED --- Comment #11 from Heiko Tietze --- (In reply to Michael Weghorn from comment #10) > "High Contrast" option to "Enable" results in Calc selection being displayed > the same way as setting the mentioned expert setting: > ... > Therefore: Does that already cover the request made here? Yes, it does IMO. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154140] Bring back the transparency option
https://bugs.documentfoundation.org/show_bug.cgi?id=154140 --- Comment #10 from Michael Weghorn --- (In reply to Heiko Tietze from comment #9) > Similar request in https://bz.apache.org/ooo/show_bug.cgi?id=97672. > > Michael, what do you think with a11y in mind? >From what I can see in a quick test, setting the "Accessibility" -> "Options for High Contrast Appearence" -> "High Contrast" option to "Enable" results in Calc selection being displayed the same way as setting the mentioned expert setting: > Expected Results: > With org.openoffice.Office.Common.DrawingLayer.TransparentSelection = OFF > all selections are highlighted in colors complementary to the highlighted > items, borders, text, areas which is very easy to spot even in colorful > situations. (and might possibly do more in addition, didn't look into it in more detail yet) Therefore: Does that already cover the request made here? Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 0c53ac3ff360a3fd646dcb0c42198300fab86d90 CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153749] Allow entering textbox edit mode with single click instead of double-click
https://bugs.documentfoundation.org/show_bug.cgi?id=153749 Heiko Tietze changed: What|Removed |Added CC||er...@redhat.com, ||tele...@surfxs.nl See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=10 ||7688 Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO --- Comment #6 from Heiko Tietze --- The point of single click to activate the text box object vs. double click to enter the edit mode makes sense. However, Impress/Draw has the option General > Allow quick editing which detects whether the cursor is over text and goes directly into edit mode if checked (see also bug 106330). Now I wonder if we can add this behavior to Writer/Calc. Eike, what do you think? The question is frequently asked, see bug 107688 "Accessing the textbox of a selected shape is a bit counter-intuitive and inconsistent", but also somewhat controversial, see bug 154409 for "A single click on a shape/image with frame should select the frame, instead of the image". -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153749] Allow entering textbox edit mode with single click instead of double-click
https://bugs.documentfoundation.org/show_bug.cgi?id=153749 Stéphane Guillou (stragu) changed: What|Removed |Added OS|Windows (All) |All Priority|medium |low Keywords||needsUXEval Component|Calc|LibreOffice Summary|Calc Text Box cursor bug|Allow entering textbox edit ||mode with single click ||instead of double-click CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #5 from Stéphane Guillou (stragu) --- (In reply to golemus from comment #3) > How to implement this then? IMO there could be (at least for the next 3-5 > years) a "single click textbox editing" setting somewhere under Options... > menu in LibreOffice. Its default value would be "disabled" in beginning but > changed to "enabled" after 2 years or so. This setting would change behavior > of textboxes in Calc and Impress as described above so that single click > starts to directly edit from where cursor was pressed. > As selection is probably lesser used mode it could be enabled by clicking > edges/corners or clicking inside the textbox and pressing ESC to get from > editing to selection mode. I'll let the UX team decide if this is desirable enough or not, copying them in. > [...] I am using textbox as a notepad > so centering text in the middle is not an option. Although when using > Impress centering probably makes more sense. Have you considered using comments, then? You can insert them easily with Ctrl + Alt + C, and make them always visible with View > Comments. > As you know internals of Libreoffice better could you maybe make the above > suggestions "Single Click Textbox Editing" and "solid white or graywhite > background as default Area... values/fills for Calc textbox" to the right > discussion thread where they would get more attention? Reports that focus on a specific issue are a lot more likely to be actioned and resolved. I am refocusing this one on "single-click to edit", and you can open a new report about default colours if you'd like that to change. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.
