[Libreoffice-ux-advise] [Bug 153722] Review needed of style groups "Chapter Styles" and "Text Styles"
https://bugs.documentfoundation.org/show_bug.cgi?id=153722 sdc.bla...@youmail.dk changed: What|Removed |Added Keywords||needsUXEval Blocks||114278 CC||libreoffice-ux-advise@lists ||.freedesktop.org Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=114278 [Bug 114278] [META] Style filter drop down list in Styles deck of Sidebar -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150164] PDF exporter's "Export outlines as named destinations" does not export outlines, but bookmarks
https://bugs.documentfoundation.org/show_bug.cgi?id=150164 sdc.bla...@youmail.dk changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #11 from sdc.bla...@youmail.dk --- (In reply to gabriel.crabbe from comment #9) > The phrasing "names of objects" is overly broad: only LibreOffice bookmarks > are exported (just tested with LibreOffice 7.5.0). This phrase appears in the following sentence in the help page [1]. "Enable the checkbox to export the names of objects in your document as valid bookmark targets." This raises the following question -- which I will ask to UXEval -- Is the intended behavior of this option: (a) to only export LO bookmarks, or (b) should "names of objects" be interpreted as referring to the "Name" property of images, tables, frames, and OLE objects, which could plausibly be exported as named destinations. If (a), then the needed corrections are being addressed here. If (b), then (maybe) a bug report must be filed. [1] https://help.libreoffice.org/7.6/en-US/text/shared/01/ref_pdf_export_links.html -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 105628] Creating a ToC with page numbering by chapter (see comment 4)
https://bugs.documentfoundation.org/show_bug.cgi?id=105628 --- Comment #19 from sdc.bla...@youmail.dk --- (In reply to sdc.blanco from comment #14) > There is an additional problem -- > there is a blank space between the Heading (Chapter No.) and the page > number. Bug 114773 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 139302] [UI] Demote Chapter in navigator
https://bugs.documentfoundation.org/show_bug.cgi?id=139302 sdc.bla...@youmail.dk changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||4493 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153527] LibreOffice 7.5 Calc: unable to apply formatting to all cells in spreadsheet
https://bugs.documentfoundation.org/show_bug.cgi?id=153527
--- Comment #11 from ady ---
(In reply to V Stuart Foote from comment #10)
> As to some edit engine cyclic application of the +A selection--seems
> overly complex, and you'd never be sure what you'd selected (you can't see
> the last cell selected).
FWIW, having "steps" for +A is what Excel already does (see bug 131916
comment 14 regarding [CTRL]+[A]). Such behavior does not contradict whichever
other decision about which action is applied to which ranges. In fact, by
imitating Excel in this regard the "mistake" of users applying some attribute
to the entire worksheet is reduced, while letting users _know_ that they are
applying it just to the selected area. IOW, it brings mostly pros, especially
in comparison to the current behavior.
Regarding not seeing the last cell, I don't understand why that is relevant in
any case. At any rate, users get "surprised" by the result. In some cases, it
is a welcome result, whereas in others, it might be an eventual "why is this
cell not formatted as I expected?".
I understand the performance issue. I happen to disagree that _forcing_
unexpected results on users is the best that can be done. When users complain
about unexpected results, they receive some explanation, or at least a hint,
and NAB. I think that allowing "steps" in +A behavior would reduce the
amount of "surprises". If then a user complains about performance when
selecting the entire worksheet (which would replace the other complains), the
response would also be about a UX decision, with a relevant comment about
workarounds ("modify the default cell style").
I am not a developer. My comments come from a user's POV only. It seems strange
to _silently force_ users (against the behavior they are used to and expect,
from prior experience), when there might be alternatives, especially when the
product is named _libre_ :p).
IDK whether having an option to "allow" applying attributes to an entire
worksheet is an adequate solution. I do know that having "steps" for +A
should be welcome (because, in comparison to the current status, it brings more
freedom and efficiency). Whichever the case, until users are _somehow_
"allowed" to see their actions applied to the selected range of cells (with
whichever pros and cons, as with anything), these types of bug reports will
keep showing up, simply because the behavior is unexpected by users,
independently of whichever logical and justified reasoning developers could
present.
Let me put it this way. Current answer: "You cannot do that, even when you
expected that result". Alternative answer: "You pressed +A three times in
order to select the entire worksheet and the reaction from Calc is not
absolutely immediate? Well, you have the choice to select only the relevant
areas of your worksheet, and work faster; or you could change the default cell
style; but if you anyway decide to select the entire worksheet with 10^6
columns (or whatever), please be patient".
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153712] "Chapter Info" should be named "Heading Info" (or "Heading") and "chapter entry" and its buddy dropdown box labels should be changed
https://bugs.documentfoundation.org/show_bug.cgi?id=153712 sdc.bla...@youmail.dk changed: What|Removed |Added Blocks||122497 Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=122497 [Bug 122497] [META] Table of Contents and Indexes dialog bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 105628] Creating a ToC with page numbering by chapter (see comment 4)
https://bugs.documentfoundation.org/show_bug.cgi?id=105628 --- Comment #18 from sdc.bla...@youmail.dk --- (In reply to @Timur from comment #13) > "Enter the maximum hierarchy level down to which objects are shown in the > generated index." Note "maximum hierarchy level down to which objects are shown" from the help page (which I believe is unchanged from 2004). if "objects"[1] is interpreted to mean "outline levels in the heading numbering", then the key phrase is "down to which" -- because the entered number is showing the maximum number of levels (from the top of the hierarchy) that are shown. In other words -- some circumstantial evidence that the help page is consistent with the hypothesis that the label should be: "Show up to outline level" > Or maybe that should be renamed, because it doesn't seem to do the same as > Evaluate up to level in Type tab. I agree. The "Type" tab evaluate is evaluating index levels. It would be good if Lee could write instructions for the Wiki, because this technique will only work if one outline level 1 heading is used in each chapter. The technique would not work in a document that uses more than one outline level 1 heading in a chapter. [1] I believe "objects" appear in help because the same text is used for the different kinds of indices (e.g., Tables, Illustrations). Fortunately there are separate help pages for these different kinds of indices, so it should be possible to use a more appropriate word for each kind of index. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 105628] Creating a ToC with page numbering by chapter (see comment 4)
https://bugs.documentfoundation.org/show_bug.cgi?id=105628 sdc.bla...@youmail.dk changed: What|Removed |Added Blocks||122497 Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||3561 --- Comment #17 from sdc.bla...@youmail.dk --- (In reply to Lee from comment #4) > There is a way to generate a Table of Contents (TOC) with page numbering by > chapter. I see now that I have re-invented this wheel. > Change the field "Evaluate up to level:" make the value a 1. > Since there is a way to create a TOC with page numbers by chapter, Right. Except for the new problem mentioned in comment 14 about the unwanted space. > it remains for someone with an understanding of the architecture to determine > if this is the intended solution. @Heiko? And more generally -- is the intended behavior accurately described by the word "Show" up to level" Because this ticket intersects with bug 153561, will drag UXEval into the picture. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=122497 [Bug 122497] [META] Table of Contents and Indexes dialog bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153561] Rename "Chapter -> Heading" and "E# -> H#" in Entries tab of Insert Table of Contents, Index, Bibliography dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153561 sdc.bla...@youmail.dk changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=10 ||5628 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153527] LibreOffice 7.5 Calc: unable to apply formatting to all cells in spreadsheet
https://bugs.documentfoundation.org/show_bug.cgi?id=153527 V Stuart Foote changed: What|Removed |Added Blocks||145509 --- Comment #10 from V Stuart Foote --- Pretty clearly the move to 16K columns necessitated this shift. Past practice of applying per cell attribute to a +A selection of the entire sheet instantly became non-performant with sheets of a billion cells. For acceptable performance the *reasonable* solution of ShrinkToDataArea() requires minor adjustment to work flows, acceptable UX. As noted, styling of sheet cells is the only way to efficiently apply formatting to entire sheets--not selecting all cells on a sheet and applying DF. This is not a bug, nor a regression, as implementing 16K columns necessitates retraining to keep sheet manipulations efficient. As to some edit engine cyclic application of the +A selection--seems overly complex, and you'd never be sure what you'd selected (you can't see the last cell selected). No, seems best to just accept that the +A selection will encompass only the sheets active cells as implemented for bug 147842 keeping the UX for Calc performant. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=145509 [Bug 145509] [META] Bugs Related to Liborcus -- You are receiving this mail because: You are on the CC list for the bug.
