[Libreoffice-ux-advise] [Bug 150477] "Slide 1 of 1" instead of "Page" in the bottom bar of Draw
https://bugs.documentfoundation.org/show_bug.cgi?id=150477 Timur changed: What|Removed |Added Summary|"Slide 1 of 1" in the |"Slide 1 of 1" instead of |bottom bar |"Page" in the bottom bar ||of Draw -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150477] "Slide 1 of 1" in the bottom bar
https://bugs.documentfoundation.org/show_bug.cgi?id=150477 Timur changed: What|Removed |Added Priority|medium |low Severity|normal |trivial -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150477] "Slide 1 of 1" in the bottom bar
https://bugs.documentfoundation.org/show_bug.cgi?id=150477 --- Comment #8 from robomurphy98 --- Yes, both in the menu and in the panel are changed but in the bottom bar it still says "Slide 1 of 1" -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150477] "Slide 1 of 1" in the bottom bar
https://bugs.documentfoundation.org/show_bug.cgi?id=150477 Julien Nabet changed: What|Removed |Added OS|Windows (All) |All -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150477] "Slide 1 of 1" in the bottom bar
https://bugs.documentfoundation.org/show_bug.cgi?id=150477 Julien Nabet changed: What|Removed |Added CC||heiko.tietze@documentfounda ||tion.org --- Comment #7 from Julien Nabet --- (In reply to robomurphy98 from comment #5) > In Impress slide is used ok, but in Draw they are pages not slides so it > makes no sense to put it there Ok I understand better, in Impress you got a menu "Slide" then for example "New Slide" whereas in Draw, there's a Page menu with "New Page" for example. So indeed, we may expect "Page 1 of 1" in Draw specifically (compared to Impress). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150477] "Slide 1 of 1" in the bottom bar
https://bugs.documentfoundation.org/show_bug.cgi?id=150477 --- Comment #6 from robomurphy98 --- LibreOffice Draw manages pages such diagrams etc but Impress other type (slides) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150477] "Slide 1 of 1" in the bottom bar
https://bugs.documentfoundation.org/show_bug.cgi?id=150477 --- Comment #4 from Julien Nabet --- (In reply to robomurphy98 from comment #3) > Yes but in the spanish version of LibreOffice, in LO Draw, I see > "Diapositiva 1 de 1" "Diapositiva" is the Spanish translation of "Slide" so we can expect this word in Draw or Impress when using Spanish language. For Writer, you'll find "Página" so the Spanish translation of "Page". I still don't see the pb here. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150477] "Slide 1 of 1" in the bottom bar
https://bugs.documentfoundation.org/show_bug.cgi?id=150477 --- Comment #3 from robomurphy98 --- Yes but in the spanish version of LibreOffice, in LO Draw, I see "Diapositiva 1 de 1" -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150477] "Slide 1 of 1" in the bottom bar
https://bugs.documentfoundation.org/show_bug.cgi?id=150477 Julien Nabet changed: What|Removed |Added CC||serval2...@yahoo.fr --- Comment #2 from Julien Nabet --- I don't see the pb here: - for a presentation software, I expect "Slide" - for a word processing software, I expect "Page" -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150477] "Slide 1 of 1" in the bottom bar
https://bugs.documentfoundation.org/show_bug.cgi?id=150477 --- Comment #1 from robomurphy98 --- Created attachment 181868 --> https://bugs.documentfoundation.org/attachment.cgi?id=181868=edit Attachment of the bottom bar Screenshot of the bug -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150477] "Slide 1 of 1" in the bottom bar
https://bugs.documentfoundation.org/show_bug.cgi?id=150477 Xisco Faulí changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||xiscofa...@libreoffice.org Keywords||needsUXEval -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150466] Hide Print File Directly by default in the tabbed and tabbed compact user interfaces
https://bugs.documentfoundation.org/show_bug.cgi?id=150466 V Stuart Foote changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vstuart.fo...@utsa.edu --- Comment #1 from V Stuart Foote --- reasonable, +1 And once hidden, for users who understand the action, the button can be added back via MUFFIN NB customization. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150461] Allow deselecting tables in View->Tables
https://bugs.documentfoundation.org/show_bug.cgi?id=150461 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | Status|NEEDINFO|NEW CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #9 from Heiko Tietze --- No objection to unselect on click at the white space if we keep the multi-selection. Still wonder if that's a requirement. But anyway. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150461] Allow deselecting tables in View->Tables
https://bugs.documentfoundation.org/show_bug.cgi?id=150461 --- Comment #8 from Mike Kaganski --- (In reply to Heiko Tietze from comment #7) > (In reply to Mike Kaganski from comment #5) > > Uh??? When you have an object selected, it is *very* common to select > > outside to deselect it (without selecting anything else). > > True for drawing objects but not lists. You don't need to click the word to > select an entry. Even MS file explorer keeps the list item active when > clicking white space. This is playing words. In Windows Explorer, when you click outside of files, the *selection* is cleared, and the context changes (see the context menus there). They keep the focus frame to hint from where navigation would start if user uses arrow keys, but not to keep user guessing if something is selected or not. > But the better example of what I mean is the left > folders pane. Totally wrong. The left Pane defines location context, and you can't be outside of any location at any time in Explorer's world. And the correct analogy in our case is View->Tables, which defines our location. We can't be outside of any such location, too. But the selected object is what defines on what the user will perform actions. And for any location where there are objects, and you might add more, everything unelected is a common context, familiar to everyone. I am actually puzzled how *that* could be controversial. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150461] Allow deselecting tables in View->Tables
https://bugs.documentfoundation.org/show_bug.cgi?id=150461 --- Comment #7 from Heiko Tietze --- (In reply to Mike Kaganski from comment #5) > Uh??? When you have an object selected, it is *very* common to select > outside to deselect it (without selecting anything else). True for drawing objects but not lists. You don't need to click the word to select an entry. Even MS file explorer keeps the list item active when clicking white space. But the better example of what I mean is the left folders pane. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150461] Allow deselecting tables in View->Tables
https://bugs.documentfoundation.org/show_bug.cgi?id=150461 --- Comment #6 from Mike Kaganski --- (In reply to Mike Kaganski from comment #5) > it is *very* common to select outside to deselect it Sorry, a typo: "to click outside" was meant. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150461] Allow deselecting tables in View->Tables
https://bugs.documentfoundation.org/show_bug.cgi?id=150461 --- Comment #5 from Mike Kaganski --- (In reply to Heiko Tietze from comment #4) > Well if we remove "Select All" the suggested "Unselect All" makes no sense ??? No one proposed a new menu entry at all! The idea is to click outside of tables (in an empty space), and have selection cleared. > (and it's a very uncommon interaction anyway). Uh??? When you have an object selected, it is *very* common to select outside to deselect it (without selecting anything else). Think objects in Draw, or files in your favorite graphical file manager (most of them currently, I don't count Midnight Commander-like ones). > What is the multi-selection good for anyway? Besides being able to delete > all tables at once, which is rarely a necessity. This is off-topic here - for the reason outlined above. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150461] Allow deselecting tables in View->Tables
https://bugs.documentfoundation.org/show_bug.cgi?id=150461 --- Comment #4 from Heiko Tietze --- (In reply to Mike Kaganski from comment #3) > > The point of Select All is not clear to me. > > This is off-topic here ;) Well if we remove "Select All" the suggested "Unselect All" makes no sense (and it's a very uncommon interaction anyway). What is the multi-selection good for anyway? Besides being able to delete all tables at once, which is rarely a necessity. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150461] Allow deselecting tables in View->Tables
https://bugs.documentfoundation.org/show_bug.cgi?id=150461 --- Comment #3 from Mike Kaganski --- (In reply to Heiko Tietze from comment #2) > We could either auto select the first table or show all entries but disabled. Does this mean that we can *only* discuss these two options? IMO, the status quo (when the non-selected context menu is small and does not include disabled commands) is just fine, the only problem is to enable getting into "nothing selected" state after selection. > The point of Select All is not clear to me. This is off-topic here ;) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150461] Allow deselecting tables in View->Tables
https://bugs.documentfoundation.org/show_bug.cgi?id=150461 Heiko Tietze changed: What|Removed |Added Status|NEW |NEEDINFO CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #2 from Heiko Tietze --- We could either auto select the first table or show all entries but disabled. The point of Select All is not clear to me. Would expect ctrl/shift+click and/or ctrl+A to do the trick. So rather adding another unnecessary command to the menu we could clean it up. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150260] Last row/column does not remain hidden when deleting row(s)/column(s)
https://bugs.documentfoundation.org/show_bug.cgi?id=150260 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Summary|Last row does not remain|Last row/column does not |hidden when deleting row(s) |remain hidden when deleting ||row(s)/column(s) --- Comment #9 from Heiko Tietze --- We discussed the topic in the design meeting. While rows are "added" in MSO, it does not happen for columns - "deleting" a column reduces the total number (actually the number remain but with zero width). We "add" rows and columns if one is deleted. So the recommendation is to keep "added" rows and columns hidden if the last row/column is not visible. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150244] TABLES: Command "Distribute columns evenly" doesn't work for a single row
https://bugs.documentfoundation.org/show_bug.cgi?id=150244 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Heiko Tietze --- We discussed the topic in the design meeting and agreed that the action should respect the selection. The concerns raised in comment 3 in respect to the idea having an automatic redistribution flag on the whole table is irrelevant. The request is questionable itself (running the one-shot action again is cheap) and could be realized additionally as it covers another use case (if the action is execute the flag could be disabled). We should also consider the alt+left/right function that allows easy resizing of columns. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150276] Paragraph mark in rotated-character paragraph placed in middle of text
https://bugs.documentfoundation.org/show_bug.cgi?id=150276 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #18 from Heiko Tietze --- We discussed this topic in the design meeting with different opinions. First, we can follow the MSO approach and show the pilcrow/downward arrow for paragraph/line breaks next to the rotated word. MSO takes the word after a line break into the next line while we show it right (or left) of it. Aligning the behavior would solve the problems raised in comment 17. The alternative idea is to rotate the break symbol and show it at the end of the current line. It potentially overlaps previous characters (either on top or left/right of it), but unlike today the text should be drawn on top of the symbol (z-oder-wise). Last but not least, due to many pros and cons the request could be resolved as WF. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150375] Render non-printing line numbers with faint gray
https://bugs.documentfoundation.org/show_bug.cgi?id=150375 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||hoss...@libreoffice.org Keywords|needsUXEval |needsDevAdvice Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Depends on||150237 See Also|https://bugs.documentfounda | |tion.org/show_bug.cgi?id=15 | |0237| --- Comment #5 from Heiko Tietze --- We discussed this topic in the design meeting as a potential solution for bug 150237. Starting with a text would show no line number unless line 5. But since the dialog runs manually users should be aware of what they do (line numbering can be set in templates too, however). One use case for line numbers is minutes where seeing all numbers is relevant (so having an info in the status bar is not a sufficient solution). The "faint gray numbers" could be drawn similar to line numbers using the same algorithm. When it comes to print preview and print it would be suppressed. True line numbers could overwrite the grey "virtual line numbers". The function could therefore be implemented as a view option, if the effort is acceptable. It might also be an easy hack. Alternatively we could change the dialogs default to 1. => needsDevAdvice Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=150237 [Bug 150237] LINE NUMBERING DIALOG: Change interval to 1 by default -- You are receiving this mail because: You are on the CC list for the bug.
