Bug 146246 - Residual UI toggle from old Toolbox based Navigator control, but it is non-functional in the present "by element" Navigator
Summary: Residual UI toggle from old Toolbox based Navigator control, but it is non-fu...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 85905
Blocks: Navigator
  Show dependency treegraph
 
Reported: 2021-12-15 17:54 UTC by Christian Lehmann
Modified: 2022-11-09 15:58 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Lehmann 2021-12-15 17:54:59 UTC
Description:
The Navigator icon bar, last line, first symbol has a tool tip "List Box On/Off". The icon is always "on", and clicking it changes nothing. Behavior is the same on Linux and Windows. According to the LO Help (https://help.libreoffice.org/latest/en-US/text/swriter/01/02110000.html?&DbPAR=WRITER&System=UNIX), "List Box shows or hides the Navigator list." However, what is the Navigator list. And why can't it be turned off?

Steps to Reproduce:
1. Open the Navigator sidebar in Writer.
2. Click on the (highlighted) "List Box" icon.

Actual Results:
None.

Expected Results:
The List Box (whatever it is) should be turned off, and the icon should no longer be highlighted.


Reproducible: Always


User Profile Reset: No



Additional Info:
This has been so for several versions of LO.
If there is indeed no functionality to this icon, then delete it from the Navigator sidebar. Otherwise, explain the functionality in the Help.
Comment 1 Ezinne 2021-12-24 09:55:10 UTC
Reproducible in :

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 17a4f4d5e4d49189b43e748271d2d4fa330eef9b
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 2 Roman Kuznetsov 2022-11-07 19:35:50 UTC
We need some opinion by design team here
Comment 3 V Stuart Foote 2022-11-08 01:26:57 UTC
That looks to just be a residual control from the old Navigator popup "Toolbox" -- SWNavHelpToolbox.

In the past it would toggle on or off the Navigator elements shown as a list box -- the 'Navigator list'.  But as noted it now has no function.

IIRC the list like Toolbox was removed for bug 89566 with Jim's https://gerrit.libreoffice.org/c/core/+/87005/ and additional fix-ups to implement the current Navigate by Element behavior of the Navigator.

Would reconnecting the control be useful--i.e. to show Navigator without its element list?

Guess it would reduce size of a Floating Navigator deck, but the docked Navigator Sidebar would just show empty space on its deck.

So probably not?

@Jim?
Comment 4 V Stuart Foote 2022-11-08 01:39:13 UTC
(In reply to V Stuart Foote from comment #3)

Actually /me brain fart here.  The toggle *IS* fully functional with the SB Framework when the Navigator in use is the <F5> detached instance.  Just greyed inactive for the full SB.

Sorry Jim, you had it correct to start...
Comment 5 Jim Raykowski 2022-11-08 06:10:07 UTC
Code comment about this:

    "if the parent isn't a float, then the navigator is displayed in
     the sidebar or is otherwise docked. While the navigator could change
     its size, the sidebar can not, and the navigator would just waste
     space. Therefore disable this button."

@Stuart, Pretty much what you said :-)
Comment 6 V Stuart Foote 2022-11-08 14:35:16 UTC
Thanks Jim,

Agree it is still a valid behavior for the discrete <F5> launched Navigator. 

But control is currently not functional with the main SB in an undocked state--unintended? 

It is a little weird to have the icon swap (check mark colored vs. greyed out) when the control is available. And on Windows at least, the control shows either instance as if it has pointer "focus".

Worth any effort to better hide it for the main SB instance of Navigator? Or to enable it on the main SB instance when undocked?
Comment 7 Jim Raykowski 2022-11-09 08:20:27 UTC
(In reply to V Stuart Foote from comment #6)
> But control is currently not functional with the main SB in an undocked
> state--unintended?
I think that was intended. If the navigator in the sidebar, docked or floating, was allowed to change it's size I think the navigator panel size would change but the sidebar window would not change size. I suppose the entire sidebar window when floating could be made to change size but that would seem strange because the sidebar tabbar would be showing the first 4 tab buttons and the Navigator toolbox tool items.

> Worth any effort to better hide it for the main SB instance of Navigator? Or
> to enable it on the main SB instance when undocked?
It was hid for the SB instance before changes made to the Navigator toolbox around the end of 7.0 builds. Caolán did the changes for this.
Comment 8 Heiko Tietze 2022-11-09 13:31:35 UTC
Hiding the button makes sense. But I'd challenge the interaction even in floating mode. Perhaps we encapsulate the listbox in a frame and make this expandable when floating.
Comment 9 V Stuart Foote 2022-11-09 15:58:25 UTC
(In reply to Jim Raykowski from comment #7)
> I think that was intended. If the navigator in the sidebar, docked or
> floating, was allowed to change it's size I think the navigator panel size
> would change but the sidebar window would not change size. I suppose the
> entire sidebar window when floating could be made to change size but that
> would seem strange because the sidebar tabbar would be showing the first 4
> tab buttons and the Navigator toolbox tool items.
> 

Comparing differences in behavior between the discrete <F5> Navigator and the Navigator resident in the SB (see discussion bug 73151), this toggle when floating makes sense for the detached decks.

And, should bug 85905 get some attention, there would be more Decks of the SB framework that could benefit from similar kind of collapse while "floating".

So here, suppressing (or hiding) the toggle for Decks resident on the full SB continues to make sense, though I think something is not quite right with the button ATM. 

Going forward with bug 85905, having the capability would be useful--to conserve screen space and avoid clutter as the SB framework is eventually able to undock more of its Decks. The discrete undocked Decks wouldn't include the SB Tab Bar. So   other Decks/Content Panels could be reduced--as now for the Navigators "Elements" listbox.