Bug 43514 - UI: Need an easy way to get from current position in a document to the corresponding position in the Navigatior dialog's header tree
Summary: UI: Need an easy way to get from current position in a document to the corres...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.3 release
Hardware: All All
: medium enhancement
Assignee: Rohan Kumar
URL:
Whiteboard: ToBeReviewed target:5.2.0
Keywords: difficultyBeginner, easyHack, skillCpp
Depends on:
Blocks:
 
Reported: 2011-12-04 06:49 UTC by hindmost
Modified: 2017-02-14 08:57 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
test document containing a variety of navigator items (32.26 KB, application/vnd.oasis.opendocument.text)
2016-02-11 14:16 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description hindmost 2011-12-04 06:49:59 UTC
Problem description: Documents can be large and complex.  The Navigator's Header tree is a handy way to find your place in a document as you need only drill down the header tree to the branch of interest and double click.
Unfortunately doing the opposite is not supported.
A way to easily go from the document to the corresponding location in the header tree is not available.

Steps to reproduce:
1. Open a document, a specification for instance, with several levels of headers.
2. Move down the document many paragraphs.
3. Wish you knew if the text you just read is part of the spec's Overview, or Background, or Detail Requirements, ie. which sub-sub-sub paragraph the text is a part of.  The header tree in the Navigator would show you if there was a handy way to pop the Navigator open to the tree branch corresponding to the current location in the document.

Current behavior:  Moving around the document has no effect on the location shown on the Navigator's Heading tree.  Pressing f5 always opens the Navigator with just the level 1 headers displayed and Headings selected.

Expected behavior:  Moving around the document also moves the location displayed in the Navigator's heading tree.  Or perhaps there could be a right click menu option to pop open the Navigator to the current position in the document.

Platform (if different from the browser): Fedora 16 with XFCE
              
Browser: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0
Comment 1 Christian Lohmaier 2011-12-28 07:00:13 UTC
confirming. proposed as easyhack
Comment 2 Michael Stahl (allotropia) 2013-04-02 21:58:18 UTC
hmm... this would need some sort of notification from the
cursor movement to the navigator dialog, probably indirectly;
i'd try defining an empty virtual method in SwCrsrShell
(since that one is used also in documents that don't have any UI)
that is called from SwCrsrShell::UpdateCrsr and with
an override in SwWrtShell... the SwWrtShell method then
updates the navigator (if it is active).

SwCrsrShell is in sw/source/core/crsr/crsrsh.cxx

but i'm not sure how to get the dialog...
the navigator is in sw/source/ui/utlui/navipi.cxx
apparently it's registered as a child window at SwView.

the outline list is apparently stored in a separate class
SwContentTree in sw/source/ui/utlui/content.cxx

SwContentType::FillMemberList

aha... so it works like this:
SwContentTree::HasContentChanged() is called from a timer
and updates the display.  it could of course request the current
cursor position from "SwWrtShell* pActShell" and select something.
probably it's not even necessary to change SwCrsrShell at all.
Comment 3 Juanan Pereira 2013-04-15 19:55:58 UTC
I have been trying to implement a fix for this issue just to discover that it is already implemented..., at least since 3.6! , but IMHO it's not obvious how to use it (I mean, it's not user-friendly). In fact, I wouldn't find it if I hadn't dug into the code O:-) 

You only have to click on the "Content View" button (located to the left of the paperclip - Set Reminder - button). Then, you can move around the document headings and they will be correctly synchronized - selected - on the Navigator). (!)

OTOH, it is true that, by default, the "Content View" button is not select, and in that configuration, Headings are _not_ synchronized with cursor's position. So, I'm wondering if I should invest my time trying to "fix" this mini-issue following Michael Stahl's implementation hints.
Comment 4 Björn Michaelsen 2013-10-04 18:47:22 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 5 Jean-Baptiste Faure 2013-10-05 17:48:57 UTC
The function already exists but the issue is that it is difficult to discover. So why not replacing the label "Content view" by something like "Synchronize the view with the content".

