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
confirming. proposed as easyhack
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.
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.
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
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
Requesting input from UX-Advise.
(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" ?
Restricted my LibreOffice hacking area
If this bug is still open, I would like to take it up as my first bug. Any suggestions on where to start from?
(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
Migrating Whiteboard tags to Keywords: (easyHack, difficultyBeginner, skillCpp) [NinjaEdit]
I just build libreoffice today. I'm starting to work on this bug.
(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
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.
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
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.
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.
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.
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 ?
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.
(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
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.
(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.
(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?
> 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 ;)
(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"??
(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.
@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 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.
(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.
Okay then, we should create separate bugs and see also them to this one additional context reference.