[Libreoffice-ux-advise] [Bug 148417] Change "X" icon in Print Preview to "X Close Preview" (like in Writer)
https://bugs.documentfoundation.org/show_bug.cgi?id=148417 --- Comment #2 from sdc.bla...@youmail.dk --- Polite ping to check if this ticket should be registered as an EasyHack. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148417] Change "X" icon in Print Preview to "X Close Preview" (like in Writer)
https://bugs.documentfoundation.org/show_bug.cgi?id=148417 sdc.bla...@youmail.dk 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 148513] Poor nomenclature for Manual Break
https://bugs.documentfoundation.org/show_bug.cgi?id=148513 --- Comment #14 from sdc.bla...@youmail.dk --- Type o Line Break Position of next line in paragraph: Next line After all objects After all objects to right of cursor After all objects to left of cursor --- >From reading BZ entries, one learns that (some? many?) Eve users want the UI to be "intuitive" or "self-explaining" -- without having to read the help. Here is a proposal that might satisfy Eve users and maybe not too bad for Benjamin. And I believe it would be easier to write accurate "help" pages in relation to these options. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148519] Change "Margin" to "Entire Frame" in "to" field for Vertical Position when anchoring "To frame" in Position and Shape tab
https://bugs.documentfoundation.org/show_bug.cgi?id=148519 --- Comment #1 from sdc.bla...@youmail.dk --- Revised suggestion. (for Type tab - Image): Entire frame --> Frame border (for Position and Size tab - Shape): Margin -> Frame border Reasons: 1. "Frame border" may be the "standard" terminology. 2. Border tab exists in Frame, so some users will know about Frame border. 3. The Horizontal Position "to" field has "Left frame border" and "Right frame border". (best reason) because gives internal consistency to the dialogs, and makes it easier to recognize likely meaning of "frame border" vs. "frame text area". -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 141625] Calc Chart x-Axis Formatting
https://bugs.documentfoundation.org/show_bug.cgi?id=141625 Caolán McNamara changed: What|Removed |Added Keywords|needsUXEval | Version|6.4.6.2 release |Inherited From OOo Assignee|libreoffice-b...@lists.free |caol...@redhat.com |desktop.org | Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148568] Rework the Sparklines dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=148568 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added Keywords||needsUXEval Severity|normal |enhancement 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 148513] Poor nomenclature for Manual Break
https://bugs.documentfoundation.org/show_bug.cgi?id=148513 --- Comment #13 from sdc.bla...@youmail.dk --- Created attachment 179527 --> https://bugs.documentfoundation.org/attachment.cgi?id=179527=edit test file to experiment with Left and Right Have attached a test file (a paragraph with four shapes) that can be used for testing. How to play the game. Place your cursor ANYWHERE in the paragraph. Use line break, with LEFT or RIGHT. Before clicking OK, predict what will happen. Meanwhile ... started to think about what labels to use for "Left" and "Right". If my rules are correct then the Restart position is: Left = After all objects to left of cursor position Right = After all objects to right of cursor position Would the following be minimally acceptable in the dropdown box? Left objects Right objects In the context of the dialog box, you have chosen "Line break" and then click in the "Restart position" dropdown box. The "cue" of "Left objects" is to remind/highlight: Objects to the left of the cursor position. The assumption is that after you have read the excellent help page and understand how it works (or now I have more or less written possible extended tooltips), then (a) you place your cursor in the paragraph where you want the break, and (b) choose "Left objects", which reminds you -- all objects to the left of the cursor. Left/Right alone seems too minimal, because it does not remind that left/right is about "objects in relation to cursor" I guess that is my opinion for now. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148513] Poor nomenclature for Manual Break
https://bugs.documentfoundation.org/show_bug.cgi?id=148513 --- Comment #12 from Miklos Vajna --- This sounds correct. This is meant to work with any kind of fly frames, so anything other than as-char should work. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148513] Poor nomenclature for Manual Break
https://bugs.documentfoundation.org/show_bug.cgi?id=148513 --- Comment #11 from sdc.bla...@youmail.dk --- @Miklos -- I was hoping you would tell me something like the following: Left = Start next full line after ALL objects (anchored to paragraph) that have some part horizontally to the left of current cursor position. (If no parts of objects are left of the cursor position, then break to next line). Right = Start next full line after ALL objects (anchored to paragraph) that have some part horizontally to the right of current cursor position. (If no parts of objects are right of the cursor position, then break to next line). Does that give a complete and accurate description of the expected behavior? (only tested with anchor "to paragraph" Do these rules also apply with ”to character” anchors?) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148513] Poor nomenclature for Manual Break
https://bugs.documentfoundation.org/show_bug.cgi?id=148513 --- Comment #10 from Miklos Vajna --- > 3. Are Left and Right really needed? See the URL of this bug, I created screenshots to show how the left/right/all cases differ when you have multiple images intersecting with a line of text. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148513] Poor nomenclature for Manual Break
https://bugs.documentfoundation.org/show_bug.cgi?id=148513 --- Comment #9 from sdc.bla...@youmail.dk --- (In reply to Heiko Tietze from comment #8) > How about: > "Restart location" How about: Restart position - because command is used to position text in relation to objects > "[None]" -> "Next line" Concur. Also in OP > "Right" -> keep; > "Left" -> keep Undecided. Diverges from OP. See question 3 below. > "Next full line" Concur. Also in OP. Observations and questions. 1. In a "normal" text paragraph, all 4 options give exactly the same result. (correct?) => Help page should indicate that "Line break" "Next line" is sufficient for introducing a line break in a text-only paragraph. 2. => Help should emphasize that the other options are only relevant when positioning text in relate to embedded objects. 3. Are Left and Right really needed? Place a shape or frame in the middle of a text. Place cursor in text to right of shape. LB - "Next line" and LB - "Right" give same result. LB - "Next full line" and LB - "Left" give same result. I also tried two shapes (next to each other, with cursor in between) and with cursor after the two shapes. Miklos' blog gives impression that Left and Right might be useful when there are shapes on the right side of the canvas? So far it seems like everything that can be done with Left and Right, can also be done with Next Line (none) and Next Full Line. What am I missing (in my first encounter with LB, Left, Right, etc.)? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148523] Table properties changes only a cell in Impress (full table expected)
https://bugs.documentfoundation.org/show_bug.cgi?id=148523 Heiko Tietze changed: What|Removed |Added Severity|normal |enhancement Blocks||100366 CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #4 from Heiko Tietze --- So let's make Draw/Impress smart as well and apply an attribute to all unformatted cells in the table in case of no cell selection. 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 148523] Table properties changes only a cell in Impress (full table expected)
https://bugs.documentfoundation.org/show_bug.cgi?id=148523 --- Comment #3 from Mike Kaganski --- I can see a value in making these unified; having similar behavior for similar functionality is definitely good when it doesn't hurt. In Writer, the "apply to selection" only works when cells are *selected*; otherwise, it applies to the whole table. I would think that there would be little problem using the same paradigm in any other module - it doesn't limit your possibilities. Unless there is a pressing *huge* benefit of keeping current behavior, I suggest to unify it (to make other modules follow Writer, not the other way round, because Writer is most used). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148513] Poor nomenclature for Manual Break
https://bugs.documentfoundation.org/show_bug.cgi?id=148513 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||sdc.bla...@youmail.dk Ever confirmed|0 |1 --- Comment #8 from Heiko Tietze --- How about: "Restart location" - keep it; short and precise "[None]" -> "Next line"; much better than [None] and sounds familiar to the common LB "Right" -> keep; short and precise enough with the title caption "Left" -> keep "Next full line" -> keep; short and makes the difference to "Next Line" clear Seth, what do you think? Code pointer: sw/uiconfig/swriter/ui/insertbreak.ui -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148523] Table properties changes only a cell in Impress (full table expected)
https://bugs.documentfoundation.org/show_bug.cgi?id=148523 Heiko Tietze changed: What|Removed |Added CC||mikekagan...@hotmail.com --- Comment #2 from Heiko Tietze --- Definitely not a bug. Writer tries to be smart and applies the formatting, border and background, to the unformatted cells. Draw/Impress just apply to the selected cell(s). It could be interpreted as a feature because Draw/Impress are more likely used for small-scale graphical changes while Writer is supposed to have a homogeneous look and feel. There is also bug 101802 talking about harmonization but there in respect to the table style feature at the sidebar. Mike, what's your take? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148513] Poor nomenclature for Manual Break
https://bugs.documentfoundation.org/show_bug.cgi?id=148513 --- Comment #7 from Miklos Vajna --- MSO only has UI to insert the clear=all case. The ribbon has a Layout tab, which has a Page Setup group, part of that is a Breaks dropdown. Inside that, there is a Page Breaks section, and one item there is Text Wrapping. (If you find it confusing that they present a line break inside a page break section, you're not alone.) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148513] Poor nomenclature for Manual Break
https://bugs.documentfoundation.org/show_bug.cgi?id=148513 --- Comment #6 from Heiko Tietze --- (In reply to Olivier Hallot from comment #0) > "Restart location" -> "New line restart location" > "[None]" -> "Next line" > "Right" -> Next clear line on right > "Left" -> Next clear line on left > "Next full line" -> "Next Full Line" Since the feature was implemented mainly for compatibility reasons we should care about at least similar wording. What I found is [1] with the same nomenclature as used now, [2] is not really informative. So how is it implemented/named in MSO? [1] http://officeopenxml.com/WPtextSpecialContent-break.php [2] https://www.officetooltips.com/word_365/tips/line_breaks_in_a_word_document.html -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 71991] FORMATTING: arrow end default sizes incoherent with "Synchronize end" checked by default
https://bugs.documentfoundation.org/show_bug.cgi?id=71991 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||hoss...@libreoffice.org Keywords|needsUXEval | --- Comment #8 from Heiko Tietze --- Some issues here: 1) the "Synchronize Ends" checkbox is misleading - a lock icon between the two controls would be better; or we disable one of the controls if synchronize is checked 2) checking synchronize has no immediate effect on the two endings, meaning 0.2 / 0.3 are still different unless one is changed - this might be solved by #1 3) setting an arrow via sidebar ends up with a different size - since synchronize is not active by default this is not wrong but inconvenient; we should use 0.3 cm by default In a nutshell: move the checkbox between the controls and make it a toggle icon, adjust the values when synchronize is checked, and change the default at the sidebar. Code pointers: cui/uiconfig/ui/linetabpage.ui and cui/source/tabpages/tpline.cxx for the dialog; the sidebar is a bit tricky to find, I'd start at .uno:LineEndStyle (called by the sidebar control) pointing to SID_ATTR_LINEEND_STYLE which might be related to SID_ATTRIBUTES_LINE.. but at this point I stopped digging the code. Maybe Hossein finds the place where these 0.2cm are defined. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 140900] [Feature Request] A setting to change the size of the font previews dropdown
https://bugs.documentfoundation.org/show_bug.cgi?id=140900 --- Comment #17 from chameleonsca...@protonmail.com --- Yes, that's the preview I was talking about in the following sentences. But selecting text in a page and changing the font does the same thing, apart from that updating issue with up and down arrows I mentionned. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148519] Change "Margin" to "Entire Frame" in "to" field for Vertical Position when anchoring "To frame" in Position and Shape tab
https://bugs.documentfoundation.org/show_bug.cgi?id=148519 sdc.bla...@youmail.dk changed: What|Removed |Added Blocks||148485 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=148485 [Bug 148485] four options missing in "Position > Vertical > to" section for Position and Size tab for Shape -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 140900] [Feature Request] A setting to change the size of the font previews dropdown
https://bugs.documentfoundation.org/show_bug.cgi?id=140900 --- Comment #16 from Heiko Tietze --- Created attachment 179507 --> https://bugs.documentfoundation.org/attachment.cgi?id=179507=edit Character properties (In reply to chameleonscales from comment #15) > Not sure how... This preview -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 140900] [Feature Request] A setting to change the size of the font previews dropdown
https://bugs.documentfoundation.org/show_bug.cgi?id=140900 --- Comment #15 from chameleonsca...@protonmail.com --- (In reply to Heiko Tietze from comment #14) > Maybe the preview of the character properties dialog helps here. Not sure how, although this made me notice that, while the character properties dropdown updates the preview as you arrow up and down, the one in the main window doesn't update the selected text as you do the same. You have to hit enter but then the focus gets out of the selector widget, so you have to use your mouse again. Maybe that's what you were referring to and maybe that's another issue to address for the main window. > Project made a dev decision to hand over widget controls to the os/DE, > stripping out ability to scale some selection of "individual" widget elements. As I understand it, the blocking point is mainly that the toolbox can/should only use regular widgets (e.g. a Combobox as GTK calls it), which I understand. In that case, since other places in the UI have non-regular widgets/viewports, e.g. the font preview in the Characters properties, maybe we could have a font list with large previews there? The main idea of this issue is to not have to see each font one by one but being able to see many fonts at once in all their glory. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 86297] Wrong Field reference when heading is in a frame
https://bugs.documentfoundation.org/show_bug.cgi?id=86297 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||mikekagan...@hotmail.com, ||rayk...@gmail.com Keywords|needsUXEval | --- Comment #10 from Heiko Tietze --- Cannot wrap my mind around a frame with heading moved to some other position- neither to have it in the header/footer area. Why the heck would you do that? If the chapter needs to be present in the header a reference is the way to go. So my first idea is to block outlines in special sections. But I see no clear way to do so as it requires to block applying a style linked to an outline - but no other style. In respect to the sorting order at the Navigator we do wrong in either way. We show in the Navigator somehow what you see in the document. Somehow since "Chapter 1.1" comes before framed "Chapter One", which then contains 1.1.1 ff. Btw, use Tools > Chapter Numbering to get the true level. Maike, Jim, what do you think? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148465] Rework Sparklines's context menus
https://bugs.documentfoundation.org/show_bug.cgi?id=148465 andreas_k changed: What|Removed |Added CC||kain...@gmail.com --- Comment #2 from andreas_k --- when the sparkline commands are context related commands, can it have a context related notebookbar tab (like MSO)? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 140900] [Feature Request] A setting to change the size of the font previews dropdown
https://bugs.documentfoundation.org/show_bug.cgi?id=140900 --- Comment #14 from Heiko Tietze --- (In reply to chameleonscales from comment #12) > ...resizeable previews which can get much larger than LO's dropdown (see > attachment). Thought you complain about the text itself (expanded widget) or the dropdown when collapsed in case of very long font names in mind. But your point is to have a larger font size in the preview, which is better for special fonts like this PaintyPaint. I concur with Stuart's duplication verdict that points to the general solution of a UI scaling. A larger font size comes on cost of readability and the average use case is to pick one (sans / serif) font from the list. But admittedly there are cases when the fancy stuff is used. Maybe the preview of the character properties dialog helps here. -- You are receiving this mail because: You are on the CC list for the bug.
