Created attachment 127269 [details] UI change button of KSO near the Update button in LO Hello, In the following of the discussion of Bug 101249 (https://bugs.documentfoundation.org/show_bug.cgi?id=101249) I am opening this bug to know if it's possible to create a button that increases the visibility of the option to change the Toolbar Layout that will be introduced in 5.3 in the View --> Toolbar Layout menu. https://vid.me/bpS3 --> video of ht behaviour Is this feasible, considering that a few OSes integrate the Menu bar in the top bar (Ex. MacOS, Ubuntu)? Best regards, Pedro
2 cents incoming: I think this is a view option. Having the switcher button would just clutter the toolbar. LO comes with the option that serves most users needs (the 2 row toolbar). If you want to switch, you can do that via the view menubar option (which is the correct place for this imo). As an alternative the option could be in the LO preferneces > View, but honestly I prefer the menubar > view. The switching process is a one time process that has no need for repeated action. Thus I vote against adding this as option to the toolbar. I am not sure I understand what the screenshot should be pointing out. It would be helpful to mark the section of the screenshot which is relevant to this specific bug.
(In reply to steve -_- from comment #1) > I think this is a view option. Having the switcher button would just clutter > the toolbar. I don't see it as necessary, but believe Pedro is proposing adding a button to a different "prominent" GUI element, not to an existing Toolbar. > As an alternative the option could be in the LO preferences > View, but > honestly I prefer the menubar > view. > Yes, would agree that in addition to the View -> Toolbars Layout menu, it should be added as a drop list to the Tools -> Options -> View: User Interface section. > The switching process is a one time process that has no need for repeated > action. Thus I vote against adding this as option to the toolbar. Would agree, no need for a button widget on Toolbar (either standard tool bar, or a "special" toolbar just for a toolbar View split button). However, suspect you underestimate the frequency folks would be changing their toolbar mode. Especially if we can not get the toolbars to assert per module stateful by user profile.
(In reply to steve -_- from comment #1) > 2 cents incoming: > I think this is a view option. Having the switcher button would just clutter > the toolbar. I am not saying including it in the toolbar, but next to the Update button that shows up when an update is available in LO as I've written in the text and exemplified in the figure. > LO comes with the option that serves most users needs (the 2 row toolbar). > If you want to switch, you can do that via the view menubar option (which is > the correct place for this imo). My point is that having that option buried in menus will keep it out of sight of the common users who may not even notice that. As for the double toolbar serving most user needs, that's besides the point. If that was the case LO wouldn't be constantly criticized in every release because of its dated UI. In case you haven't noticed in the past 13 years the overwhelming majority of Office suite users have been using different UI paradigms than a double toolbar. And the UI team has been hard at work in creating and imrpoving three different UIs for LO. > As an alternative the option could be in the LO preferneces > View, but > honestly I prefer the menubar > view. > > The switching process is a one time process that has no need for repeated > action. Thus I vote against adding this as option to the toolbar. Why is it a one time process? for you maybe, but what if an user prefers to use Sidebar in Writer, double toolbar in Calc and Single toolbar in Impress and wants to change the UI per module? > I am not sure I understand what the screenshot should be pointing out. It > would be helpful to mark the section of the screenshot which is relevant to > this specific bug. Will do. What I am asking is the feasibility of creating a button next to the Update button (which sits on the Menu bar) and separate of the toolbar buttons. This would achieve the following: - Make the option to change between toolbar modes easier to reach (less clicks and more visible), - Would not site on any of the toolbars. - Would not be buried in a Menu, so normal users would notice it more. - It would make the work of the LO UI/Design team more visible to the user and easier to be toggled on, instead of defaulting to a legacy UI and hiding the work done by so many people in the past year and a half under a Menu option (whichmost casual users avoid as much as possible).
Created attachment 127277 [details] Highlighted toolbar Layout button near to Update button
Created attachment 127278 [details] UI Change button in KSO
(In reply to steve -_- from comment #1) > As an alternative the option could be in the LO preferneces > View, but > honestly I prefer the menubar > view. Not a good alternative place as only advanced users open the options dialog and there are different toolbar modes per module (e.g. there is no sidebar mode in impress and there is no single toolbar mode in draw) (In reply to Pedro from comment #3) > Why is it a one time process? for you maybe, but what if an user prefers to > use Sidebar in Writer, double toolbar in Calc and Single toolbar in Impress > and wants to change the UI per module? Yes per module users may want to change it once or more until they are content with the mode and then they normally never change it again. With KSO, i only switch to the classic mode when i want to see their menu or toolbar structure, other than that, i stick with their ribbon UI. Setting the necessary keywords to have a dev look into how difficult it would be to implement this, though i believe that it should be simple as we are already doing the same for the update button, though it maybe difficult to have a menu popup from clicking the button, which in that case we could always create a dialog for the switching if necessary. I believe the update icon code is here. http://opengrok.libreoffice.org/xref/core/extensions/source/update/ui/updatecheckui.cxx
Created attachment 127287 [details] menubar close button always active, and transient update button on a Windows build The menubar Close button and LibreOffice Update button widgets are hard coded in src, they are not .UI configured. And placement onto the menubar is really not a very good part of the UI to try using for GUI configuration preferences. =-ref-= http://opengrok.libreoffice.org/xref/core/extensions/source/update/check/updatecheck.hxx#141 http://opengrok.libreoffice.org/xref/core/vcl/source/window/menubarwindow.cxx http://opengrok.libreoffice.org/xref/core/vcl/inc/salmenu.hxx of course GTK has its on twist on things.
"And placement onto the menubar is really not a very good part of the UI to try using for GUI configuration preferences." It's a method of having a one way stop for UI configuration instead of having it spread around multiple dialog boxes and accessed in multiple Menu items. For example, if I want to change the icon set, icon size, and toolbar layout I have to go to: Tools --> Options --> View to change icons, View --> Toolbar Layout These options should be readily accessible in the same module to allow for more intuitive and faster configuration so that I can quickly adjust the UI to my needs and preferences instead of having to dig around in completely unrelated modules. IMO having this immediately visible to the user is crucial because it will become one of the strong and unique points of LO. The user can make it its own. If you don't agree with having the button there, then I would suggest creating a completely separate Menu entry then. But hey, if you don't want the excelent work done by yourselves in the past year and a half - to provide the users with UI choices - easily discoverable then that's on you. If I had spent so much time doing this, and being fully confident in my work I would try to make as easily discoverable as possible instead of hiding it away in submenus to stick to a legacy UI that wasn't developed by the LO contributors.
Havent read everything in here, but atm we shouldn't add any easy discoverable means to activate the Notebookbar. It is only a proof-of-concept currently and far from finished. Please leave it hidden for now, as we did with the Sidebar in earlier days.
(In reply to Pedro from comment #8) > These options should be readily accessible in the same module to allow for > more intuitive and faster configuration so that I can quickly adjust the UI > to my needs and preferences instead of having to dig around in completely > unrelated modules. True, see bug 80544. > IMO having this immediately visible to the user is crucial because it will > become one of the strong and unique points of LO. The user can make it its > own. It definitely is useful, but not crucial, as the user had the option to reorganize the toolbars previously, though had to do it manually. > If you don't agree with having the button there, then I would suggest > creating a completely separate Menu entry then. Unfortunately that isnt a good idea, as changing the layout of toolbars isnt important enough to justify that. > But hey, if you don't want the excelent work done by yourselves in the past > year and a half - to provide the users with UI choices - easily discoverable > then that's on you. Yes we do want users to easily be able to switch the toolbar layout, which is why we didnt stuff this option in the Options dialog, but added it to the recently organized menu bar. Having a button on the menubar will possibly make this feature more easily discoverable, but there isnt any guaranteed method that will show this option to the user. What is the 'year and a half' you are referring to? > If I had spent so much time doing this, and being fully confident in my work > I would try to make as easily discoverable as possible instead of hiding it > away in submenus to stick to a legacy UI that wasn't developed by the LO > contributors. Not getting what you mean by 'so much time', but if you are talking about the notebookbar, then it has been worked on for maybe 6 months. Toolbars are used in most applications, so i wouldnt call it a legacy UI and we have improved the toolbars during LO's lifetime. (In reply to Samuel Mehrbrodt (CIB) from comment #9) > Havent read everything in here, but atm we shouldn't add any easy > discoverable means to activate the Notebookbar. It is only a > proof-of-concept currently and far from finished. The button isnt about easy discoverability of the notebookbar, but easy discoverability of switching the toolbar layouts/modes.
(In reply to Yousuf Philips (jay) from comment #10) > (In reply to Samuel Mehrbrodt (CIB) from comment #9) > > Havent read everything in here, but atm we shouldn't add any easy > > discoverable means to activate the Notebookbar. It is only a > > proof-of-concept currently and far from finished. > > The button isnt about easy discoverability of the notebookbar, but easy > discoverability of switching the toolbar layouts/modes. No, I think what Samuel is concerned about *is* that we are already providing too much visibility to the NotebookBar before it has been fully implemented. Like the Sidebar in its debut--the NotebookBar should probably remain an experimental feature rather than already being enabled by default and already visible from the View -> Toolbar Layout entries. This obsession with making it "easily accessible" is premature.
(In reply to V Stuart Foote from comment #11) > (In reply to Yousuf Philips (jay) from comment #10) > > (In reply to Samuel Mehrbrodt (CIB) from comment #9) > > > Havent read everything in here, but atm we shouldn't add any easy > > > discoverable means to activate the Notebookbar. It is only a > > > proof-of-concept currently and far from finished. > > > > The button isnt about easy discoverability of the notebookbar, but easy > > discoverability of switching the toolbar layouts/modes. > > No, I think what Samuel is concerned about *is* that we are already > providing too much visibility to the NotebookBar before it has been fully > implemented. Like the Sidebar in its debut--the NotebookBar should probably > remain an experimental feature rather than already being enabled by default > and already visible from the View -> Toolbar Layout entries. > > This obsession with making it "easily accessible" is premature. Exactly, thanks Stuart!
(In reply to V Stuart Foote from comment #11) > No, I think what Samuel is concerned about *is* that we are already > providing too much visibility to the NotebookBar before it has been fully > implemented. Like the Sidebar in its debut--the NotebookBar should probably > remain an experimental feature rather than already being enabled by default > and already visible from the View -> Toolbar Layout entries. Well the sidebar was an experimental feature in 4.1 before its debut in 4.2, so maybe the notebookbar should only be visible when the experimental checkbox is checked in the options dialog. > This obsession with making it "easily accessible" is premature. Well that doesnt change the fact of having the other toolbar modes easily accessible. There is going to be alot of hype/discussion/retaliation around the notebookbar when 5.3 is released and people are going to try it and reporters are going to write about it and i'm assuming it will also be featured in the 'what's new' videos. So we better braise for impact.
(In reply to Yousuf Philips (jay) from comment #13) > Well the sidebar was an experimental feature in 4.1 before its debut in 4.2, > so maybe the notebookbar should only be visible when the experimental > checkbox is checked in the options dialog. If you enabled the experimental options, only the menu entry to activate the sidebar became visible. Nothing more. > Well that doesnt change the fact of having the other toolbar modes easily > accessible. > > There is going to be alot of hype/discussion/retaliation around the > notebookbar when 5.3 is released and people are going to try it and > reporters are going to write about it and i'm assuming it will also be > featured in the 'what's new' videos. So we better braise for impact. Not if we do not mention them in the release notes. And I think we shouldn't before we have the same for all apps (we have ~nothing for Base,Math,Basic IDE atm). And its really not ready to replace the current toolbars. we have no way to customize things or allow extensions to integrate.
Also it might be worth bumping the major version to 6.0 if we release the Notebookbar/other toolbar modes, so I really think we should wait 1 or two releases before making it public. For the enthusiasts it already is there to try out.
(In reply to Samuel Mehrbrodt (CIB) from comment #14) > If you enabled the experimental options, only the menu entry to activate the > sidebar became visible. Nothing more. Didnt quite follow, but i'm saying that we could link the experimental options checkbox with the visibility of notebookbar entry in the toolbar layout submenu (.uno:ToolbarMode) and we would likely have to remove the notebookbar submenu (.uno:Notebookbar) from the view menu unless it can be hidden. > Not if we do not mention them in the release notes. Already mentioned in the release notes as it was GSoC work. > And I think we shouldn't before we have the same for all apps (we have > ~nothing for Base,Math,Basic IDE atm). I doubt notebookbar is needed in math, as the toolbar is pretty much empty already, or for basic ide as devs dont care for a notebookbar interface. No idea about base as i havent used it or worked on its toolbars or menus. :D > And its really not ready to replace the current toolbars. we have no way to > customize things or allow extensions to integrate. Thats why i'm suggesting it only be visible when experimental options is enabled, as it is unfinished. (In reply to Samuel Mehrbrodt (CIB) from comment #15) > Also it might be worth bumping the major version to 6.0 if we release the > Notebookbar/other toolbar modes, so I really think we should wait 1 or two > releases before making it public. Yes bumping to 6.0 for the release of notebookbar sounds like a good idea, and i believe 6.0 is already scheduled to happen after 5.3.
I do agree that the Notebookbar should not be accessible untill it is considered to be usable enough at least in the three main modules (Writer, Impress and Calc) and maybe in Draw as well. But that doesn't invalidate the discussion for making these default toolbar layouts already available to become discoverable. But I guess that having them under the View Menu is already a lot better than having them buried in: Tools --> Options --> View I just wanted to see it even less buried. But if it's not feasible then I won't push for more. Maybe move the selection of icon set and icon size to the View Menu as well then. For visually impaired users it would probably be easier to change icon size if it was under the View menu which is much more accessible than under 3 submenus. And the icon set would be another interesting option. The issue then is that the View menu would have too many subcategories.
*** Bug 106630 has been marked as a duplicate of this bug. ***
Calling this resolved fixed with work on bug 115131 to elevate the Notebookbar modes (still experimental) onto the main menu as elements on the new View -> User Interface list. Present on the main menu, and from Notebookbar menus, so no need for a GUI split-button object. Desired visibility of the MUFFIN Notebookbar modes has been achieved. =-ref-= https://gerrit.libreoffice.org/49575 https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=5c573a2f7473bae7bb965ca36557cd1b0bf7b9c9