[Libreoffice-ux-advise] [Bug 145980] Table Alignment options are somewhat confusing, illustration needed
https://bugs.documentfoundation.org/show_bug.cgi?id=145980 --- Comment #2 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #1) > You may consult the help > https://help.libreoffice.org/7.4/en-US/text/swriter/01/05090100.html (which > has different terms). Yes, that does help, but as always - I'm against it being used as a crutch, and the UI must be somewhat, even if not perfectly, clear; and consistent. > We could change it to > > *Position* > (o) Full page size > ( ) Start from left > ( ) Start from right (I see no difference between "From Left" and "Right"; > the code [1] proves wrong; it needs more testing) > ( ) Centered > ( ) Manual This would already be an improvement. Some bikeshedding: "position" -> perhaps "positioning"? Not sure which is better. "full page size" -> "full page width" or "entire page width" are better. "Start from left" -> perhaps "Extend from left"? Not sure which is better. > We could also drop everything and have > > (o) Automatic Spacing > ( ) Manual Spacing > Left [ } > Right [ ] > ... > > meaning either full size Ah, but "automatic spacing" does not mean full size. It means that LO will add some (horizontal) space outside the table. Also, the use of "spacing" isn't clear enough in your proposed controls. It's already a bit unclear in the existing controls (instead of "Spacing" I would say "Space around table" or "Spacing around table", but in your proposed control it's really unclear what kind of spacing this is supposed to be: vertical/horizontal, inside/outside. Also, a centered table is not covered by your suggestion. I would like to suggest an alternative, but whatever I think of, I come up against the fact that the table width controls on the Columns tab actually also control the spacing for the Centered case, while choosing "full page size" here sets those width controls. This is why your saying that: > Since the table size is relevant for the column size we should merge both > tabs (see also bug 145739). resonates with me. Anyway, here's my current thought. It doesn't go all the way with the tab merging, but it could be part of a merged tab: Option 1: > *Horizontal Position:* > > [ _ ] [ _ ] [ _ ] >Left Table Right >Margin Width Margin > > Automatic settings: > ( ) Fill page width > ( ) Center > ( ) Align left > ( ) Align right > ( ) None > > -- > > *Vertical Positioning:* > > [ _ ] Top margin > > [ _ ] Bottom margin Option 2: > *Horizontal Position:* > > [ _ ] [ _ ] [ _ ] >Left Table Right >Margin Width Margin > > Positioning mode: > ( ) Center table > [ ] Fill page width > ( ) Align to one side: > ( ) Left > ( ) Right > ( ) Manual > > -- > > *Vertical Positioning:* > > [ _ ] Top margin > > [ _ ] Bottom margin Now, the actual margin and width controls in my proposal could be simple text boxes; or the horizontal part could constitute or augment illustration (like right and left indentation and the ruler illustration for paragraphs) ; or you could merge the horizontal and vertical controls to constitute or augment a 2D illustration. Also, and regardless of whether the controls change, I still think an illustration is in order regarding how the table will look on the page. > > [1] > https://opengrok.libreoffice.org/xref/core/sw/source/ui/table/tabledlg. > cxx?r=457a67a5#291 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 102002] Redesign of the Load Styles dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=102002 BogdanB changed: What|Removed |Added CC||buzea.bog...@libreoffice.or ||g --- Comment #20 from BogdanB --- What is the status of this bug? It appears as new, but also looks like it was resolved in 7.2. Seth Chaikli, do you have any info? Is this bug really solved? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146018] Group similar autofilter submenu items to save the vertical space
https://bugs.documentfoundation.org/show_bug.cgi?id=146018 --- Comment #9 from kabilo --- Created attachment 176673 --> https://bugs.documentfoundation.org/attachment.cgi?id=176673=edit another possible look of the automatic filter -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146018] Group similar autofilter submenu items to save the vertical space
https://bugs.documentfoundation.org/show_bug.cgi?id=146018 --- Comment #8 from Caolán McNamara --- Created attachment 176669 --> https://bugs.documentfoundation.org/attachment.cgi?id=176669=edit libreoffice current expanded view -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 145730] Flip Impress templates when locale setting is set to RTL language
https://bugs.documentfoundation.org/show_bug.cgi?id=145730 --- Comment #11 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #10) > (In reply to Eyal Rozenberg from comment #9) > > But then, what if you have an RTL page in your presentation followed by an > > LTR one? > > Good point. How about taking care of LTR/RTL in master slides so you can > switch from one to the other but manually? You mean, with different master slides linked to different templates? Or with masters with different directionality in the same template? This sound like a homunculus suggestion. Anyway, I don't really see most users altering master slides; my (anecdotal) experience suggests that most people are deterred from working with them. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 145980] Table Alignment options are somewhat confusing, illustration needed
https://bugs.documentfoundation.org/show_bug.cgi?id=145980 --- Comment #1 from Heiko Tietze --- You may consult the help https://help.libreoffice.org/7.4/en-US/text/swriter/01/05090100.html (which has different terms). We could change it to *Position* (o) Full page size ( ) Start from left ( ) Start from right (I see no difference between "From Left" and "Right"; the code [1] proves wrong; it needs more testing) ( ) Centered ( ) Manual Is this worth the effort for documentation and l10n? We could also drop everything and have (o) Automatic Spacing ( ) Manual Spacing Left [ } Right [ ] ... meaning either full size or to always start with zero distance from the left page border for LTR resp. from right in case of RTL. If users want something else it can be done manually. Since the table size is relevant for the column size we should merge both tabs (see also bug 145739). [1] https://opengrok.libreoffice.org/xref/core/sw/source/ui/table/tabledlg.cxx?r=457a67a5#291 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146018] Group similar autofilter submenu items to save the vertical space
https://bugs.documentfoundation.org/show_bug.cgi?id=146018 --- Comment #7 from Caolán McNamara --- Created attachment 176668 --> https://bugs.documentfoundation.org/attachment.cgi?id=176668=edit google sheets example -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146018] Group similar autofilter submenu items to save the vertical space
https://bugs.documentfoundation.org/show_bug.cgi?id=146018 --- Comment #6 from Caolán McNamara --- Created attachment 176667 --> https://bugs.documentfoundation.org/attachment.cgi?id=176667=edit excel using english UI -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146018] Group similar autofilter submenu items to save the vertical space
https://bugs.documentfoundation.org/show_bug.cgi?id=146018 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #5 from Roman Kuznetsov <79045_79...@mail.ru> --- (In reply to Heiko Tietze from comment #4) > Eventually it would be: > > Sort | Ascending | Descending > All Values | Top 10 | Empty | Not Empty > Color | Text > | Background > > Standard Filter > Clear All Filter > [Search Items] May be this variant will be better: Sort Ascending Sort Descending All Values | Top 10 | Empty | Not Empty Text Color (should be context depended, if there is any color different from Auto) Background Color (should be context depended, if there is any color different from None) Standard Filter Clear Filter [Search items...] And let's set it to NEW -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 145730] Flip Impress templates when locale setting is set to RTL language
https://bugs.documentfoundation.org/show_bug.cgi?id=145730 --- Comment #10 from Heiko Tietze --- (In reply to Eyal Rozenberg from comment #9) > But then, what if you have an RTL page in your presentation followed by an > LTR one? Good point. How about taking care of LTR/RTL in master slides so you can switch from one to the other but manually? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146018] Group similar autofilter submenu items to save the vertical space
https://bugs.documentfoundation.org/show_bug.cgi?id=146018 Heiko Tietze changed: What|Removed |Added CC|heiko.tietze@documentfounda |79045_79...@mail.ru, |tion.org|libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #4 from Heiko Tietze --- Comparing gtk and win is not fair. But for the grouping I second your idea, at least for the filter items (to name it). It requires an additional "All Values" entry shown when closed. Sort is not really a function of the auto filter, we could remove it. Otherwise it's convenient and could be as suggested. In respect to the color items, we should consider the uncommon interaction (checkbox selection in a menu). Clicking through a deep menu structure adds annoyance here. Eventually it would be: Sort | Ascending | Descending All Values | Top 10 | Empty | Not Empty Color | Text > | Background > Standard Filter Clear All Filter [Search Items] Is this really a win? -- You are receiving this mail because: You are on the CC list for the bug.
