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.