Currently, all (?) fields are presented in Navigator directly under the Fields root, with the field code/name and arguments serialized into a string. For example: * Fields | + - * cross-reference - __RefHeading__Toc415784771 - יב + - * cross-reference - __RefHeading__Toc4157846681 - 2 and so on; see attachment. This is not useful. In this bug, I suggest one way of improving this state of affairs: Use the field type to form subtrees. Fields are already effectively grouped by field type because of how the serialization works, so why not save the repetitions and just make the field types into subtrees? Even without touching anything else, that would already allow the Navigator to fit more field info in, and be easier on the eyes.
Created attachment 179418 [details] A typical Navigator view of some fields
I think it is an advantage in documents with a lot of fields, but a disadvantage in documents with only five fields or less. cc: Design-Team cc: Jim Raykowski for further input and decision
(In reply to Dieter from comment #2) What about documents with only 5-or-less outlined paragraphs? Those are arranged in subtrees according to outline levels.
Wonder with what categories we end up. Number range, Date/Time, Page Number in case of my formatted dummy text (=> available at the extensions site). But in principle IO agree with more hierarchy for large trees. Could have been also an option for the Foot/Endnote thingy.
Created attachment 181161 [details] Screenshot That's what I get with Version: 7.3.4.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 8; OS: Linux 5.18; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 7.3.4-2 Calc: threaded Looks good to me, please check again.
(In reply to Heiko Tietze from comment #5) > Looks good to me, please check again. Your screenshot doesn't affect this bug that much. It still makes sense to have a subtree for cross-references, and within that for different types of references etc. - and the same for other kinds of fields. In your example there are few fields from every kind.
Created attachment 181172 [details] A document with some cross-references
(In reply to Eyal Rozenberg from comment #7) > Created attachment 181172 [details] > A document with some cross-references ...showing the category and object names. The _RefHeading_* labels show proper names now. WFM?
(In reply to Heiko Tietze from comment #8) > (In reply to Eyal Rozenberg from comment #7) > > Created attachment 181172 [details] > > A document with some cross-references > > ...showing the category and object names. The _RefHeading_* labels show > proper names now. WFM? Well, though the problem is less significant now, it would still be useful to create a subtree per field category, and the items in the subtree will just have the names, not also the category.
(In reply to Heiko Tietze from comment #8) > (In reply to Eyal Rozenberg from comment #7) > > Created attachment 181172 [details] > > A document with some cross-references > > ...showing the category and object names. The _RefHeading_* labels show > proper names now. WFM? Oh, wait, actually, no. I still see the RefHeadings. So, let's split that off into a different bug.
Okay, let's use sub-categories for fields. About the second issue, I don't get the _refheading_. Good for another ticket if you have clear STR.
(In reply to Heiko Tietze from comment #11) > About the second issue, I don't get the _refheading_. Good for another > ticket if you have clear STR. Done, bug 149916.
Dear Eyal Rozenberg, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
It's still the case that the field type gets concatenated to the specific field name for the Navigator entry, rather than us getting a subtree. Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US