Bug Hunting Session
Bug 115817 - Correct implementation or remove the Navigation toolbar (a GSOC 2009 contribution see bug 32869) (comment 3 for history and functional intent)
Summary: Correct implementation or remove the Navigation toolbar (a GSOC 2009 contribu...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: implementationError
: 49710 98762 98877 (view as bug list)
Depends on:
Blocks: Navigator Writer-Toolbars
  Show dependency treegraph
 
Reported: 2018-02-17 23:45 UTC by Yousuf Philips (jay) (retired)
Modified: 2019-01-23 14:23 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
Renewal of navigation toolbar (32.15 KB, application/pdf)
2018-05-24 13:29 UTC, Christian Lehmann
Details
replace the navigation facility by a more straightforward function (32.15 KB, application/pdf)
2018-06-06 12:46 UTC, Christian Lehmann
Details
Docked Navigator in Writer, Calc and Navigation Toolbar (102.74 KB, image/jpeg)
2019-01-23 05:47 UTC, russell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2018-02-17 23:45:21 UTC
When clicking on an element in the Navigator, the Navigation toolbar pops up and its back and forth buttons dont seem to work correctly, so i'd prefer that this toolbar not appear and disrupt the position of the existing formatting toolbar and preferably be completely removed if the functionality of the buttons cant be clearly understood.
Comment 1 Heiko Tietze 2018-02-18 08:33:48 UTC
Raised in bug 38781 comment 10 and we should keep it there IMHO.

*** This bug has been marked as a duplicate of bug 38781 ***
Comment 2 Heiko Tietze 2018-02-22 17:32:35 UTC
Jay was right, we better have an extra ticket for the UX issue. Discussion so far on bug 38782:

(In reply to Olivier Hallot from comment #10)
> Behaviour is apparently erratic and lack of description does not help user.
> 
> https://ask.libreoffice.org/en/question/114955/navigation-toolbar-appears-on-inserting-headerfooter-in-a-document/

(In reply to Heiko Tietze from comment #11)
> Introduced with bug 32869 in
> https://opengrok.libreoffice.org/xref/core/sw/source/uibase/wrtsh/navmgr.cxx
> the purpose is to navigate over hyperlinks in the document. We could enhance
> the toolbar with next/previous page.

(In reply to V Stuart Foote from comment #13)
> The source [1][2] is reasonably well documented. And the Greenberg &
> Cockburn [3] "recency with temporal ordering" based back and forward history
> navigation remains.  But, if fully functional would expect the feature to be
> less about navigating hyperlinks (internal or external) and for the control
> to provide more generic Back and Forward movements within a document.
> 
> A GoToMark, GoToFLy, GotoINetAttr, GotoOutline (index), GotoOutline
> (string), GotoRegion, GotoRefMark, GotoNextTOXBase, GotoTable,GotoFld, and
> GotoRedline action were linked as history navigation targets. 
> 
> Unfortunately, not clear the "recency with temporal ordering" of the
> navigation history is still implemented correctly. I couldn't identify where
> in UI a user could "add" a mark to trigger inclusion of a SwUnoCsr position
> to the m_entries[] list and _activate_ the control. And while inserting an
> internal hyperlink--reference, bookmark, header, footer, etc. the Cusor is
> registered into the navigation history, and activates the Navigation toolbar
> controls--other actions for cursor/focus movement do not.  For example a
> Go-to-End of document should provide a Navigation toolbar action to return
> from.
> 
> =-ref-=
> [1]
> https://opengrok.libreoffice.org/xref/core/sw/source/uibase/wrtsh/navmgr.
> cxx?a=true
> 
> [2] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/inc/navsh.hxx
> 
> [3] https://prism.ucalgary.ca/bitstream/handle/1880/45977/1999-641-04.pdf

(In reply to V Stuart Foote from comment #14)
> Aslo, if fully functional seems like this set of controls--.uno:NavigateBack
> & .uno:NavigateForward would make sense to appear in the Standard toolbar,
> or maybe the Navigator dialog adjacent to the PreviousPage/NextPage buttons.
Comment 3 V Stuart Foote 2018-02-23 00:41:12 UTC
(In reply to Heiko Tietze from comment #2)
> Jay was right, we better have an extra ticket for the UX issue. 

Sorry I should also have included link to the navmgr.hxx.

Here is Maja's original description of the navigation history. When originaly implemented the function tracked SwPosition--but Michael S. changed that to use SwUnoCrsr (unocrsr.hxx) for more robust behavior [1]:

class SW_DLLPUBLIC SwNavigationMgr
{
private:
/*
* List of entries in the navigation history
* Each entry is a SwPosition, which represents a position within the document
* SwPosition is given by a node index (SwNodeIndex) which usually represents the paragraph the position is in
* and an index (SwIndex), which represents the position inside this paragraph.
* You can find more on SwPositions at http://wiki.services.openoffice.org/wiki/Writer_Core_And_Layout
*
* The navigation history behaves as a stack, to which items are added when we jump to a new position
* (e.g. click a link, or double click an entry from the navigator).
* Every use of the back/forward buttons results in moving the stack pointer within the navigation history
*/

So, it seems the Navigation toolbar is a dedicated shell for Writer that tracks movement through the UI and permits "back" button navigation of its stack with some concept of "curency" of position in the history of movements. Provides a helper in addition to other Navigator's by "mode" provided movements. 

For example the "reminder" mode (the Paper clip icon) keeps a separate stack of Marks (to depth of MAX_MARKS default of 5)--but the NavigationMgr m_aNavigationMgr receives and follows these swUnoCursr objects on its stack. The modes provided in Navigator are specific for each flavor of events. 

IIUC the NavigationMgr exposes the movement events (that it is aware of) [2]--and implements a toolbar with Back/Forward button controls to move among all of them.

I think the buttons from the toolbar probably ought to have been added to the Navigator from the beginning. The Navigator's current Previous/Next buttons apply to the active Navigator mode--while the Navigation buttons draw events from across the UI.  Is there a spot on the Navigator UI the more general movements from the Navigation toolbar would make sense?

Likewise I think some of the movements in the sw UI ought to be exposed to the Navigation toolbar's buttons but aren't--position to Top of document, End of document, next Paragraph, next page, etc. This may need some additional dev effort to 

Also, seems the same ability to navigate between cursor positions in the other LO modules by Back/Forward button action would be a good enhancement if this is the right framework to hang it off of.


=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/inc/navmgr.hxx?#24
[2] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/inc/wrtsh.hxx?#461
Comment 4 V Stuart Foote 2018-04-17 18:43:49 UTC
The Navigation toolbar is a counterpoint to the modal "Navigator", as intended its backward and forward navigation was to be more like navigating a web browser's history, positioning document focus to any of the established markers. 

The use case is still valid, but not sure the implementation is fully complete, and no documentation was added to help (bug 38781).

Kind of think that if this were fully developed, it would be a reasonable interface to allow history movement between soffice.bin modules rather than just the Writer shell, where as noted it is a bit confusing as to function.
Comment 5 Cor Nouws 2018-04-17 18:50:03 UTC
(In reply to V Stuart Foote from comment #4)

> The use case is still valid, but not sure the implementation is fully
> complete, and no documentation was added to help (bug 38781).

Indeed. So better improve then remove
Comment 6 V Stuart Foote 2018-04-17 19:16:09 UTC
@Maxim, Adolfo -- does this UI navigation stack make sense to retain? That is, is it worth salvaging? And given it was a GSOC (2009 so OOo) effort would be sad to just purge it.

See the OOo history for the feature request: 
https://bz.apache.org/ooo/show_bug.cgi?id=5608
Comment 7 V Stuart Foote 2018-04-17 19:36:42 UTC
@Thorsten, you mentored Maja D. in 2009 for this work--do you have any thoughts on what is correct here in these dark corners of the code base?
Comment 8 Thorsten Behrens (CIB) 2018-04-17 22:10:18 UTC
(In reply to V Stuart Foote from comment #7)
> @Thorsten, you mentored Maja D. in 2009 for this work--do you have any
> thoughts on what is correct here in these dark corners of the code base?

If the toolbar is the problem - move the functions somewhere else? At least when it was implemented, people thought it's quite useful.
Comment 9 Samuel Mehrbrodt (CIB) 2018-04-18 19:39:10 UTC
I one had a patch to remove this very feature at https://gerrit.libreoffice.org/#/c/10551/ but there were some people opposing the removal.

So it seems to be useful to some. Of course we should make sure the toolbar doesn't randomly pops up etc.
Comment 10 Heiko Tietze 2018-04-20 13:56:11 UTC
Removing needsUX as the decision was made to keep the functionality. As Samuel points out we have top take care about the position of the controls; should be done in this ticket IMO.
Comment 11 Heiko Tietze 2018-04-20 14:00:42 UTC
As an idea, it was suggested to work these functions into the Navigator dialog (good idea IMO) or/and added to Standard toolbar (very bad idea IMO).

Fix docking left (edit: or anywhere else), another idea, is not an option since users define the UI and have the Navigator docked left, for example.
Comment 12 Cor Nouws 2018-04-20 14:20:24 UTC
(In reply to Heiko Tietze from comment #11)
> As an idea, it was suggested to work these functions into the Navigator
> dialog (good idea IMO) 

The tool bar of the Navigator already is quite loaded, so I see a challenge there..

Integrating in the Navigation bar, that can be started from the Navigator?
Could be. But will then the 'edit positions' be on of the many choices, or a separate one?
Comment 13 V Stuart Foote 2018-05-05 01:40:26 UTC
*** Bug 98762 has been marked as a duplicate of this bug. ***
Comment 14 V Stuart Foote 2018-05-05 01:40:39 UTC
*** Bug 98877 has been marked as a duplicate of this bug. ***
Comment 15 V Stuart Foote 2018-05-05 01:41:28 UTC
*** Bug 49710 has been marked as a duplicate of this bug. ***
Comment 16 V Stuart Foote 2018-05-05 01:45:06 UTC
*** Bug 43220 has been marked as a duplicate of this bug. ***
Comment 17 V Stuart Foote 2018-05-05 01:52:13 UTC
QA housekeeping, moved all issues of the Navigation toolbar here.

Either need to complete the implementation of the multi-element type navigation stack fixing its behavior (in GUI and function); or go ahead and delete the module.

This was developed at the end of OOo era, and integrated into LibreOffice at initial 3.3.0 release.
Comment 18 Christian Lehmann 2018-05-24 13:29:05 UTC
Created attachment 142262 [details]
Renewal of navigation toolbar

It proposes a reduced version of the current 'Reminder' function of LO Writer to replace the Navigation toolbar.
Comment 19 Christian Lehmann 2018-06-06 12:46:00 UTC
Created attachment 142560 [details]
replace the navigation facility by a more straightforward function
Comment 20 Christian Lehmann 2018-08-16 16:02:24 UTC Comment hidden (no-value)
Comment 21 Ljiljan 2018-08-16 16:33:56 UTC
(In reply to Christian Lehmann from comment #20)
> I am disappointed that the bug pointed out by Yousuf (the ever-popping up
> navigation bar) has not been removed even in the newest version of LO
> (6.0.6.2). Maybe some people have a narrow notion of 'bug' so that something
> is a bug only if the entire system breaks down. Please widen the notion a
> bit: Something that definitely obstructs the user in doing his work is a
> bug. If you really think the navigation bar is a valuable feature, then at
> least allow the user to deactivate it.
> 
> Maybe progress on this matter presupposes that somebody change the status to
> 'confirmed'.

I haven't notice Navigation bar in Lo 6.1 with Notebookbar Style, but I don't think this bug will be solved... you just learn to live with it. I removed all buttons on this toolbar (so it is very small) and position it at the top left part of my screen, so when it appears, it does not make me nervous too much... I hardly notice it :-) Per each session, you can also go to View -> Toolbars -> Navigation to disable it temporarily. So during that session, it will not popup. Next time, you just need to do the same. So these are workarounds that can help you to reduce the pain caused by this bug.
Comment 22 Christian Lehmann 2019-01-01 17:59:03 UTC
@Ljiljan:
Not even the workarounds that you recommend do what you think. If you deactivate the navigator, it pops up again on the next (unpredictable) occasion, not just when I start LO the next time. And it does occupy an entire line of precious writing space.

The navigator icon is the only icon in the entire LO software that
- occupies an entire toolbar by itself
- and the user is not allowed to deactivate this toolbar for the entire session (or forever).
It must really enjoy the highest priority in the view of some developers.
Comment 23 Cor Nouws 2019-01-01 19:12:34 UTC
(In reply to Christian Lehmann from comment #22)
> The navigator icon is the only icon in the entire LO software that
> - occupies an entire toolbar by itself
> - and the user is not allowed to deactivate this toolbar for the entire
> session (or forever).
As you can read in the comments. it's not only you that is annoyed by the behavior.
Let's ask UX_advise to come with a choice on how to resolve.
Comment 24 V Stuart Foote 2019-01-01 20:12:38 UTC
(In reply to Christian Lehmann from comment #22)
> ...
> The navigator icon is the only icon in the entire LO software that
> - occupies an entire toolbar by itself
> - and the user is not allowed to deactivate this toolbar for the entire
> session (or forever).
> It must really enjoy the highest priority in the view of some developers.

The control is the "Navigation" toolbar, the Navigator is a completely different dialog based UI component.

Otherwise, the Navigation toolbar *is* a standard toolbar and behaves as such. Meaning "just dock it", IMHO at the end of the Standard toolbar is pretty unobtrusive. Positioned there its two buttons are well behaved.

It would be great to complete multi-element navigation, especially cross module. Or if concensus is to kill it off for lack of dev interest that works also.

Otherwise, it really is benign, and seems to have no impact with the MUFFIN Notebookbar as the popup toolbars are suppressed.

It is only its default toolbar pop-up behavior that annoys folks--that seems an easy fix (users can open and dock it, or we can pick a spot and do it by default).
Comment 25 Roman Kuznetsov 2019-01-16 17:25:16 UTC
(In reply to Samuel Mehrbrodt (CIB) from comment #9)

> So it seems to be useful to some. Of course we should make sure the toolbar
> doesn't randomly pops up etc.

I fully agree with this opinion
Comment 26 Heiko Tietze 2019-01-17 14:35:05 UTC
We talked about this in the design meeting and suggest to dock by default at the end of the Standard toolbar (as there is one item more space than on the Formatting toolbar).
Comment 27 russell 2019-01-23 05:47:23 UTC
Created attachment 148536 [details]
Docked Navigator in Writer, Calc and Navigation Toolbar

Please see the attached image.

I use the Navigator docked in the sidebar, in both Writer & Calc. I have more horizontal space than vertical, so I add things to the left or right. I dock everything when available.

I don't use the Navigation Toolbar (1), because I use the Navigator scrollable list. 

It seems the main purpose of the Navigation Toolbar is to prime the left and right arrows on the Navigator (or the up & down arrows in the Navigation Toolbar). The "Extended Help" text changes over the Navigator left and right arrows to reflect what was selected in the Navigation Toolbar.

Suggestion 1:

How about changing how the button works in the Navigator. When clicked, rather than opening the Navigation Toolbar, change the button to a drop-down radio list, similar to (2) and (3). Change the button image to reflect the action being taken; Reuse the images that are currently shown on the Navigation Toolbar. The arrows in the Navigator can then be used to reposition. To change what to maneuver to, just click the Navigation button on the Navigator and select a different radio button.

Suggestion 2:

Remove the button, and instead use whatever is highlighted/selected in the Navigator list to prime the arrows.  For example, if the user clicks on "Images" the arrows would find the previous and next images.
Comment 28 Heiko Tietze 2019-01-23 06:31:48 UTC
(In reply to russell from comment #27)
> How about changing how the button works in the Navigator...
> ...
> Remove the button, and instead use whatever is highlighted/selected in the
> Navigator list to prime the arrows.

Of course there are better solutions. For example we made a fancy mockup for the Navigator https://design.blog.documentfoundation.org/2016/07/31/how-the-navigator-may-support-object-handling-in-libreoffice-draw/ but due to lack of development expertise (and the need for effort in other areas) it's far from being implemented. 

Docking is simple and can be done by (almost) everyone, that's why we recommend it.
Comment 29 V Stuart Foote 2019-01-23 14:23:48 UTC
(In reply to russell from comment #27)
> 
> I don't use the Navigation Toolbar (1), because I use the Navigator
> scrollable list. 
> 

And that is not the "Navigation Toolbar" feature this issue is about. That is the "mode selector" for the modal Navigator deck of the Sidebar.  

Issue here is the pop-up behavior of the incomplete multi-mode Navigation stack of the toolbar, nothing to do with the Navigator deck (ex dialog).

They happen to be similarly named, but completely different function and code.