[Libreoffice-ux-advise] [Bug 148282] Page Area in Start Center Does Not Respect Application Colors Scheme
https://bugs.documentfoundation.org/show_bug.cgi?id=148282 --- Comment #3 from Rizal Muttaqin --- (In reply to V Stuart Foote from comment #2) > The "thumbnail" previews are simply not re-created / re-generated on > application color "mode" change (which really is just a static application > of a different set of fixed colors from the "default" theme). So, if it's the method why Draw and Impress ignore those static set of fixed colors? Here I'm assuming the two modules instead take values from the Application Colors' color scheme arbitrarily. Or am I wrong? > That seems kind of a waste of dev effort... I'd rather we expend the effort > on extending the slate of UI widgets that can be controlled by the > Application Color theme. Wasting time is a very relative thing. LibreOffice development puts forward the model of who wants to change something, then he contributes. But I fully support this approach. Application Color must be able to force UI widgets whether to follow the operating system's default UI theming (Let's say this color value will be defined as "default") or custom color. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148282] Page Area in Start Center Does Not Respect Application Colors Scheme
https://bugs.documentfoundation.org/show_bug.cgi?id=148282 V Stuart Foote changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vstuart.fo...@utsa.edu --- Comment #2 from V Stuart Foote --- The "thumbnail" previews are simply not re-created / re-generated on application color "mode" change (which really is just a static application of a different set of fixed colors from the "default" theme). But the thumbnail preview mechanisim probably should be adjusted to produce a "dark mode" preview, at least for when that was the mode the document was opened in. Otherwise while it should be inexpensive to rebuild the previews--responding to light/dark mode change would require refactoring to handle all the thumbnail views held in a users MRU, essentially reopening each document held in history to rebuild its thumbnail view (1st page of document) and record it back to per-user profile registrymodification.xcu in response to a mode change. That seems kind of a waste of dev effort... I'd rather we expend the effort on extending the slate of UI widgets that can be controlled by the Application Color theme. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 144561] UI: add quick sort links to the right click menu for the column headers to sort a sheet based on that column.
https://bugs.documentfoundation.org/show_bug.cgi?id=144561 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Whiteboard| QA:needsComment| Keywords||needsUXEval --- Comment #1 from Roman Kuznetsov <79045_79...@mail.ru> --- I don't think we need it We have icons for sorting on the toolbar -1 from me -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 142498] UI: Highlight the found search text in cell
https://bugs.documentfoundation.org/show_bug.cgi?id=142498 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Whiteboard| QA:needsComment| Keywords||needsUXEval Blocks||108019, 113731 --- Comment #1 from Roman Kuznetsov <79045_79...@mail.ru> --- +1 but I'm not sure it's possible Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108019 [Bug 108019] [META] Calc UX bugs and enhancements https://bugs.documentfoundation.org/show_bug.cgi?id=113731 [Bug 113731] [META] Highlight bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147828] "Select to Next Sentence" does not work properly when the current sentence ends with a period and the next sentence does not have a capital letter at the beginning
https://bugs.documentfoundation.org/show_bug.cgi?id=147828 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=12 ||4552 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147828] "Select to Next Sentence" does not work properly when the current sentence ends with a period and the next sentence does not have a capital letter at the beginning
https://bugs.documentfoundation.org/show_bug.cgi?id=147828 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=12 ||5174 --- Comment #7 from V Stuart Foote --- This is locale specific and should depend on ICU lib word break / sentence break iterators for the bounds in the general case, but I've doubts we do so. Instead using viewshell hacks that miss punctuation and grammar in specific cases as here and in the see also bug 125174 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148258] Regaining user control over keyboard customization
https://bugs.documentfoundation.org/show_bug.cgi?id=148258 Vince changed: What|Removed |Added CC||vre...@cox.net --- Comment #4 from Vince --- (In reply to V Stuart Foote from comment #3) > Thanks for the patch, not sure it is really of any help as it is gtk3 only Only one part of the patch is gtk3 and I honestly do not expect that to be accepted as is. I am hoping that this leads to another solution to bug 144846 that doesn't remove ability to customize alt+letter keystrokes when vtk == gtk. > and applies just to writer. The other part of the patch does apply only to writer table sizing keystrokes since that is the source of the older bug reports. I am sure that there are other cases within writer and the other modules wherein keystrokes are processed and consumed without considering that they may have been customized. > More general structure for mix of core short-cut > binding, short-cuts assigned to UNO controls, and mnemonic 'accelerators' > assigned dynamically or by l10n to the various UI controls--and the user > 'customization' available to each category does need review and alignment. Absolutely! I would hope that outcome of such a review would still leave users the ability to customize the behaviour of as wide a range of keystrokes as possible while at the same time "protecting" them from doing stupid or insane things ... like remapping the arrow keys:) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147828] "Select to Next Sentence" does not work properly when the current sentence ends with a period and the next sentence does not have a capital letter at the beginning
https://bugs.documentfoundation.org/show_bug.cgi?id=147828 V Stuart Foote changed: What|Removed |Added CC||vstuart.fo...@utsa.edu --- Comment #6 from V Stuart Foote --- This is a ICU wordbound/sentence bound issue. It also affects the cyclic multi-click mouse selection: double--word, triple--sentence, quad--para. Believe the logic for the sentence bound is structured with ICU lib calls. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148258] Regaining user control over keyboard customization
https://bugs.documentfoundation.org/show_bug.cgi?id=148258 sdc.bla...@youmail.dk changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147828] "Select to Next Sentence" does not work properly when the current sentence ends with a period and the next sentence does not have a capital letter at the beginning
https://bugs.documentfoundation.org/show_bug.cgi?id=147828 Dieter changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #5 from Dieter --- (In reply to sdc.blanco from comment #3) >- How many times do you have an abbreviation with a dot in a sentence? > (i.e., statistically, relatively rare case for selection) In a German text very often (z.B., v.a., u.a., evtl., ggf.) > Here is a test case: This is abc. and nothing else. how does this work. > > Actual behavior if starting at T and pressing Ctrl+Shift+S, then entire line > is selected (which then requires having to back up). > > Proposed behavior: Stops selection after "abc" and then stops selection > after "else". I'm fine with that proposal. Let's ask design-team for decision. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 115311] UI missing for nesting character styles
https://bugs.documentfoundation.org/show_bug.cgi?id=115311 --- Comment #18 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #17) > Don't remember the state in 23018 but with v7.3 at least it is possible to > make one CS inherent from another by drag and drop at the Stylist. But that's not what this bug is about. It's about applying more than one character style to the same piece of text, not about styles inheriting from each other. See your own comment here: https://bugs.documentfoundation.org/show_bug.cgi?id=127754#c2 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148257] Missing/unexposed ability to explicitly set the "language group" of a piece of text
https://bugs.documentfoundation.org/show_bug.cgi?id=148257 --- Comment #6 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #5) > What exactly is the use case / scenario then? Besides convenience. I thought the title of the bug made it clear... It's more than about a use-case, it's a matter of principle: * It does not make sense that setting a direction also sets the language. * It does not make sense, and is not tolerable, that changing the direction of a run of text changes its font. In the attached document, the 12:35 should not appear in the CTL font. And at the very least, it should be easy to prevent that from happening, and easy to indicate it's in English rather than Hebrew (which would make it use the Western language group font). At the moment, it just can't be done: You can't say it's in English, and you can't set its font to the Western languages group font. (You could change the CTL font to the Western language font but that's a hack, not a solution.) (I'll also say that it's not obvious what the font selection logic for "None"-language text should be, but that also would be another bug.) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146910] [UI Enhance] ease to use the same font for Western and Asian
https://bugs.documentfoundation.org/show_bug.cgi?id=146910 --- Comment #15 from Eyal Rozenberg --- As an RTL language user, I'll say I also sometimes want to set the Western and RTL language fonts to the same one. But - it's not frequent enough to necessitate its own UI. Plus, if anything, I might want to set a different font for Hebrew and for Arabic or Farsi, and that's not supported at all... -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148257] Missing/unexposed ability to explicitly set the "language group" of a piece of text
https://bugs.documentfoundation.org/show_bug.cgi?id=148257 --- Comment #5 from Heiko Tietze --- (In reply to Eyal Rozenberg from comment #3) > ...this bug is only about language+font selection What exactly is the use case / scenario then? Besides convenience. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 115311] UI missing for nesting character styles
https://bugs.documentfoundation.org/show_bug.cgi?id=115311 --- Comment #17 from Heiko Tietze --- Don't remember the state in 23018 but with v7.3 at least it is possible to make one CS inherent from another by drag and drop at the Stylist. We also have the "Inherit from" field in the Organizer tab. And the nested CS takes attributes from the parent. So all works similar to PS. Regina, resolve WFM or am I missing a point? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148257] Missing/unexposed ability to explicitly set the "language group" of a piece of text
https://bugs.documentfoundation.org/show_bug.cgi?id=148257 --- Comment #4 from Eyal Rozenberg --- Moreover, even if manually changing the language group to "none" helped, that wouldn't resolve the bug, because: * People would not easily figure out that's what they need to do. * No right-click menu UI for this. * There are parity issues with MS Office for .doc and .docx document importation. * Autocorrect cannot be assumed to be applied by default, and is anyway something optional, not to be relied on. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147963] ENDNOTES: Provide option to set different page styles for left and right endnote pages
https://bugs.documentfoundation.org/show_bug.cgi?id=147963 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||vmik...@collabora.com Status|UNCONFIRMED |NEW -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148257] Missing/unexposed ability to explicitly set the "language group" of a piece of text
https://bugs.documentfoundation.org/show_bug.cgi?id=148257 --- Comment #3 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #2) > The only issue for me is when I select the number/date - as it is RTL I > cannot mark from left. ... but that would be a whole different bug page, about selection. That is annoying, actually; would you open a separate bug about it? Anyway, to be clear, this bug is only about language+font selection, and especially the font. > But changing the language to None (we have a section > in the status bar to quickly reach language options) does the trick. I don't think so. When I did this, it set the language in all groups to "none", but the font didn't change. Which means it probably didn't change the language-group selection either. > The language group is maybe only a virtual thing meaning just at the UI, > haven't check the ODF. Although the idea to get rid of it was rejected in > bug 146910 it was at least worth to discuss. Ok. But - I'm not taking a position on that matter here. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148257] Missing/unexposed ability to explicitly set the "language group" of a piece of text
https://bugs.documentfoundation.org/show_bug.cgi?id=148257 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||6928 Severity|normal |enhancement CC||frank...@goodhorse.idv.tw, ||jo3...@jarl.com, ||libreoffice-ux-advise@lists ||.freedesktop.org, ||naru...@gmail.com, ||shinji.en...@gmail.com --- Comment #2 from Heiko Tietze --- The only issue for me is when I select the number/date - as it is RTL I cannot mark from left. But changing the language to None (we have a section in the status bar to quickly reach language options) does the trick. The language group is maybe only a virtual thing meaning just at the UI, haven't check the ODF. Although the idea to get rid of it was rejected in bug 146910 it was at least worth to discuss. Possible solution to the number problem might be to add this to the AutoCorrect options as "[ ] Use 'None' for language in case of numbers". Wonder how CJK people deal with the problem. -- You are receiving this mail because: You are on the CC list for the bug.