Best regards. JBF
Comment 6 Samuel Mehrbrodt (allotropia) 2013-10-05 17:56:00 UTC
Requesting input from UX-Advise.
Comment 7 Cor Nouws 2013-10-05 23:16:05 UTC
(In reply to comment #5)
> The function already exists but the issue is that it is difficult to
> discover. So why not replacing the label "Content view" by something like
> "Synchronize the view with the content".


Something like that. Little problem is that it works for headings, but not for tables, graphics, ... :)
So "Content view; header selected corresponding with position in the document" ?
Comment 8 Cédric Bosdonnat 2014-01-20 09:00:30 UTC
Restricted my LibreOffice hacking area
Comment 9 Rishabh 2014-11-24 21:33:41 UTC
If this bug is still open, I would like to take it up as my first bug. Any suggestions on where to start from?
Comment 10 Cor Nouws 2014-11-26 17:36:50 UTC
(In reply to Rishabh from comment #9)
> If this bug is still open, I would like to take it up as my first bug. Any
> suggestions on where to start from?

Thanks, Please look at comment 2 and if you need more suggestions, go to the developer mail list or irc.
Cor
Comment 11 Robinson Tryon (qubit) 2015-12-13 10:00:13 UTC Comment hidden (obsolete)
Comment 12 Rohan Kumar 2016-02-04 17:16:33 UTC
I just build libreoffice today. I'm starting to work on this bug.
Comment 13 jani 2016-02-04 18:15:21 UTC
(In reply to Rohan Kumar from comment #12)
> I just build libreoffice today. I'm starting to work on this bug.

Welcome.

Please assign the bug to you, so other note you work on it.

If you want help to get started or have any questions, then please contact me. I am here to help you (and others) in getting their first patch submitted.

LibreOffice is a very big program and getting it built, setting up gerrit, and getting the first patch right can be a bit challenging, therefore do not hesitate to email me if you want help.

We have made a step by step guide to help you get started:
https://wiki.documentfoundation.org/Development/GetInvolved/DeveloperStepByStep

the guide contains information you need in order to submit a patch.

rgds
jan
Comment 14 Justin L 2016-02-11 14:16:43 UTC
Created attachment 122532 [details]
test document containing a variety of navigator items

selecting a picture, cursor inside a table, section, header ought to switch to that item in the navigator.
Comment 15 Robinson Tryon (qubit) 2016-02-18 14:51:44 UTC Comment hidden (obsolete)
Comment 16 Michael Stahl (allotropia) 2016-02-18 21:13:59 UTC
comment #3 is really interesting, i must have missed it back in the day,
so what do we do here?

this bug was initially about syncing the navigator's headers tree
- which is already implemented - but not discoverable,
so i'd propose to make this bug about making that discoverable,
say by tweaking the UI string as described in comment #5,
and filing a new bug for any further enhancements such as
extending the synchronization to all the selectable things
in the naviagtor.
Comment 17 Yousuf Philips (jay) (retired) 2016-02-22 22:54:47 UTC
Yes an alternative tooltip maybe 'Content Navigation View' and the feature should be expanded to work with all content and all content should be displayed in that view and not just the category that is selected before entering the view.
Comment 18 Michael Stahl (allotropia) 2016-02-23 12:56:49 UTC
ok so i was assuming that the "Content View" only worked for Headings
and not the other things in the navigator, but it's not true,
it can be anything:
it depends on what you have selected in the navigator
when you click the "Content View" button (or press Ctrl+Return),
that determines the kind of things that will be displayed then,
everything else is missing.

the function SwContentTree::ToggleToRoot() switches between
the 2 modes, i.e. it's called when clicking the "Content View" button.

i think the synchronization / updating of the selection in the
navigator happens in SwContentTree::HasContentChanged()
in the m_bIsRoot == true branch.

i'll leave it to UX to figure out how this should be improved
and file more specific tasks.
Comment 19 Cor Nouws 2016-02-23 14:35:27 UTC
Thanks for looking into this!

(In reply to Michael Stahl from comment #18)

> it depends on what you have selected in the navigator
> when you click the "Content View" button (or press Ctrl+Return),
> that determines the kind of things that will be displayed then,
> everything else is missing.

Indeed.

> i'll leave it to UX to figure out how this should be improved
> and file more specific tasks.

IMO quite simple (to write down at least): not only with headings but also with other content: select (in content view) the object that has the focus/is selected in the document.

But...

(In reply to hindmost from comment #0)
> A way to easily go from the document to the corresponding location in the
> header tree is not available.

... this initial comment is simply not true: one 'only' has to know that setting content view for Headings is needed.

So maybe:
 - use this issue to do more on UI feedback (explanation) and
 - create a separate issue for enhancing Content view for contents other than headings ?
Comment 20 Commit Notification 2016-02-23 16:53:09 UTC
Rohan Kumar committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=10b803cf8f065f73b784304d5434b2ccd2baac46

tdf#43514 Navigation tree: improve button name

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 Cor Nouws 2016-02-23 21:36:59 UTC
(In reply to Commit Notification from comment #20)
> Rohan Kumar committed a patch related to this issue.
> It has been pushed to "master":
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=10b803cf8f065f73b784304d5434b2ccd2baac46

Thanks Rohan!
The difference between "Content view" and "Content Navigation view" is not that much. Can you give your thought about this choice please?

Ciao - Cor
Comment 22 Yousuf Philips (jay) (retired) 2016-02-23 23:38:18 UTC
Thinking more about this and i think this feature should be available in non-Content View, as i would expect this feature to be available in all modules/apps when a user opens the Navigator.

Content View according to the help is primarily for enabling drag and drop functionality for the Headings. So there isnt a point to mess with that specific functionality to get the functionality we need into the navigator.

https://help.libreoffice.org/Writer/Navigator#Content_View

So here is my proposal, we enable this functionality to work in non-Content View mode and add an entry to the context menu called "Navigate with Content" to enable and disable it (this setting should be saved to the user profile and should be on by default with a new user profile). We rename "Content View" to "Outline View" so it better describes the functionality it is focused on (bug 38262) and we limit "Outline View" to only work with headings, as it doesnt have any other functionality.
Comment 23 Rohan Kumar 2016-02-24 07:48:45 UTC
(In reply to Cor Nouws from comment #21)
> (In reply to Commit Notification from comment #20)
> > Rohan Kumar committed a patch related to this issue.
> > It has been pushed to "master":
> > 
> > http://cgit.freedesktop.org/libreoffice/core/commit/
> > ?id=10b803cf8f065f73b784304d5434b2ccd2baac46
> 
> Thanks Rohan!
> The difference between "Content view" and "Content Navigation view" is not
> that much. Can you give your thought about this choice please?
> 
> Ciao - Cor

Hello, I don't understand what you're saying. The previous patch that i submitted in order to synchronize navigator view was reviewed by Michael Stahl. He noticed that this feature was already implemented in the "Content View" button. So He asked me to update that button's name. I would really appreciate if you could elaborate it more.
Comment 24 Cor Nouws 2016-02-24 11:51:07 UTC
(In reply to Rohan Kumar from comment #23)
> Hello, I don't understand what you're saying.

Sorry for not being clear.
In comment #7 it was mentioned to use
 "Content view; header selected corresponding with position in the document"

Now this is waaay too long ;) but does tell quite precise what happens.
Could there be something in between: not too long, but a bit more descriptive?
Comment 25 Cor Nouws 2016-02-24 11:54:18 UTC
> So here is my proposal, we enable this functionality to work in non-Content
> View mode

That would be great to have of course.
But imagine that implementing that is a bit hard (after all, it's not available now, possibly for a reason), then maybe another not so huge step would bring improvement on shorter term? Which one?

But this all in a separate issue please. You may want to query for existing Navigator issues too :) please ;)
Comment 26 Rohan Kumar 2016-02-24 11:57:10 UTC
(In reply to Cor Nouws from comment #24)
> (In reply to Rohan Kumar from comment #23)
> > Hello, I don't understand what you're saying.
> 
> Sorry for not being clear.
> In comment #7 it was mentioned to use
>  "Content view; header selected corresponding with position in the document"
> 
> Now this is waaay too long ;) but does tell quite precise what happens.
> Could there be something in between: not too long, but a bit more
> descriptive?

Should i rename it to "Header View" or "Content Header View"??
Comment 27 Yousuf Philips (jay) (retired) 2016-02-24 14:54:26 UTC
(In reply to Cor Nouws from comment #25)
> That would be great to have of course.
> But imagine that implementing that is a bit hard (after all, it's not
> available now, possibly for a reason), then maybe another not so huge step
> would bring improvement on shorter term? Which one?

I'd assume its not there now because the idea to have it in non-Content View mode was never thought of. The devs can evaluate how difficult it would be to implement, but as the function is already there in Content View, porting it to non-Content View should be easy, but then it would have to be extended to work with non-header elements as well.

> But this all in a separate issue please. You may want to query for existing
> Navigator issues too :) please ;)

The proposal discusses the issue specifically (having navigator react to clicking items in the document), as well has having some additional small tweaks.
Comment 28 Yousuf Philips (jay) (retired) 2016-03-01 19:35:25 UTC
@Rohan: Not sure why you set this to resolved if it isnt completed, or has a patch not hit this page that was pushed.
Comment 29 Michael Stahl (allotropia) 2016-03-01 19:49:13 UTC
the feature that was originally requested in this bug wasn't even missing, it was there all along.  i'd say this report has so many comments going in all kinds of directions by now that we should really close it and open new bugs for any particular improvements that UX wants.
Comment 30 Rohan Kumar 2016-03-01 20:10:42 UTC
(In reply to Yousuf (Jay) Philips from comment #28)
> @Rohan: Not sure why you set this to resolved if it isnt completed, or has a
> patch not hit this page that was push(In reply to Yousuf (Jay) Philips from comment #28)
> @Rohan: Not sure why you set this to resolved if it isnt completed, or has a
> patch not hit this page that was pushed.

The feature of this issue is already implemented in the "Content View" button (although that is not working for all items). I read in the comments that there was some work to do from the UI side (Cour Nouws). I thought that improvement in that button functionality should me filed as a new issue. That's why i did it. Moreover i wasted a lot of time working for an issue that was implemented already. So i thought it was better to close a misleading easyhack.
Comment 31 Yousuf Philips (jay) (retired) 2016-03-03 05:30:10 UTC
Okay then, we should create separate bugs and see also them to this one additional context reference.