[Libreoffice-ux-advise] [Bug 147232] Improvement of CALC diagrams
https://bugs.documentfoundation.org/show_bug.cgi?id=147232 --- Comment #16 from shoe...@gmx.de --- Created attachment 186340 --> https://bugs.documentfoundation.org/attachment.cgi?id=186340=edit New panel for "true size" X/Y diagram image export -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151507] Themed color palette
https://bugs.documentfoundation.org/show_bug.cgi?id=151507 --- Comment #8 from Regina Henschel --- Created attachment 186332 --> https://bugs.documentfoundation.org/attachment.cgi?id=186332=edit Solid fill and gradient fill Theme colors (MS Office "schemeClr") are different from palettes because the set of scheme colors is stored in the file and bound to the master page. As Writer has only one master page it can only have one set of scheme colors. Impress/Draw can have several master pages and thus several sets of scheme colors. If you want to change a theme, that means effectively a change of the master page. So I agree with V Stuart Foote that changing or editing the set of scheme colors should not be in the area dialog but could be located in the master page dialog in Impress. In Writer it cannot be inside the page style dialog, because there is only one set of scheme colors. [Perhaps a new dialog with all document wide settings in Writer?] For selecting a scheme color, I prefer to have it separated from the palettes. There could be a dedicated area for it, see my attachment. Lighten/darken can be a new control, consisting of a set of buttons with stepped examples and a field for numerically determine the value. MS Office allows light and darken not only for scheme colors but for all colors. Therefore I would allow lighten/darken for palette colors too. See my attachment. MS Office has no fixed steps of lighten/darken but depends the steps on the brightness of the base color. So should we do (bug 153361). It is useless to make a light background color 4 steps lighter, or a dark text color even darker. The previews of the selected colors would then need to be split in showing the base color and the selected lighten/darken variant. That is not included in my attachment. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 Eyal Rozenberg changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED CC||libreoffice-ux-advise@lists ||.freedesktop.org Resolution|NOTABUG |--- Keywords||needsUXEval --- Comment #12 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #11) > We discussed the topic in the design meeting. Please read my last comment. > LibreOffice offers the outstanding feature to merge cells in three different > ways. ... not relevant to this bug. > If you copy a merged cell you expect the merged state to be taken into > account. The same is true for clone format that takes the merge state as a > formatting attribute and applies it to the target. It's a convenience > feature in alignment to the copy function. All features are convenience features. One can always edit an ODF file manually. The use of this term is suspicious. > Cell formatting is preferably done per cell style. Cell formatting is application of style + DF. When you clone-format, you clone the style and the DF. > The style with all > defined attributes will be applied to the merged cells without affecting the > state. (facepalm!) 1. This bug was opened about the fact that clone-formatting _does_ affect the merged state - it breaks up the cells. You're claiming that it doesn't? That's nonsensical. In fact, in the design meeting, the conclusion was that the clone-formatting _should_ affect the merged state. 2. This bug is about cloning DF, not cloning styles. Given that the cells are broken up, the complaint is that the DF is applied to just one of them. 3. No, the style is _not_ applied to all of the cells! Just to the first one. If you change the style of D3 in the reproduction instruction to some other style (e.g. "my_style" with a blue background) - only the first of the broken-up cells will get "my_style" and the blue background; the rest will remain in Default Style. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 113388] Support for Client Side Windows Decorations in LibreOffice
https://bugs.documentfoundation.org/show_bug.cgi?id=113388 V Stuart Foote changed: What|Removed |Added Blocks||115512 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=115512 [Bug 115512] Client-side window decorations (remove titlebar from UI when running GNOME with some toolbar view modes) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 113388] Support for Client Side Windows Decorations in LibreOffice
https://bugs.documentfoundation.org/show_bug.cgi?id=113388 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||4472 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154394] Can not select multiple check box in single shot for Formatting Text
https://bugs.documentfoundation.org/show_bug.cgi?id=154394 Stéphane Guillou (stragu) changed: What|Removed |Added Status|REOPENED|UNCONFIRMED Keywords||needsUXEval Ever confirmed|1 |0 CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||stephane.guillou@libreoffic ||e.org --- Comment #7 from Stéphane Guillou (stragu) --- The icons in the top menu are used to indicate that something is on, they are not actual tick boxes like in a dialog. The design of the top menu is that clicking one element executes an action, and then closes. I don't see this changing any time soon, the behaviour is standard and I can't think of other apps in which the menu remains open after having clicked on an option. (Can you think of one?) Alternatives to using the menu repeatedly: - toolbar, which you can customise - Character dialog (accessed through top menu or context menu) - If you often need to apply the same set of direct formatting options, you should create a character style that has them all I believe these are sufficient. Agreeing with Miguel Angel in closing as "won't fix". (Maybe better icons could be used if they look like actual tickboxes, but I think that comes from your desktop environment, not LO. Mine look like this on GNOME: ✓) The UX team can weigh in. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151507] Themed color palette
https://bugs.documentfoundation.org/show_bug.cgi?id=151507 --- Comment #7 from V Stuart Foote --- I really want to keep the Theme "style" editor separate from our functional Palette based color picker. OK to use the Theme palette from the picker as now. But keeping two distinct dialogs please--not option #2 Yes to providing the 'Standard' colors (standard.soc) for use with the Theme Colors... picker would be useful. And with the 'Standard' palette the drop list would obviously be the defined "tints" and "shades" of the standard.soc. +1 for option #3 A good start but would we stop there? For Themed colors "style" dialog--how do you make changes to the Theme? Remember the theme structure is 2-backgrounds, 2 text/foregrounds, 6 accents, hyperlink, followed-hyperlink. And the rest of the "Theme" columns are calculated values against those base colors: 80%, 60%, 40% lighter and 25%, 50% darker. They are fixed as recorded to the palette. Currently, you can change one value--but you can not pick one base color to modify and recalculate its derived values to edit the "Theme". Seems that is going to be needed. Also, should there be some cross over by including the "active" palette from the color picker for editing the base colors? Maybe just link the picker as a split button (show active color - or open picker) like done on normal toolbars? Another reason to keep two dialogs. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154211] Allow selecting a range between current cursor position and an element in Navigator with Shift + click (EDITING)
https://bugs.documentfoundation.org/show_bug.cgi?id=154211 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #7 from Heiko Tietze --- The request boils down to not change the document focus when interacting with the Navigator and to just scroll to the respective position. I think wont be comfortable for the majority of users (who not even know about Emacs). And actually it shouldn't be a frequent use case anyway. You could realize the function per macro. And perhaps you may benefit from the various selection modes we provide, and which are easy to overlook. Depends of course on your specific use case. My take is still WF. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147232] Improvement of CALC diagrams
https://bugs.documentfoundation.org/show_bug.cgi?id=147232 --- Comment #15 from Heiko Tietze --- (In reply to Regina Henschel from comment #14) > If you draw an xy-chart manually you will decide whether you will use 1cm or > 5mm for the unit "1". The diagram size minus the wall size divide by the maximum is the size of steps on the axis. If you define the step in metrical units this affects the overall size of the diagram - and vice versa. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151507] Themed color palette
https://bugs.documentfoundation.org/show_bug.cgi?id=151507 Heiko Tietze changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #6 from Heiko Tietze --- The mockup at https://design.penpot.app/#/view/d9665a57-0073-80a2-8002-47af3e11cf33?page-id=d9665a57-0073-80a2-8002-47af3e11cf34=interactions=0=d5fc0283-ef1c-80fa-8002-47d90c42f7c6 starts on 1) with the current implementation. While LibreOffice (on the left) offers RGB access to set all millions of colors the theme (as implemented by MSO on the right) is kind of a style and changing „Accent 1“ affects all places it is used. The requirements are: a) pick a themed colorize 1. access different brightness/colorization steps 2. show the active theme color on the selection 3. allow special colors such as „Automatic“ (eg. for font color) and „No Fill“ (Shapes) b) pick a standard color 1. provide access to the recently used colors 2. allow to switch the way RGB colors are presented (eg. Palette filtered for HTML) c) use the themed and standard colors on gradients and other places too d) allow to switch the color theme to adjust to whole document appearance (eg. from “Rainbow” to “Beach”) e) edit and share color theme f) edit and share standard colors and palettes No doubt that MSO solves a) in a perfect way, and we could do the same giving full access to the standard colors b) in an extra dialog. But we aim to give freedom to the users and should not just copy a solution but make it more flexible. Option 2) in the mockup merges a) and b) into one picker. The standard palette is reduced to save space but that’s not necessary. In contrast to the prototype from MSO we could just present the basic theme colors denying a1 (access to the brightness level could be given in the color dialog underneath the current color per slider / num stepper). It adds a dropdown to pick a theme and the load more from the extension site. Drawback of this solution is that picking a theme when coloring a random object affect every color. Changing the color theme might be better suited at some special place, in case of MSO at the Design tab. We could do this in a special dialog or in the page style dialog (respectively Slide Properties for Impress) since the setting belongs to the whole document. Option 3) takes into account that the layout of 2) feels a bit crowded. It reduces the Theme Colors to just the colors with access to the brightness levels via dropdown menu. And while we can do this for the themed colors the same is possible for the standard colors, as shown right hand. Changing the RGB palette could be done in any Area Fill dialog. Themed colors are well suited for less colorful documents as done in Writer but less optimal when color is prime, ie. in Draw. We probably need two different approaches. Comments are welcome. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147232] Improvement of CALC diagrams
https://bugs.documentfoundation.org/show_bug.cgi?id=147232 --- Comment #14 from Regina Henschel --- (In reply to Heiko Tietze from comment #13) > (In reply to Regina Henschel from comment #12) > > ...unit on x-axis and y-axis are displayed with the same length. > What is the length of a unit? If you draw an xy-chart manually you will decide whether you will use 1cm or 5mm for the unit "1". Such setting is missing in LibreOffice. One mode of the desired behavior is, that you can force the axis to use a specific length for the unit "1" and that length is kept when resizing the chart object and when exporting the chart. > > > If you have fixed min and max values you can get it manually by dragging the > > chart wall to the correct size. > Therefore me concluded in comment 10 that we have to expose the wall > position/size in the UI. That would indeed be a great help for manually tweaking the chart. > > > I think this report is duplicate to bug 43174 in regard to axis scaling. > You can easily set a min/max. A second mode would be, that x-axis and y-axis use the same length for the unit "1" but in case min/max is set to 'automatic', this length adapts to the actual data values and the length adapts to the size of the chart object. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154211] Allow selecting a range between current cursor position and an element in Navigator with Shift + click (EDITING)
https://bugs.documentfoundation.org/show_bug.cgi?id=154211 Ole Tange changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- --- Comment #6 from Ole Tange --- Just to make it clear: The mulitiselection idea (Bug 129610) would not solve my issue and it is in no way the same problem. I am an emacs user, and I really love CTRL-space to set mark, then move to another location, and then being able to cut the area between the mark and the current cursor location. So another way that would solve my issue would be to have a way to turn on selection mode, then navigate (by hand or by Navigator) and then have a selection between the start point and the current cursor location. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147232] Improvement of CALC diagrams
https://bugs.documentfoundation.org/show_bug.cgi?id=147232 --- Comment #13 from Heiko Tietze --- (In reply to Regina Henschel from comment #12) > ...unit on x-axis and y-axis are displayed with the same length. What is the length of a unit? > If you have fixed min and max values you can get it manually by dragging the > chart wall to the correct size. Therefore me concluded in comment 10 that we have to expose the wall position/size in the UI. > I think this report is duplicate to bug 43174 in regard to axis scaling. You can easily set a min/max. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154410] Improve Calc's Format > Align Text menu's contents and labels
https://bugs.documentfoundation.org/show_bug.cgi?id=154410 --- Comment #5 from Heiko Tietze --- The alternative that needs to be discussed is the existing "clear DF" function. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 80281] FORMATTING: "Keep aspect ratio" checkbox of images or photos not always honoured
https://bugs.documentfoundation.org/show_bug.cgi?id=80281 --- Comment #11 from Heiko Tietze --- (In reply to Stéphane Guillou (stragu) from comment #10) > want it discussed at the next UX meeting? It's on the agenda -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153248] Insert Caption and Caption Options dialogs have a mix of settings affecting the whole category or only current caption
https://bugs.documentfoundation.org/show_bug.cgi?id=153248 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #13 from Heiko Tietze --- We discussed the proposal in the design meeting without further suggestions. Sounds like a good topic for a GSoC project. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154211] Allow selecting a range between current cursor position and an element in Navigator with Shift + click (EDITING)
https://bugs.documentfoundation.org/show_bug.cgi?id=154211 Stéphane Guillou (stragu) changed: What|Removed |Added Resolution|DUPLICATE |WONTFIX --- Comment #5 from Stéphane Guillou (stragu) --- Maybe rather a "won't fix" then, because this is less about multiselect but more about using the navigator items as a "jump point" to select a range of text (and maybe tables or other things that can be selected together). "Won't fix" because there's always an active selection in the navigator, and therefore using Shift + Click should trigger a navigator multiselection when it can (once it's implemented, and as it's already implemented in e.g. Draw). In the specific case of headings, I assume such multiselection should be the equivalent of selecting multiple headings in the text with Ctrl key pressed. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 91415] Improve design of comment indicators to block less of the cell's content
https://bugs.documentfoundation.org/show_bug.cgi?id=91415 Bug 91415 depends on bug 153106, which changed state. Bug 153106 Summary: Revert commit of Bug 91415 - Scale Calc's comment indicator with zoom level (please, do not) https://bugs.documentfoundation.org/show_bug.cgi?id=153106 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154080] Comment indicator is too small, non-circumspect, easy to miss
https://bugs.documentfoundation.org/show_bug.cgi?id=154080 Heiko Tietze changed: What|Removed |Added Blocks||108019 CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=12 ||9847 Keywords|needsUXEval | --- Comment #11 from Heiko Tietze --- We discussed the topic in the design meeting. The indicator is easy to spot at 100% but might be a challenge in other zoom levels if the text overflow indicator is spread across the sheet together with comment indicators, both being red. The proposal is to move these two options out of tools > options > calc > view into application colors to allow the specification of other colors than red. MSO uses purple color for comments but has no overflow indicator (content is replaced by #). Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108019 [Bug 108019] [META] Calc UX bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Resolution|--- |NOTABUG Status|UNCONFIRMED |RESOLVED --- Comment #11 from Heiko Tietze --- We discussed the topic in the design meeting. LibreOffice offers the outstanding feature to merge cells in three different ways. Either the content if the cells to merge is collected into the new cell (eg. A1=1, B1=2 => A1 = 12), the cell content is kept hidden (and unmerging is possible), or only the content of the first cell is kept. If you copy a merged cell you expect the merged state to be taken into account. The same is true for clone format that takes the merge state as a formatting attribute and applies it to the target. It's a convenience feature in alignment to the copy function. Cell formatting is preferably done per cell style. The style with all defined attributes will be applied to the merged cells without affecting the state. => NAB -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154021] Customize dialog is too big to display on 1280x800 laptop screen GNOME (gtk3)
https://bugs.documentfoundation.org/show_bug.cgi?id=154021 --- Comment #16 from Heiko Tietze --- We discussed the topic in the design meeting. The question was if reducing the height by showing less items in the list makes sense and is desired. We rejected the idea as low res screens are dropping off the market and a patch would affect the usability for many solving issues for a few (and tweaking the font size helped in this case). => WF/NOB -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154211] Allow selecting a range between current cursor position and an element in Navigator with Shift + click (EDITING)
https://bugs.documentfoundation.org/show_bug.cgi?id=154211 Heiko Tietze changed: What|Removed |Added Keywords||needsUXEval Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||rayk...@gmail.com --- Comment #4 from Heiko Tietze --- The Navigator aims to navigate not to manipulate. In my opinion we should keep it simple. However, the request about multiselection has been done before (and wasn't questioned). Multi-selection means to ctrl+click tree items to toggle it's selection state. Shift+click in the tree would select all items up to the current position. There can't be a cursor position in the document. *** This bug has been marked as a duplicate of bug 129610 *** -- You are receiving this mail because: You are on the CC list for the bug.
