This is a follow up from discussions on the design mailing list (http://nabble.documentfoundation.org/About-the-Navigator-tp2701544p2701544.html)
LibO adds a “Tree view” for the Navigator. The tree view gives immediate feedback about the document structure... But this tree view also adds some usability issues.
For example, consider the case in which you have, say, four levels of headings and you are now on a level three (a sub-subsection). Now, you want to go for a moment to the top level for this part (the Chapter) and as consequence you double click on the corresponding entry on the navigator. You will be “teleported” there immediately, which is OK... but at the same time the tree view for that entry will collapse, hiding the sublevels and forcing you to reopen them one by one to return to the original position, which is bad. On this common user case the tree-view becomes counter productive.
A good change could be to modify the tree view behaviour in order to separate the opening/closing of each level from the “jump to” feature. For example:
- Click (on the Navigator text entry) → Select
- Double–Click (on the Navigator text entry) → Jump
- Something else to open/close the corresponding entry on the tree view.
An option to open all branches at once is highly desirable too.
Also, the tree view should remember its status between sessions, keeping opened the branches that were opened by the user.
NOTE: even if this request ask for different items, all of them affect only one feature (the tree-view) and for that reason I filled them on only one issue.
(In reply to comment #0)
> - Something else to open/close the corresponding entry on the tree view.
This is / should be possible with the expand/collapse controls (small triangles, or plus/minus-signs - according platform).
> An option to open all branches at once is highly desirable too.
The "Show heading levels" dropdown "filter" should be converted into
a command list. So if the user sets "5", then all the headings until
level 5 should be expanded. All further levels will still be expandable
by the user. If the user sets "1", then all headings are collapsed but
the main headings. Still, the user may expand them manually - there is
no hidden pre-filtering.
Something related to this bug:
If you have a document with "same-looking headings", you can't immediately click something on the third level to select it, no matter how many times you click it. You will need to click the parent heading first, then the subheading.
You ask, "why create two same-looking headings? Aren't headings supposed to be unique?" Yes. But in my project I have Heading1:"Collection header". Heading2:"Book header"(Repeats among collections) and heading3: chapter number (repeats in every single book).
I'll try and upload an extreme case example, try navigating around using the navigator, and close/open with the triangle/arrow icons, feel the frustration.
OK I see my case is a bit strange, but it could be fixed sometime :D
Created attachment 45996 [details]
lots of same-looking headings at the same level messes up navigator tree view
The attached document is an extreme case.
The bug is "fixed" by making sure all headings on a specific level are unique document-wide.
(In reply to comment #2)
> OK I see my case is a bit strange, but it could be fixed sometime :D
You say it :-)
Would be good if you create a separate bug for that enhancement, IMHO.
(In reply to comment #1)
> (In reply to comment #0)
> > An option to open all branches at once is highly desirable too.
> The "Show heading levels" dropdown "filter" should be converted into
> a command list. So if the user sets "5", then all the headings until
> level 5 should be expanded. All further levels will still be expandable
> by the user. If the user sets "1", then all headings are collapsed but
> the main headings. Still, the user may expand them manually - there is
> no hidden pre-filtering.
What I would suggest: cltr-Arrow to open/close all the nodes of a lower level
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
The feature requested is not implemented on 3.5 beta2.
Being able to set LO Writer to display all headings in the Navigator as a remembered setting is crucial for me to be able to use the program. For me the importance is "highest", but I just upped it to "high". :-) Since this is a regression from OOo, I also changed this from "enhancement" to "normal". I updated version and platform.
I'm not a programmer, but am happy to help in other ways--testing, documentation, etc.
** Please read this message in its entirety before responding **
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 on a currently supported version of LibreOffice (4.4.3 or later)
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
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)
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: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2015-06-08
still not changed