[Libreoffice-ux-advise] [Bug 154795] Font selection pane offers choice of "language" - which isn't.
https://bugs.documentfoundation.org/show_bug.cgi?id=154795 Eyal Rozenberg changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #2 from Eyal Rozenberg --- (In reply to Regina Henschel from comment #1) > The field there sets a language/country pair. If you select > "English(Israel)" you get fo:language="en" and fo:country="IL". > > You need this information, for example, to select the appropriate > dictionaries, thesauri, hyphenation rules, and AutoCorrect entries. ... none of which are relevant when choosing a _font_. Changing a font should have no effect on dictionaries, thesauri, hyphenation or autocorrect. So, clearly, the choice of country should be placed somewhere closed to where we control or configure the use of these features. > Are you sure there exists items, which are not considered somewhere? For > example, you can define your own AutoCorrect entries for each of the items > in this 'Language' drop-down list. Even if choosing a country is significant in some contexts, there is rarely a need to choose a pair from the Cartesian product of language x country (as opposed to local language variants). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155054] UI: Remediate frustration of unclear style names in style-name picklist contexts
https://bugs.documentfoundation.org/show_bug.cgi?id=155054 --- Comment #3 from R. Bingham --- FYI, this attachment/comment may show multiple times. I submitted it but it is now not showing in Bugzilla when I re-query this bug 155054. Thanks. I volunteer edit a wide range of documents, accumulating my own library of OTTs AND a library of 100s of styles (for all style types shown in Navigator) across multiple OTTs. I have become very sensitive to the clunky parts of the LO UI regards 'enterprise' style creation and curation for consistency across OTTs. I dream of an enterprise database of LO styles I can manage via a spreadsheet-like presentation for consistency and parameter-value patterns across all my OTTs. Sigh... In the meantime I must make do with the OTT by OTT, style-by-style tabbed-pane GUI. Navigator is my friend. Inheritance is my friend for managing commonality of parameter value sub-sets in tree children. The attached screenshot... well, no, Bugzilla Attachment submission not working at the moment, so laboriously re-create in text here Heading Appendix Hd VolSer 100 LOO LeftAlign Sans parent_only Hd VolSer 110 LOG LftA KeepNext Sans parent_only Hd VolSer 260 VS Vol L03 F/13_Mattr H FM_Title Hd VolSer 264 VS Vol LD4 F/13_Mattr L2 Hd VolSer 268 VS Vol LOS F/B_Mattr L3 Hd VolSer 320 VS Vol Wart L04 UB_I'vlattr LI Hd VolSer 330 VS Vol Wart L05 UB_Mattr L2 Hd VolSer 510 VS Vol Wart 1-StorySet L04 StorySetTitle Hd VolSer 520 VS Vol Wart 1-StorySet L05 F/B_Mattr L1 Hd VolSer 530 VS Vol Wart 1-StorySet LO6 F/B_Mattr L2 Hd VolSer 610 VS Vol Wart 1-StorySet Story LOS StoryTitle L1 Hd VolSer 620 VS Vol Vpart 1-StorySet Story LOS StoryTitle L2 Hd VolSer 710 Vol Wart 1-StorySet Story Chap LD6 ChapTitle L1 Hd VolSer 715 VS Vol Wart 1-StorySet Story Chap LO6 ChapTitle L1 AutoNbr Hd VolSer 720 VS Vol Vpart 1-StorySet Story Chap L06 ChapTitle L2 SubTitle Hd VolSer 730 VS Vol Vpart 1-StorySet Story Chap Anno L07 LO parent_only Hd VolSer 734 VS Vol Vpart 1-StorySet Story Chap Anna 1_07 L1 SubChapTitle Hd VolSer 740 VS Vol VPart 1-StorySet Story Chap Anno L08 L2 Topic Hd VolSer 740 Vol Wart 1-StorySet Story Chap Anno LOB L2 SH_Crono Hd VolSer 780 VS Vol Vpart 1-StorySet Story Chap Anna L10 L4 Char Hd VolSer 150 VS LO1 VolSerTitle Hd VolSer 210 VS Vol L02 VolTitle L1 Hd VolSer 220 VS Vol 1_02 VolTitle L2 SubTitle Hd VolSer 310 VS Vol Wart L03 VpartTitle Hd VolSer L09 LftA Hdr def placeholder Heading 1 ... shows a small part of one of my paragraph styles trees still evolving. Note how I use 'parent only' styles not intended for actual doc use to both encode key parameter value choices in the style name and as a holder of those values for the children. Note how I have had to develop a hints encoding scheme for the style terminal name for when it appears in a tabbed-pane flat picklist. The encoding scheme not only hints at parameter values but also leverages the style-name string sort that usefully happens in both picklist and Navigator presentations. Building up this sort/grouping gives each style-name item a surrounding context as an implicit additional hint of meaning. The encoding burden on the terminal sytle-name could be much less in the Navigator hierarchial view since the inheritance parents are there to also carry some of the encoding in their names as well. I note that Navigator does not offer inheritance for Pages, Lists, and Tables styles. Sadness, and my next UI enhancement requests. Regards. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147680] Autotext replacement not willing to ignore space after shortcut
https://bugs.documentfoundation.org/show_bug.cgi?id=147680 --- Comment #9 from Eyal Rozenberg --- (In reply to V Stuart Foote from comment #8) > I see no benefit to including the trailing space for the F3 Autotext > shortcut handling The benefit is that half the time I type an autotext entry key, I also type a space, because I'm used to typing a space after every word. >, and a serious downside of inadvertent replacements by > allowing any non-exact matching. But that's the whole point - it's not inadvertant - it's advertant! It is what the user asked for. > The AutoText dialog +F3 shortcut field does not allow/accept space (or > other whitespace that I tried) for defining a AutoText passage. Even better - that means that there is even less doubt about what the user wanted. Now, if someone were to proposed generalized fuzzy matching - that certainly has downsides and I'd not make it the default behavior. Here we're talking about a very specific case where user intent is clear. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147680] Autotext replacement not willing to ignore space after shortcut
https://bugs.documentfoundation.org/show_bug.cgi?id=147680 V Stuart Foote changed: What|Removed |Added CC||vsfo...@libreoffice.org --- Comment #8 from V Stuart Foote --- I see no benefit to including the trailing space for the F3 Autotext shortcut handling, and a serious downside of inadvertent replacements by allowing any non-exact matching. The AutoText dialog +F3 shortcut field does not allow/accept space (or other whitespace that I tried) for defining a AutoText passage. Behaving as implemented. -1 to any change, and otherwise => NAB -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147680] Autotext replacement not willing to ignore space after shortcut
https://bugs.documentfoundation.org/show_bug.cgi?id=147680 Eyal Rozenberg changed: What|Removed |Added Resolution|NOTABUG |--- Status|RESOLVED|UNCONFIRMED --- Comment #7 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #6) > Neither Dieter or me expect white-space being part of shortcuts. Dieter said that in his opinion this could be an enhancement. So, not enough grounds for closing this. > Consider also the word finalization Not sure what you mean by that. > some procedures run like spell checking and auto correction. => NAB I'm not sure how these things relate to my request. When you've typed some text and press the autotext shortcut (F3), two things can happen: A replacement, or nothing. Now, think about it: Why would I press this shortcut unless I expect a replacement? That's my extremely-likely intent. Now, if there's a "perfect" match for an autotext key in the preceding text, there's no dilemma and you just replace. And if we have no idea what to replace with, we shouldn't just guess. Also, if there are two entries which are just as likely, one could also argue we shouldn't arbitrarily choose one. But - in this case, we have a single candidate entry, and an extra space. What is more likely? That I would rather LO not replace anything, or that what I want is for the space to be elided? You will be hard-pressed to claim the first response is what the user wants, or expects. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155054] UI: Remediate frustration of unclear style names in style-name picklist contexts
https://bugs.documentfoundation.org/show_bug.cgi?id=155054 V Stuart Foote changed: What|Removed |Added Summary|UI: Remediate frustration |UI: Remediate frustration |of opaque style names in|of unclear style names in |style-name picklist |style-name picklist |contexts|contexts CC||vsfo...@libreoffice.org --- Comment #2 from V Stuart Foote --- slight edit to summary s/opaque/unclear -- on first read I'd assumed it was a dark-mode rendering issue ;-) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154788] The default width of Calc columns should be a bit narrower
https://bugs.documentfoundation.org/show_bug.cgi?id=154788 --- Comment #30 from Rafael Lima --- (In reply to Heiko Tietze from comment #29) > Asked of Mastodon [1] and 63% out of 408 people voted to keep the current > width... Thank you for the effort of considering this change =) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155054] UI: Remediate frustration of opaque style names in style-name picklist contexts
https://bugs.documentfoundation.org/show_bug.cgi?id=155054 Dieter changed: What|Removed |Added CC||dgp-m...@gmx.de, ||libreoffice-ux-advise@lists ||.freedesktop.org Blocks||107833, 108346 Keywords||needsUXEval --- Comment #1 from Dieter --- R. Bingham, thank you for the enhancement request. Topic A is related to the combobox, while topic B is more genral about a more significant name of paragraph styles. So perhaps it would be better to have two different bug reports, but first let's add design-team for further input and perhaps decision. cc: Design-Team Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=107833 [Bug 107833] [META] Writer paragraph style bugs and enhancements https://bugs.documentfoundation.org/show_bug.cgi?id=108346 [Bug 108346] [META] Writer paragraph style combobox control bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155169] Inconsistent behavior of Cmd+left/right arrow on macOS
https://bugs.documentfoundation.org/show_bug.cgi?id=155169 Telesto changed: What|Removed |Added Keywords|needsUXEval | 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 155169] Inconsistent behavior of Cmd+left/right arrow on macOS
https://bugs.documentfoundation.org/show_bug.cgi?id=155169 Telesto changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval -- You are receiving this mail because: You are on the CC list for the bug.
