[Libreoffice-ux-advise] [Bug 153740] In Writer, there should be 3 types of hyperlinks
https://bugs.documentfoundation.org/show_bug.cgi?id=153740 --- Comment #3 from Heiko Tietze --- Some ideas: We could use underline to identify three variants: without, single, double. Would be hard to understand, has no room for more differentiation and clashes with the customization. Splitting the Hyperlinks section of the Navigator sounds wrong. But what I could imagine nice design-wise and effective is an icon next to the entry that indicates what type it is. What do you think, TAB? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153986] Use of "numbering" instead of "bullets"/"bulleting" for bulleted list
https://bugs.documentfoundation.org/show_bug.cgi?id=153986 Heiko Tietze changed: What|Removed |Added CC||sdc.bla...@youmail.dk --- Comment #1 from Heiko Tietze --- IIRC, Seth had something similar recently. Put it on the pile of bug 153751? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153995] No UI for flipping the column order of a table
https://bugs.documentfoundation.org/show_bug.cgi?id=153995 Maxim Monastirsky changed: What|Removed |Added CC||momonas...@gmail.com --- Comment #3 from Maxim Monastirsky --- In Writer you can switch the direction of a table using the "Text Direction" property in the Table Properties dialog. By default this affects also the paragraph direction inside the table, but you can override this on the paragraph level either via a style or DF. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153986] Use of "numbering" instead of "bullets"/"bulleting" for bulleted list
https://bugs.documentfoundation.org/show_bug.cgi?id=153986 --- Comment #2 from sdc.bla...@youmail.dk --- (In reply to Heiko Tietze from comment #1) > IIRC, Seth had something similar recently. Nope. Not connected to heading/chapter/level etc. But I can see the issue identified in the OP. fwiw -- do not experience it as a troubling discrepancy. It is easy enough to understand "numbering" metaphorically. And focus on the key words "alignment" and "followed by". Is it easy for the dialog to know whether it is editing ordered or unordered lists (so that it could show the appropriate label)? That would seem necessary to satisfy the OP request. Otherwise, would probably need to find a generic label for "numbering" like "list identifier" or "List ID" or "List Symbol" where this "cure" might be worse than the "illness". -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153350] Allow user to change bibliography citation number structure
https://bugs.documentfoundation.org/show_bug.cgi?id=153350 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||page74010...@yahoo.fr, ||vermelhusco1...@gmail.com Ever confirmed|0 |1 --- Comment #6 from Heiko Tietze --- It seems to be a FAQ https://ask.libreoffice.org/t/writer-how-to-insert-bibliography-entry-showing-number/33081 where even the experts struggle with the answer. Currently we insert shortname entry from the bibliography database entry, eg. ARJ00. Alternatively one can switch to sequential numbers but very unfamiliar at the bibliography (aka ToC) insertion dialog. And this dialog allows to change the brackets. We need an extra dialog that allows ad-hoc and more fine-grained definitions. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153995] No ability for flipping the column order of a table
https://bugs.documentfoundation.org/show_bug.cgi?id=153995 Eyal Rozenberg changed: What|Removed |Added Summary|No UI for flipping the |No ability for flipping the |column order of a table |column order of a table --- Comment #4 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #2) > Have you ever seen such a UI? Well, I see it for paragraphs: A two-state button group... I'm being a little facetious of course, because table direction switching is needed much more rarely and does merit "toolbar real-estate". But let's start with having the functionality, e.g. as an UNO command which has a potential menu item / items, and maybe an off-toolbar pair of buttons. > Rather than some interface I'd want to use a > shortcut, something like ctrl+c and +v that not only inserts the > copied content but switches it. Would be hard to figure out, if not existent > anywhere else. I would not want to mix copying and switching, because what this would effectively mean is that you have to copy-switch then delete, which is a hassle, especially for large tables which fill an Impress slide etc. But - if the functionality existed and was only accessible via some keyboard shortcut - that would already be pretty good. So, changing the title to focus on the functionality rather than the UI -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151338] When selecting a cell or table row/column, "Position & Size" regards entire table
https://bugs.documentfoundation.org/show_bug.cgi?id=151338 Buovjaga changed: What|Removed |Added Keywords||needsUXEval CC||ilmari.lauhakangas@libreoff ||ice.org, ||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #3 from Buovjaga --- (In reply to Eyal Rozenberg from comment #0) > When I select a table cell, table row, table column, or select nothing and > have the cursor in a table cell, I expect "Position and Size" in the context > menu to refer to: The cell, the row, the column, and the cell respectively. > > Yet - in all these cases, they refer to the table's overall position and > size. I don't understand why it would refer to such table elements, when you can't change their position. I read the request as disabling the context menu entry for all situations except when the table object itself is selected. Why would you deprive me of the ability to open the Position and Size dialog freely? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153986] Use of "numbering" instead of "bullets"/"bulleting" for bulleted list
https://bugs.documentfoundation.org/show_bug.cgi?id=153986 --- Comment #3 from Eyal Rozenberg --- (In reply to sdc.blanco from comment #2) > fwiw -- do not experience it as a troubling discrepancy. > It is easy enough to understand "numbering" metaphorically. > And focus on the key words "alignment" and "followed by". So, I did mark this bug as "trivial", since it's not that bad. But I've seen people who get confused by it, and thus had trouble with instructions I gave them on how to manipulate their bulleted list. > Is it easy for the dialog to know whether it is editing > ordered or unordered lists (so that it could show the appropriate label)? I think so, because it shows, in the preview area, either bullets or numbers. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151338] When selecting a cell or table row/column, "Position & Size" regards entire table
https://bugs.documentfoundation.org/show_bug.cgi?id=151338 --- Comment #4 from Eyal Rozenberg --- (In reply to Buovjaga from comment #3) > I don't understand why it would refer to such table elements, when you can't > change their position. Well, because: 1. I can change their size. 2. The table is one level (or more) outwards, away, from the most specific thing I selected or am inside of. 3. Other items on the menu - "Character..." and "Paragraph..." regard the cell, column, or row - not the whole table. > I read the request as disabling the context menu > entry for all situations except when the table object itself is selected. That's not what I meant... Now, if you believe the table position and size should always be accessible on the context menu, anywhere in the table - I can live with that, but then I would expect two things: 1. Be explicit about it, i.e. "Table Position & Size", not "Position & Size" 2. Add a context menu item for changing the size of the row or column (and for a cell - either both row and column or none of them) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154003] It is too cumbersome to switch the direction of an entire presentation
https://bugs.documentfoundation.org/show_bug.cgi?id=154003 Eyal Rozenberg 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.
[Libreoffice-ux-advise] [Bug 154003] It is too cumbersome to switch the direction of an entire presentation
https://bugs.documentfoundation.org/show_bug.cgi?id=154003 Eyal Rozenberg changed: What|Removed |Added Blocks||43808 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=43808 [Bug 43808] [META] Right-To-Left and Complex Text Layout language issues (RTL/CTL) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154003] It is too cumbersome to switch the direction of an entire presentation
https://bugs.documentfoundation.org/show_bug.cgi?id=154003 Eyal Rozenberg changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||3995 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153995] No ability for flipping the column order of a table
https://bugs.documentfoundation.org/show_bug.cgi?id=153995 Eyal Rozenberg changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||4003 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153995] No ability for flipping the column order of a table
https://bugs.documentfoundation.org/show_bug.cgi?id=153995 --- Comment #5 from Heiko Tietze --- What comes in mind is the move column left/right function (resp. up/down for rows). Would be bug 99457 and bug 116948. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153995] No ability for flipping the column order of a table
https://bugs.documentfoundation.org/show_bug.cgi?id=153995 --- Comment #6 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #5) > What comes in mind is the move column left/right function (resp. up/down for > rows). Would be bug 99457 and bug 116948. So, those issues are somewhat related, but: 1. They're about Calc and Writer, respectively 2. If that were implemented in Impress, it would make the flipping less painful, but you would still need to make floor(N/2) column moves per table to make it happen, for an N-column table. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154003] It is too cumbersome to switch the direction of an entire presentation
https://bugs.documentfoundation.org/show_bug.cgi?id=154003 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Heiko Tietze --- What I can imagine to change automatically is * position of fields such as page number * text direction but I struggle with the artwork * left/right-handed images for decoration vs. functional purpose (thinking of a progress through the slides) * background images (simply mirroring is not going to fly) My take: create special RTL templates. And we have bug 145730 where you agreed with me, for once, at least partially :-). *** This bug has been marked as a duplicate of bug 145730 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153995] No ability for flipping the column order of a table
https://bugs.documentfoundation.org/show_bug.cgi?id=153995 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=99 ||457 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153995] No ability for flipping the column order of a table
https://bugs.documentfoundation.org/show_bug.cgi?id=153995 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=11 ||6948 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151338] When selecting a cell or table row/column, "Position & Size" regards entire table
https://bugs.documentfoundation.org/show_bug.cgi?id=151338 Heiko Tietze changed: What|Removed |Added CC||momonas...@gmail.com --- Comment #5 from Heiko Tietze --- Bug 153271 makes a precise input necessary, bug 142529 and bug 145204 about missing functionality (not confirming nor disconfirming). I wonder if Draw/Impress tables have a precise cell height/width at all or are defined by the content with some random initial value. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154003] It is too cumbersome to switch the direction of an entire presentation
https://bugs.documentfoundation.org/show_bug.cgi?id=154003 --- Comment #2 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #1) What about existing presentations, though? And what about templates which already exist? After all, most template creators will create LTR templates, not pairs of templates for RTL (Not to mention LRTB, RLTB etc.) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153986] Use of "numbering" instead of "bullets"/"bulleting" for bulleted list
https://bugs.documentfoundation.org/show_bug.cgi?id=153986 --- Comment #4 from Heiko Tietze --- How about dropping the "Numbering"? Bulleting would be as misleading as numbering for alphanumerical "numbers". If we stick to some word it needs to be changed on the customize tab as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153986] Use of "numbering" instead of "bullets"/"bulleting" for bulleted list
https://bugs.documentfoundation.org/show_bug.cgi?id=153986 --- Comment #5 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #4) > How about dropping the "Numbering"? So "alignment" and "followed by"? A bit too obscure, I'm afraid... > Bulleting would be as misleading as numbering for alphanumerical "numbers". I meant, use "bulleting" when it's a bulleted list, use "numbering" when it's a numbered list. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153971] Cannot direct-format paragraph, character when selecting (one or more) text boxes
https://bugs.documentfoundation.org/show_bug.cgi?id=153971 Heiko Tietze changed: What|Removed |Added CC||armin.le.gr...@me.com, ||mikekagan...@hotmail.com, ||momonas...@gmail.com --- Comment #1 from Heiko Tietze --- Speaking as a technical layman, if you select an object you don't know the content. Might be text but could be anything else too. Meaning you cannot apply text formatting neither to a single textbox or frame nor to multi-selection. And I believe the way to go is to make drawing styles available in Writer and Calc. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153952] Default template cannot be modified (by non-root user?)
https://bugs.documentfoundation.org/show_bug.cgi?id=153952 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=13 ||1529 Status|UNCONFIRMED |NEW Component|Writer |Installation Ever confirmed|0 |1 CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #3 from Heiko Tietze --- We install factory settings in the restricted area; same happening for Gallery content see bug 131529. Content that is typically editable needs to be installed in the user space. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153933] bg color for area fill of cell and dialog fields for negative find results against calc cells -- #ff6d6d is a bit harsh
https://bugs.documentfoundation.org/show_bug.cgi?id=153933 --- Comment #5 from Heiko Tietze --- In case of weld::EntryMessageType::Error the background becomes #ff6563, see vcl/source/app/salvtables.cxx set_message_type(). This red has not changed (neither it follows dark/light color schemes) and I don't get the "pink". Since we do not have a warning/error color from the OS this looks like a proper solution. Although some adjustments make sense, ie. the yellow color is over-saturated and should become #63. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153971] Cannot direct-format paragraph, character when selecting (one or more) text boxes
https://bugs.documentfoundation.org/show_bug.cgi?id=153971 --- Comment #2 from Maxim Monastirsky --- Note that DF commands are *not* grayed out in Impress/Draw in this case, and actually work. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153666] MASTER DOCUMENT: In navigator 'Insert -> File' should be 'Insert -> Text File' to be more precise
https://bugs.documentfoundation.org/show_bug.cgi?id=153666 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 CC||mikekagan...@hotmail.com, ||olivier.hallot@libreoffice. ||org --- Comment #3 from Heiko Tietze --- Why do you need a section in a master document? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153933] bg color for area fill of cell and dialog fields for negative find results against calc cells -- #ff6563 is a bit harsh
https://bugs.documentfoundation.org/show_bug.cgi?id=153933 V Stuart Foote changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED Ever confirmed|1 |0 Summary|bg color for area fill of |bg color for area fill of |cell and dialog fields for |cell and dialog fields for |negative find results |negative find results |against calc cells -- |against calc cells -- |#ff6d6d is a bit harsh |#ff6563 is a bit harsh --- Comment #6 from V Stuart Foote --- (In reply to Heiko Tietze from comment #5) > In case of weld::EntryMessageType::Error the background becomes #ff6563, see > vcl/source/app/salvtables.cxx set_message_type(). > > This red has not changed (neither it follows dark/light color schemes) and I > don't get the "pink". Since we do not have a warning/error color from the OS > this looks like a proper solution. > Thanks Heiko for finding that one off color ref (OOo from i75179) for the ERROR--could we adjust it from 0xff6563 to 0xff6d6d so picker can match a color on the Standard palette "Light Red 2"--but have to say it does trend "pink" . > Although some adjustments make sense, ie. the yellow color is over-saturated > and should become #63. I guess, for Warning the COL_YELLOW is a bit saturated. So, how about tweaking to ERROR -- 0xff3838 WARNING -- 0x38 which would correspond to the "Light Red 1" and "Light Yellow 1" of the standard palette? As long as there is no unit test conflict, that change would improve UI for both. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153995] No ability for flipping the column order of a table
https://bugs.documentfoundation.org/show_bug.cgi?id=153995 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #7 from Regina Henschel --- Tables in Draw/Impress are inside shapes and the edit engine for shape content is not able to interpret and render the style:writing-mode attribute of a table style. This cannot be simple solved by introducing an uno-command. It needs adding features to the shape text edit engine. The request belongs to the group of not implemented ODF features. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153971] Cannot direct-format paragraph, character when selecting (one or more) text boxes
https://bugs.documentfoundation.org/show_bug.cgi?id=153971 --- Comment #3 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #1) > Speaking as a technical layman, if you select an object you don't know the > content. I'm not sure what exactly you mean. Why do I need to "know the content" to set its style? > Might be text but could be anything else too. > Meaning you cannot > apply text formatting neither to a single textbox or frame nor to > multi-selection. We're talking about objects which all have text areas. If you were to make this argument about the case of objects which cannot have any text, that's a different story - although even then, I should be able to do some DF'ing, and have it apply to whichever selected objects it can apply to. > And I believe the way to go is to make drawing styles available in Writer > and Calc. That is not an alternative to allowing direct formatting, although that's important to do as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153933] bg color for area fill of cell and dialog fields for negative find results against calc cells -- #ff6563 is a bit harsh
https://bugs.documentfoundation.org/show_bug.cgi?id=153933 --- Comment #7 from Heiko Tietze --- Let's give it a try https://gerrit.libreoffice.org/c/core/+/148348 (not solving the OP's reported "pink" though) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153933] bg color for area fill of cell and dialog fields for negative find results against calc cells -- #ff6563 is a bit harsh
https://bugs.documentfoundation.org/show_bug.cgi?id=153933 V Stuart Foote changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154010] Show dragged object boundaries on ruler while dragging
https://bugs.documentfoundation.org/show_bug.cgi?id=154010 Eyal Rozenberg changed: What|Removed |Added CC||eyalr...@gmx.com, ||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154015] Mark selected object center on rulers
https://bugs.documentfoundation.org/show_bug.cgi?id=154015 Eyal Rozenberg 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.
[Libreoffice-ux-advise] [Bug 154010] Show dragged object boundaries on ruler while dragging
https://bugs.documentfoundation.org/show_bug.cgi?id=154010 V Stuart Foote changed: What|Removed |Added CC||vsfo...@libreoffice.org See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||4015 --- Comment #1 from V Stuart Foote --- Any reason the 'Helplines While Moving' is insufficient to task? Can already be exposed with grid and snap grid, and the guides extend to rulers (horizontal and vertical) when shown. The object guides do not affect the ruler layout until the Shape's text element has edit cursor focus. And the ruler will respond. Don't gain much for the effort to "show" object edges directly on the ruler. Likewise object center as requested for bug 154015 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154015] Mark selected object center on rulers
https://bugs.documentfoundation.org/show_bug.cgi?id=154015 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||4010 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154010] Show dragged object boundaries on ruler while dragging
https://bugs.documentfoundation.org/show_bug.cgi?id=154010 --- Comment #2 from Eyal Rozenberg --- (In reply to V Stuart Foote from comment #1) > Any reason the 'Helplines While Moving' is insufficient to task? Very often there are no relevant help-lines. > Can > already be exposed with grid and snap grid, and the guides extend to rulers > (horizontal and vertical) when shown. I'm not sure I follow this sentence. > The object guides do not affect the ruler layout until the Shape's text > element has edit cursor focus. And the ruler will respond. I'm not sure what you mean here also. How does this issue relate to editing? > Don't gain much for the effort to "show" object edges directly on the ruler. They are _already_ shown - except that only the original object boundaries/edges are shown. You gain about the same from showing the new boundaries as from showing the old boundaries. Which is letting the user consider the positions on each axis independently of the other axes. If Impress or Draw let you create rules by dragging from the rulers (do we have a bug for that feature?), then the benefit would be more limited, but we're not there. I find I'm missing this when positioning objects. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154024] Allow setting object size by percentage
https://bugs.documentfoundation.org/show_bug.cgi?id=154024 Eyal Rozenberg 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 154025] Allow centering object on page/slide via context menu
https://bugs.documentfoundation.org/show_bug.cgi?id=154025 Eyal Rozenberg changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org Blocks||108640, 100155 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=100155 [Bug 100155] [META] Improve object selection and alignment https://bugs.documentfoundation.org/show_bug.cgi?id=108640 [Bug 108640] [META] Object meta bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154026] Show small preview in Position & Size dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=154026 Eyal Rozenberg changed: What|Removed |Added Keywords||needsUXEval CC||eyalr...@gmx.com, ||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 154010] Show dragged object boundaries on ruler while dragging
https://bugs.documentfoundation.org/show_bug.cgi?id=154010 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #3 from Regina Henschel --- Created attachment 185802 --> https://bugs.documentfoundation.org/attachment.cgi?id=185802&action=edit Screenshot of helplines in Writer (In reply to Eyal Rozenberg from comment #0) > When dragging an object from its place and before it is placed in its final > position, we see its shape moving around with the mouse. However - we don't > see the projection of the moved shape on the ruler. Do you have enabled "Helplines While Moving"? (In reply to Eyal Rozenberg from comment #2) > (In reply to V Stuart Foote from comment #1) > > Any reason the 'Helplines While Moving' is insufficient to task? > > Very often there are no relevant help-lines. > Please specify the situations, where you do not get helplines. I do not have problems getting helplines. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153995] No ability for flipping the column order of a table
https://bugs.documentfoundation.org/show_bug.cgi?id=153995 --- Comment #8 from Eyal Rozenberg --- (In reply to Regina Henschel from comment #7) > Tables in Draw/Impress are inside shapes and the edit engine for shape > content is not able to interpret and render the style:writing-mode attribute > of a table style. This cannot be simple solved by introducing an > uno-command. It needs adding features to the shape text edit engine. While that is a possibility, it is not necessary for what I'm asking. I'm not asking (in this bug) for tables to have a persistent, recognizable direction - just that we automate the procedure of: Add new column N+1 Move column 1 to N+1 (+ set width) Move column N to 1 (+ set width) Move column N+1 to N (+ set width) Move column 2 to N+1 (+ set width) Move column N-1 to 2 (+ set width) Move column N+1 to N-1 (+ set width) ... Remove column N+1 > The request belongs to the group of not implemented ODF features. So, I believe that would be a separate request -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153995] No ability for flipping the column order of a table
https://bugs.documentfoundation.org/show_bug.cgi?id=153995 --- Comment #9 from Regina Henschel --- Automate such procedure could likely be done by a macro. -- You are receiving this mail because: You are on the CC list for the bug.
