[Libreoffice-ux-advise] [Bug 151159] StartCenter: Document Filter: rename from `All Applications` to `All Documents`
https://bugs.documentfoundation.org/show_bug.cgi?id=151159 Rafael Lima changed: What|Removed |Added Blocks||61914 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=61914 [Bug 61914] [META] Start Center bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151159] StartCenter: Document Filter: rename from `All Applications` to `All Documents`
https://bugs.documentfoundation.org/show_bug.cgi?id=151159 Rafael Lima changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #3 from Rafael Lima --- Let's hear the opinion of the UX team. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151185] Impress: Table design icon without function
https://bugs.documentfoundation.org/show_bug.cgi?id=151185 Rafael Lima changed: What|Removed |Added CC||rafael.palma.l...@gmail.com Blocks||100366 --- Comment #2 from Rafael Lima --- This isn't a bug per se. The "Table Design" command simply opens the Table Design sidebar. If it is already open, then nothing happens. (In reply to Timur from comment #1) > But let's hear UX on changing this icon to dropdown with table designs. I'm not sure this would be the way to go, because the current implementation of Table Design needs a deeper rework. Basically, the available set of table styles is hardcoded (see bug 34391, bug 38213 and bug 74142). There's also bug 101802 that requests an integration of Table Design across Writer / Draw / Impress, which seems the better approach. So I believe that when these enhancements have been made, this bug report will be automatically fixed. The main question is whether any dev will take on these huge tasks. I am an avid user of Impress Tables and I can tell that table support in Impress/Draw is very lacking and buggy. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=100366 [Bug 100366] [META] Impress/Draw table bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 100100] Emoji toolbar control
https://bugs.documentfoundation.org/show_bug.cgi?id=100100 V Stuart Foote changed: What|Removed |Added Depends on||144348 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=144348 [Bug 144348] Remove bundled emoji font -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151122] Need way to avoid selecting fonts which don't cover the relevant language Unicode range
https://bugs.documentfoundation.org/show_bug.cgi?id=151122 --- Comment #15 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #13) > What bothers is the wish to get some very broad information at > a control that is simply a picker. But if we turn it around I just need to know the font I'm selecting covers my language(s). The title may overstate what's necessary, I've rephrased it. > unicode coverage does not match the paragraph language. There's a language choice underneath the picker - I believe it's better to go with that one. That can also allow the user to require coverage of multiple languages or no language. I haven't made up my mind regarding whether I like italicizing, graying-out or filtering-out better. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151122] Need way to avoid selecting fonts which don't cover the relevant language Unicode range
https://bugs.documentfoundation.org/show_bug.cgi?id=151122 Eyal Rozenberg changed: What|Removed |Added Summary|Need some indication of |Need way to avoid selecting |font (family) coverage |fonts which don't cover the |range when selecting fonts |relevant language Unicode ||range -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151122] Need some indication of font (family) coverage range when selecting fonts
https://bugs.documentfoundation.org/show_bug.cgi?id=151122 --- Comment #14 from Eyal Rozenberg --- (In reply to V Stuart Foote from comment #11) > There are already some fabulous programs for doing font > selection based on its Unicode coverage. Point being > these font management features do not belong in an office > product bcz they are handled better either by os/DE > provided apps--eg fontconfig and the fc- utilities or the > ancient xfd or xfontsel, or by any number of GUI based > character map utilities including the GNOME Character Map. You seem to be suggesting LO remove its font selection dialog, or the font selection pane of the font dialog, entirely... Font selection belongs in (almost) any application in which the user needs to select fonts. And while complex font exploration may perhaps be better suited for a different app, it is not a complex or esoteric task to want to choose a font which can be used for the language you want to write in; and my office productivity app must help me avoid choosing fonts (or font families) which don't cover the language I'm making the choice for. > It has *ALL* the features that Eyal is asking for, I asked for just one thing. And I'm not even the one who asks for it; I would argue every user asks for it: Not misdirected into choosing an invalid font for the language I'm writing in. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151170] Need mechanism for re-centering "Slides pane" onto current slide with edit focus
https://bugs.documentfoundation.org/show_bug.cgi?id=151170 --- Comment #8 from Eyal Rozenberg --- (In reply to V Stuart Foote from comment #7) > NO it is strictly a feature request for the Slide / Page pane -- which > technically is a list as Heiko notes. Stuart is exactly right. (In reply to Heiko Tietze from comment #3) > Do we talk about what slide is the currently active - which is clearly shown > in the slides bar by highlighting Ah, but it isn't always. That is, the currently active slide is only shown in the slides bar if its scroll position is close enough to the slide's position. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151170] Need mechanism for re-centering "Slides pane" onto current slide with edit focus
https://bugs.documentfoundation.org/show_bug.cgi?id=151170 V Stuart Foote changed: What|Removed |Added Resolution|NOTABUG |--- Status|RESOLVED|UNCONFIRMED --- Comment #7 from V Stuart Foote --- NO it is strictly a feature request for the Slide / Page pane -- which technically is a list as Heiko notes. Nothing at all to do with Zoom of the currently active slide/page! Read the description, and its blocking of bug 102283 The request is for a means to control the list of slides/pages to position the list view to the active slide/page without risk of changing onto a different slide. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151170] Need mechanism for re-centering "Slides pane" onto current slide with edit focus
https://bugs.documentfoundation.org/show_bug.cgi?id=151170 Timur changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #6 from Timur --- I also understood that View > Zoom > Entire Page is what's described here. Let's close. Note bug 38164. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151185] Impress: Table design icon without function
https://bugs.documentfoundation.org/show_bug.cgi?id=151185 Timur changed: What|Removed |Added Priority|medium |low OS|Linux (All) |All Summary|Icon without function |Impress: Table design icon ||without function Severity|normal |enhancement Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #1 from Timur --- Icon opens sidebar with table design. But let's hear UX on changing this icon to dropdown with table designs. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151170] Need mechanism for re-centering "Slides pane" onto current slide with edit focus
https://bugs.documentfoundation.org/show_bug.cgi?id=151170 --- Comment #5 from Heiko Tietze --- (In reply to V Stuart Foote from comment #4) > Issue is that an imprecise click-hold of the scrollbar thumb can too easily > change selection of the active slide in Impress (or page in Draw). Like in any other list. With the difference that the slide/page is large and clearly highlighted. -1 from my side. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151170] Need mechanism for re-centering "Slides pane" onto current slide with edit focus
https://bugs.documentfoundation.org/show_bug.cgi?id=151170 V Stuart Foote changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED Ever confirmed|1 |0 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151170] Need mechanism for re-centering "Slides pane" onto current slide with edit focus
https://bugs.documentfoundation.org/show_bug.cgi?id=151170 --- Comment #4 from V Stuart Foote --- (In reply to Heiko Tietze from comment #3) The Slides pane, obviously. Issue is that an imprecise click-hold of the scrollbar thumb can too easily change selection of the active slide in Impress (or page in Draw). For Presentations (or Drawings) with more than a few slides it can be very disruptive to have to reidentify and position to the slide (or drawing page) you were working on. This additional UNO control to re-center the pane without risk of bumping the focus onto another slide would be useful assigned to a menu, a context menu or a keyboard shortcut. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151170] Need mechanism for re-centering "Slides pane" onto current slide with edit focus
https://bugs.documentfoundation.org/show_bug.cgi?id=151170 Timur changed: What|Removed |Added Priority|medium |low Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151133] Remove empty rows faster in Calc (add in LO instead of extension)
https://bugs.documentfoundation.org/show_bug.cgi?id=151133 Timur changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED Ever confirmed|1 |0 --- Comment #10 from Timur --- I also agree that a command would be useful. Working with rows/columns is a core Calc feature and a need may arise during regular user's work, regardless how often it will be used. I think it's much better to have it confirmed with Lowest Enh and info on extension than to close and for sake tell: no need for this in Calc. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151133] Remove empty rows faster in Calc (add in LO instead of extension)
https://bugs.documentfoundation.org/show_bug.cgi?id=151133 --- Comment #9 from Rafael Lima --- (In reply to Heiko Tietze from comment #8) > Nothing to say against an extension, however. And improving it as well as > having it on our extension site is a big plus. Other opinions? The extension is also available in: https://extensions.libreoffice.org/en/extensions/show/5747 I just need to update it to the latest version in LO extension website. (In reply to Heiko Tietze from comment #8) > I don't see this as a frequent use case. It is hard to assess how frequent this use case is. All I can say is that I use it very often. The 3 main use cases for me are: 1) Copying and pasting data from web pages often result in empty lines depending on how the original web page was organized; so removing these empty rows in a quick manner is very helpful 2) Sometimes working with long data tables I need to manually remove some lines. It is easier to simple remove their contents first (using Delete key) than using the Remove Row command (which shows a dialog, requiring more clicks). After removing all the rows, I simply compact the data table. 3) In lectures, I often use Calc to illustrate how a certain algorithm processes a matrix of data, which involves deleting rows one at a time. So what I do is simply delete the cell contents (using the Delete key) and at the end of the iteration I compact the data using this extension. I understand that these uses cases may be a little "niche", which is why I developed it as an extension. But if some day a dev wishes to implement this functionality into LO natively, I would be very pleased =) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 115645] Should be able to permanently delete comments with track changes enabled.
https://bugs.documentfoundation.org/show_bug.cgi?id=115645 --- Comment #13 from Timur --- In comment 1 I proposed to add comment menu item "Remove All Deleted Comments" on tracked deleted comments. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 144348] Remove bundled emoji font
https://bugs.documentfoundation.org/show_bug.cgi?id=144348 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists | |.freedesktop.org| Keywords|needsUXEval | Summary|Emoji font |Remove bundled emoji font --- Comment #12 from Heiko Tietze --- (In reply to Heiko Tietze from comment #0) > While I personally hate when an application unsolicited installs fonts and > vote for putting these add-ons into extensions... (In reply to Mike Kaganski from comment #2) > And personally I'm for removal of *all* fonts that are not required for the > application operation from the package. (In reply to V Stuart Foote from comment #11) > +1, drop the bundled emoji font. Do it. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151144] Options dialog. Move "Allow use of OpenCL" option to LibreOffice Calc > Calculate subsection
https://bugs.documentfoundation.org/show_bug.cgi?id=151144 Heiko Tietze changed: What|Removed |Added Keywords||needsDevAdvice --- Comment #3 from Heiko Tietze --- Sounds reasonable. But OpenCL requires to restart. Not necessarily a blocker. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151155] Rename Enable very large spreadsheets (16m rows, 16384 cols) option to shorter and more correct
https://bugs.documentfoundation.org/show_bug.cgi?id=151155 --- Comment #2 from Heiko Tietze --- The actual number is better suited for the tooltip. Would rather shorten the label to "Enable large spreadsheets" with the tooltip "If enabled, you can use up to 16 million rows on small cost of memory and performance.", or the like. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151111] Paste special mechanism significantly deficient in options
https://bugs.documentfoundation.org/show_bug.cgi?id=15 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 --- Comment #4 from Heiko Tietze --- So you are using the context menu and not the paste special dialog (shift + ctrl + insert or context menu paste special > paste special...). Thing is that a selection of option is pretty random here but requires a UNO command. So we decided for example on bug 145414 to not add more options. Reading comment 0 it sounds as if you challenge the redundancy. Don't get this and wait to resolve the ticket as WF. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151122] Need some indication of font (family) coverage range when selecting fonts
https://bugs.documentfoundation.org/show_bug.cgi?id=151122 --- Comment #13 from Heiko Tietze --- What bothers is the wish to get some very broad information at a control that is simply a picker. But if we turn it around and show incongruencies it makes sense. We draw the font name in italic if not available on the system and could so something similar if the listed font item unicode coverage does not match the paragraph language. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151161] StartCenter: Document filter: add tooltip instead of permanent description in UI
https://bugs.documentfoundation.org/show_bug.cgi?id=151161 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #3 from Heiko Tietze --- (In reply to V Stuart Foote from comment #2) > The 'Filter:' label of the combination box is necessary for Keyboard > navigation of the UI and Assistive Technology support. Needs to stay for > a11y reasons. This, and labels are good for newcomers. At some point I'd like to add a Sort-function too so you can have the most recent document on top or the largest etc. And it's not that we don't have the space... Regarding a11y I'm not sure whether this is implemented correctly. Worth a ticket if missing. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 140760] (PIVOTTABLE) selection of invalid constraint values possible and probably this irreversibly results in an empty pivot table
https://bugs.documentfoundation.org/show_bug.cgi?id=140760 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #16 from Heiko Tietze --- Let's keep the discussion here to the point - tagged the comments regarding autofilter as off-topic. My take is that we should do the same at pivot filter. Meaning the list is updated after items got selected. Excel behaves here not consistent. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151133] Remove empty rows faster in Calc (add in LO instead of extension)
https://bugs.documentfoundation.org/show_bug.cgi?id=151133 Heiko Tietze changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #8 from Heiko Tietze --- I don't see this as a frequent use case. If you want to get rid of data you can remove a col/row with content. And isn't the compact function (removing all empty col or row) dangerous since you may have references that most often but not always needs adjustment. Nothing to say against an extension, however. And improving it as well as having it on our extension site is a big plus. Other opinions? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151170] Need mechanism for re-centering "Slides pane" onto current slide with edit focus
https://bugs.documentfoundation.org/show_bug.cgi?id=151170 --- Comment #3 from Heiko Tietze --- Do we talk about what slide is the currently active - which is clearly shown in the slides bar by highlighting - or about the slider canvas that you can center with View > Zoom > Entire Page. Don't see need for more interactive controls. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151133] Remove empty rows faster in Calc (add in LO instead of extension)
https://bugs.documentfoundation.org/show_bug.cgi?id=151133 Timur changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|Remove empty rows faster in |Remove empty rows faster in |Calc (add in LO instead of |Calc (add in LO instead of |extension?) |extension) Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.
