Created attachment 121227 [details] screenshot of google docs Currently it is unavailible to create groups of elements on the panel. Creating custom groups will provide a lot of possibilities! 1. Resizing LO window to smaller width will collapse groups of actions: for example narrow LO Writer panel will have allign buttons inside one. 2. It allows to place more buttons and save logical structure I offer three kinds of such groups (groupped buttons): 1. Active button + "More" arrown on the right - currently OPEN and NEW buttons behave the same 2. Button with icon of latest. Clicking on this button opens additional items 3. Expandable button. If free space allows, all elements of this button are visible on the panel, if not - it collapses.
Ok UX, this one's for you.
You are talking about 'menu button' (no default action) or 'split button' (normal button plus a designated area where the menu pops up) and the toolbar (not a panel). But I'm not sure if you want to be able to create such a button yourself, meaning you talk about the toolbar individualization, or if you want to suggest such a change in general. Today there is no chance to individualize the UI in this way. It would mean to create a new button with all the underlying functionality. But the good news is that devs are working on something similar. However, I think your idea makes no sense in general. Menu buttons violate the basic idea of toolbars that is quick access to a certain function. If you need two clicks to align text, for instance, that would be annoying. And for novices it's hard to figure out where those hidden functions are located. The idea of responsive design (grouping controls when resized) has the same limitations. Saying that does not mean I'm completely against those controls. And of course everybody should be able to have own preferences. But by default, menu buttons should be used with care. Here is the official position of the LibO design team about the toolbar https://wiki.documentfoundation.org/Design/ToolBar
This is already possible with custom content panels on the Sidebar -- but you have to roll your own for now (Basic and Macro scripting). But Laurent G's API work and registrymodifications tweaks for bug 67770 are coming along. Also follow development of bug 33223 Depending on how ones own custom content panel is assembled and packed, it will resize and respond to changes in size of the Sidebar or the Window frame. Also think Maxim M's work in bug 93837 converting menu button context menus to customizeable XML will have application to button widgets on the Sidebar deck. What is not in place yet is a drag and drop construction/adjustment for a Sidebar deck's custom content panel. But who knows... While simple .uno: actions to start, complexity of the button widgets will increase as more folks take interest in extending the Sidebar as a deck for customizing their user interface.
The main profit that I see is reducing horizontal lenglth of the panel. Currently, by default, LO have big icons and Calc panel is barely fits laptop screen. So grouping some buttons would benefit a lot! (for example grouping allignment actions)
(In reply to Heiko Tietze from comment #2) > Today there is no chance to individualize the UI in this way. It would mean > to create a new button with all the underlying functionality. Actually it should be very easy to create such buttons, thanks to my work on SubToolBarController back in July. I believe it wouldn't be that hard to let users create such group buttons themselves. > However, I think your idea makes no sense in general. Menu buttons violate > the basic idea of toolbars that is quick access to a certain function. Well, one of the problems that Yan tries to solve is the toolbar usability in a narrow window. I think that collapsing some related buttons to group buttons when the window gets narrow, is much better solution than what we're doing currently (putting everything in one popup menu). Keep in mind that the current implementation requires two clicks anyway (open the context menu+click on the menu item), and it also creates a lot of headache like Bug 42029. But I do agree that it isn't easy to implement.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
(In reply to Yan Pas from comment #4) > The main profit that I see is reducing horizontal lenglth of the panel. > Currently, by default, LO have big icons and Calc panel is barely fits > laptop screen. So grouping some buttons would benefit a lot! (for example > grouping allignment actions) (In reply to Maxim Monastirsky from comment #5) > Well, one of the problems that Yan tries to solve is the toolbar usability > in a narrow window. I think that collapsing some related buttons to group > buttons when the window gets narrow, is much better solution than what we're > doing currently (putting everything in one popup menu). Keep in mind that > the current implementation requires two clicks anyway (open the context > menu+click on the menu item), and it also creates a lot of headache like Bug > 42029. But I do agree that it isn't easy to implement. Yes being able to shrink down the toolbar when users resize the window is a useful feature and something i had wrote about previously and never filed a bug for. :D https://docs.google.com/document/d/1hSYOFoG6jnj2G0zWDbUYkrGZoj7YCSI9j3onkTZ65bU/edit#heading=h.gye3opjb9xhy So here are example toolbar xml snippets of how i believe the feature can be implemented. <toolbar:toolbarseparator/> <toolbar:toolbaritem xlink:href=".uno:LeftPara" toolbar:group="halign"/> <toolbar:toolbaritem xlink:href=".uno:CenterPara" toolbar:group="halign"/> <toolbar:toolbaritem xlink:href=".uno:RightPara" toolbar:group="halign"/> <toolbar:toolbaritem xlink:href=".uno:JustifyPara" toolbar:group="halign"/> <toolbar:toolbarseparator/> <toolbar:toolbarseparator/> <toolbar:toolbargroup> <toolbar:toolbaritem xlink:href=".uno:LeftPara"/> <toolbar:toolbaritem xlink:href=".uno:CenterPara"/> <toolbar:toolbaritem xlink:href=".uno:RightPara"/> <toolbar:toolbaritem xlink:href=".uno:JustifyPara"/> </toolbar:toolbargroup> <toolbar:toolbarseparator/> In these examples, the icon of the group button would need to be updated to the currently selected alignment option to show status, similar to how the font color button icon gets updated. There would be group button that dont require updating of the status and would be merging of not directly related radio button options, so this can be done like so in a toolbar xml. <toolbar:toolbarseparator/> <toolbar:toolbargroup xlink:href=".uno:InsertGroup"> <toolbar:toolbaritem xlink:href=".uno:InsertTable"/> <toolbar:toolbaritem xlink:href=".uno:InsertGraphic"/> <toolbar:toolbaritem xlink:href=".uno:InsertObjectChart"/> <toolbar:toolbaritem xlink:href=".uno:DrawText"/> </toolbar:toolbargroup> <toolbar:toolbarseparator/> Here .uno:InsertGroup would have an entry in the GeneralCommands.xcu and which would provide the tooltip label for the button as well as an associated image to link to. The coding part would have to be written into the window resize refreshing code. Szymon implemented a similar feature in the notebookbar, where when it is resized a group of buttons are collapsed into a single down arrow button, which hopefully will be replaced with a single group button instead.
Meanwhile, we have the Notebookbar as the innovative variant to toolbars. Users expect no 'experiments' with the classic toolbar. Setting this request as duplicate. If the request would be about the configuration with the idea to allow, for instance, to combine the text alignment commands into one menu button, it's covered by bug 103238. *** This bug has been marked as a duplicate of bug 106566 ***
(In reply to Heiko Tietze from comment #8) > If the request would be about the configuration with the idea to allow, for > instance, to combine the text alignment commands into one menu button, it's > covered by bug 103238. FYI I was exploring this possibility last week, and came up with a patch that implements creating group buttons inside the toolbar xml files, using a new toolbar:toolbargroup element (like in comment 7). For now it even shows correctly in the customization dialog (similar to how we show submenus), although changes to such a split button's contents aren't saved back to xml yet. So if there are no objections, I can continue to work on this patch (but not before discussing with other devs, whether it will OK to make this incompatible change in the toolbar xml).
(In reply to Maxim Monastirsky from comment #9) > (In reply to Heiko Tietze from comment #8) > > If the request would be about the configuration with the idea to allow, for > > instance, to combine the text alignment commands into one menu button, it's > > covered by bug 103238. > FYI I was exploring this possibility last week, and came up with a patch > that implements creating group buttons inside the toolbar xml files, using a > new toolbar:toolbargroup element (like in comment 7). For now it even shows > correctly in the customization dialog (similar to how we show submenus), > although changes to such a split button's contents aren't saved back to xml > yet. So if there are no objections, I can continue to work on this patch > (but not before discussing with other devs, whether it will OK to make this > incompatible change in the toolbar xml). Sounds great. As we scribbled the layout for the new customization we had a tree in mind to group commands. But adding a dedicated group item like a separator is maybe the safer solution.
Back to NEW, as Maxim is working in the Toolbar, not in the Notebookbar's framework.
(In reply to Maxim Monastirsky from comment #9) > FYI I was exploring this possibility last week, and came up with a patch > that implements creating group buttons inside the toolbar xml files, using a > new toolbar:toolbargroup element (like in comment 7). For now it even shows > correctly in the customization dialog (similar to how we show submenus), > although changes to such a split button's contents aren't saved back to xml > yet. So if there are no objections, I can continue to work on this patch > (but not before discussing with other devs, whether it will OK to make this > incompatible change in the toolbar xml). Great to hear it. This means we could be a bit closer to making the notebookbar user customizable. :D
(In reply to Yousuf Philips (jay) from comment #12) > Great to hear it. This means we could be a bit closer to making the > notebookbar user customizable. :D Don't understand why, as the notebookbar shares no code with the classic toolbars.
(In reply to Maxim Monastirsky from comment #13) > Don't understand why, as the notebookbar shares no code with the classic > toolbars. It is hoped that the notebookbar will in the future be xml-based similar to toolbars rather than glade ui-based, so that it can be configurable by the user.