Bug 91824 - extend view > sidebar menubar entry with subitems
Summary: extend view > sidebar menubar entry with subitems
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Sidebar-Tab-Bar
  Show dependency treegraph
 
Reported: 2015-06-03 11:16 UTC by steve
Modified: 2021-03-06 16:01 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
sidebar proposal screenshot (163.12 KB, image/jpeg)
2015-06-03 11:16 UTC, steve
Details

Note You need to log in before you can comment on or make changes to this bug.
Description steve 2015-06-03 11:16:27 UTC
Created attachment 116255 [details]
sidebar proposal screenshot

1. sidebar configuration icon should be removed
2. move items to view > sidebar submenu
3. submenu consists of
    * enable / disable (state dependent)
    * dock / undock (state dependent)
    * customize (another submenu to show / hide icons)

explanatory screenshot attached.
Comment 1 V Stuart Foote 2015-06-03 11:48:17 UTC
Not a fan of the idea. the current button has multiple functions tied directly to active _use_ of the sidebar--in docked or undocked mode.

The efficiency of the Sidebar (Tabbar, Deck and active Content Panels) is tied to availability of buttons on the configuration button dropdown.

Movement onto the Main toolbar -> View menu would place those direct controls two levels away from their affected frame. Does not seem a desierable UX, nor a justifiable change in UI.
Comment 2 Heiko Tietze 2015-06-03 17:24:02 UTC
Good idea and reasonable objection. The reason to remove the button from the sidebar is that it looks like another section due to its appearance. We could either change that. Or otherwise how about adding a submenu with all function?
Comment 3 V Stuart Foote 2015-06-03 17:51:29 UTC
(In reply to Heiko Tietze from comment #2)
> Good idea and reasonable objection. The reason to remove the button from the
> sidebar is that it looks like another section due to its appearance. We
> could either change that. 

So a different icon/label for the Configuration menu? Simply reposition from the top of the Tabbar? But that seems the most reasonable place.

> Or otherwise how about adding a submenu with all
> function?

Not sure I follow where? If within the Sidebar frame, would still require an icon button/label of some sort even if moved from the top of the Tab Bar.  And, removing it for placement on View menu alone is not viable for the UI reasons stated.

I suppose we could change the View -> Sidebar toggle button. A dropdown exposing Configuration menu to mirror  existing button menu--and then add option to suppress. The one button on the Sidebar.  But that kind of seems like a lot of work to eliminate one currently functional button.
Comment 4 Heiko Tietze 2015-06-03 21:33:58 UTC
(In reply to V Stuart Foote from comment #3)
> So a different icon/label for the Configuration menu? Simply reposition from
> the top of the Tabbar? But that seems the most reasonable place.

If it's a configuration item the natural place would be rather at the bottom. But yes, I only tried to get clearness on the reason.

> But that kind of seems
> like a lot of work to eliminate one currently functional button.

Valid objection.
Comment 5 Yousuf Philips (jay) (retired) 2015-06-04 13:22:05 UTC
As all functionality should be available in the menu according to the HIG, the ability to dock/undock and hide/show tabs of the sidebar should be available in the View menu, similar to how we have View > Toolbars.

Regarding the button in the sidebar, it is placed in a very prominent position for no good reason and it will be a feature that will be highly unused, though it does provide easy access to the functionality, similar to how we have the toolbar context menu to customize toolbars. According to design stuff i've seen from the OOo days, they thought the button should appear at the bottom of the sidebar tab bar.
Comment 6 Adolfo Jayme 2015-06-20 18:23:16 UTC
I don’t know why the Sidebar allows to hide tabs/decks. It’s pointless functionality – it does not help reduce visual clutter, for example. IMHO Sidebar’s “Customization” menu should be killed.
Comment 7 Jean-Baptiste Faure 2015-06-25 07:41:07 UTC
(In reply to Adolfo Jayme from comment #6)
> I don’t know why the Sidebar allows to hide tabs/decks. It’s pointless
> functionality – it does not help reduce visual clutter, for example. IMHO
> Sidebar’s “Customization” menu should be killed.

I agree, these customization settings are not saved when you close the current file.

Best regards. JBF
Comment 8 Yousuf Philips (jay) (retired) 2015-06-25 13:36:49 UTC
(In reply to Adolfo Jayme from comment #6)
> I don’t know why the Sidebar allows to hide tabs/decks. It’s pointless
> functionality – it does not help reduce visual clutter, for example. IMHO
> Sidebar’s “Customization” menu should be killed.

We do allow the same customization of toolbar buttons, but the likelihood of someone actually hiding a tab/deck is very slim.

(In reply to Jean-Baptiste Faure from comment #7)
> I agree, these customization settings are not saved when you close the
> current file.

As it doesnt save it between sessions, it is quite useless (bug 92332).
Comment 9 V Stuart Foote 2015-06-26 15:34:35 UTC
You all are missing the point. The Sidebar is an adjunct GUI to Toolbars. With introduction of a SDK for flexible manipulation of Sidebar's layout and function (customizations and extensions)--the Sidebar will become a more relevant GUI option.

As Jay observes, by HIG it does need to be fully exposed in Menu. But neutering customization of the GUI now just because it lacks function currently is not rational.

When Andre Fischer took on tasks of integrating the Symphony "Property panel" expanding the OOo "Task pane" it was clear that rather than a static GUI, the new 
"Sidebar" was intended to be a dynamic framework.

https://blogs.apache.org/OOo/entry/the_sidebar_new_and_improved

LibreOffice has moved it forward considerably with .UI GTK stacking based organization of the GUI--but the flexible nature of the Sidebar to the GUI remains.

Laurent Godard's work on bug 91806 -- Create a Sidebar UNO API, gets us further along in support for dynamic reconfiguration and addition by extension to the Sidebar.

Before proposing these endless "tweaks" to the UI, consider the full potential of a fully implemented Sidebar--in that case Customization will very much be needed. Please, leave it be for now and allow the development to catch up.
Comment 10 Jean-Baptiste Faure 2015-06-29 17:43:22 UTC
(In reply to V Stuart Foote from comment #9)
> You all are missing the point.

Thank you for your explanations.
Added bug 91806 to See also:

Best regards. JBF
Comment 11 Niklas Johansson 2015-07-03 20:28:18 UTC
How about turning it into a context menu?
Thereby making it more consistent with toolbars which has entries similar to the ones in the sidebar configuration icon in it's context menu.
Comment 12 steve 2015-10-25 14:14:52 UTC
update on this

1. sidebar configuration icon should be removed → WONTFIX
(this is core important functionality to be extended in the future so it won't go)

2. move items to view > sidebar submenu → NEW

adjusting title.
Comment 13 Robinson Tryon (qubit) 2016-08-25 05:49:21 UTC Comment hidden (obsolete)
Comment 14 Thomas Lendo 2018-01-24 00:04:16 UTC
As the Notebookbar variants don't show the menu bar by default and some see the Notebookbars as the future UI direction, I wouldn't MOVE such functionality into the menu. I like to have options near where it takes action. Also other settings like restore default (Bug 105131) and docking/undocking are available here.

But as HIG expects the availability in the menu, Therefore I prefer to COPY it to a new submenus.
Comment 15 Heiko Tietze 2018-02-21 19:38:42 UTC
Recommendation is to add collapse (the x in the sidebar deck) plus an additional expand to the sidebar menu.
Comment 16 steve 2021-03-06 14:07:21 UTC
Closing as invalid. This was controvertial to begin with. UI has since evolved. Don't think keeping this open provides any value.
Comment 17 Jean-Baptiste Faure 2021-03-06 16:01:29 UTC
(In reply to steve from comment #16)
> Closing as invalid. This was controvertial to begin with. UI has since
> evolved. Don't think keeping this open provides any value.

I agree, but INVALID is not the right tag, I thing WontFix is better because this bug report has valuable discussion.

Best regards. JBF