Single toolbar work only for context-text. For all other context views it will show an the additional context toolbar, so it want be no single toolbar. Contextual single notebookbar is always one line and context related. Only drawback. Contextual single is not configured as long as NB don't offer config options.
Let's make contextual single more usability before
Discussion need ordinary some time
Hmmn, I can see some appeal to doing this for MUFFIN using a Notebook Bar. Unfortunately the framework of the Customize dialog has not been expanded to allow users to conveniently configure any of the Notebook Bar GUI constructs. Absent a Customize dialog ability to customize the Notebook Bar modes (bug 101513) replacement of the Single Mode toolbar (it is present in Writer, Calc, Impress adjusted component) would not be good UX. Is there a UX need to change it now? Not so much, I believe there are other options offering better UX and clear dev paths. And when customization support for all MUFFIN framework components (i.e. NB, SideBar, extensions) is implemented, only then should a Notebook Bar construct be considered viable replacement for a Toolbar. Currently the Single Toolbar is fully customizable--the Customize -> Toolbars target is "Standard (Single Mode)"--which includes addition of context sensitive button widgets drawn from other context-sensitive toolbars. And it could be enhanced with framework needed for bug 36976 and bug 106846 Again, IMHO while working with legacy Toolbars of button widgets, to suppress the UI layout disruption of context-sensitive popup toolbars, implementing a Sidebar Deck holding a Content Panel packed with context driven toolbar buttons would be a MUFFIN friendly alternative to the popup toolbars.
Definitely +1 for the idea. Implementation-wise it doesn't sound too hard to have a "normal" toolbar that loads different toolbar xml files depending on the context. That way we can get customization and extensions support for free.
(In reply to Maxim Monastirsky from comment #4) > Definitely +1 for the idea. Implementation-wise it doesn't sound too hard to > have a "normal" toolbar that loads different toolbar xml files depending on > the context. That way we can get customization and extensions support for > free. So rather than the current "Single Mode" toolbar, or the current .UI for Contextual Single notebook bar[1][2]--we'd modify the Contextual Single Notebook Bar to parse XML from the other Toolbars that can already be customized/extended? And that becomes the new Single Mode--very MUFFIN! :-) =-refs-= [1] https://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/UI/ToolbarMode.xcu?r=db393365#215 [2] https://opengrok.libreoffice.org/xref/core/sw/uiconfig/swriter/ui/notebookbar_single.ui?r=0d47abc5
Would be awesome maxim. The problem is I don't know the internals of libo codebase. If we can work there together it would be fine. Easiest would be to have an separate toolbar folder where all the standard and contextual xml files are located. Other option one small standard toolbar and right to the small standard all the contextual xml files. Maybe that can be done within the existing toolbar folder.
Created attachment 151110 [details] Proof of concept patch To make it clearer what I mean, I took a few hours to play with the code, and came up with the attached patch that demonstrates my idea. This uses the existing single mode toolbar (View > UI > Single Toolbar), and appends to the end of it some existing contextual toolbar. So e.g. when an image is selected, the toolbar consists of singlemode.xml + separator + graphicobjectbar.xml. For the demonstration, I hard-coded some contexts in Writer (Text, Table, Graphic, OLE, Draw) and mapped them to the existing toolbars. Customization via the dialog, and support for extensions *works already* with this patch (by request, I can attach a sample extension, so it could be tested). Customization via right-click context menu doesn't work yet (but that's just a demonstration anyway).
I think the behavior is similar with contextual single nb, but with the power of customization and extension support. Can I see an screenshot with context draw and graphic.
(In reply to andreas_k from comment #8) > Can I see an screenshot with context draw and graphic. I can attach a screenshot, but what do you expect to see there? My point was just to showcase the behavior of combining two xml files into one toolbar, and changing that toolbar dynamically based on the context, and not to show any particular UI arrangement. I used existing toolbars for demonstration purposes, but similarly it could be done with dedicated xml files.
Feels to me that not going the NB way is kind of turning away from this type of UI. Given we get customization, a11y, integration of extensions etc. for the NB, what path do we want to go in the future? Or in other words, what exactly is the NB good for when not this single contextual toolbar?
(In reply to Heiko Tietze from comment #10) > Feels to me that not going the NB way is kind of turning away from this type > of UI. Given we get customization, a11y, integration of extensions etc. for > the NB, what path do we want to go in the future? Or in other words, what > exactly is the NB good for when not this single contextual toolbar? Contextual single NB is good for make single line toolbar better. Which is fine. You can't do everything with toolbars but contextual single can be done with toolbars which mean less maintenance cause single toolbar share most stuff wirh standard toolbar.
(In reply to Heiko Tietze from comment #10) > Given we get customization, a11y, integration of extensions etc. for > the NB Will this ever happen? That's a *lot* of work, and we don't have any single dev working on it right now. And given the way the current NB are implemented with glade .ui files, which don't have strict rules but instead have the freedom of putting different containers, controls etc., it will be very hard to impossible to implement customization. Also you said in the past (Bug 122799, Bug 123171) that you're against customization for the NB at all, so now you changed your mind?
(In reply to Maxim Monastirsky from comment #12) > So now you changed your mind? Well, I raise the question :-). From the user perspective your patch is great and nobody cares if it's based on ui (MUFFIN) or xml (clssic TB). But code-wise we run double-tracked with downsize on support. There will always be some differences, tiny maybe like the separation of sections or the way of overflow handling, that lead to a different look and feel. We can either try to converge or make a clear distinction. An example: bug 87040 or bug 119707 request for a mini toolbar like graphical context menu. Would that be MUFFIN or classic TB?
(In reply to Heiko Tietze from comment #13) OK, understood. I just want to clarify that I support the idea of replacing the original single mode toolbar with the new contextual single, regardless of whether it supports customization or not, and regardless of the way it's implemented, be it a classic TB or a NB. With my patch I just tried to find a quick solution for the immediate loss of customization for those who do care about it. The original single mode toolbar pretends to be a single-line UI solution, but in fact it's not, as it still depends on other contextual toolbars to appear. I don't think that users who want a single-line solution are happy with something like this. Worse, the popping contextual toolbar make the UI jumping, as noted in Bug 124835, which is unacceptable by any mean. In addition, the current single mode toolbar is static, and it has controls for the text context (font name, size, alignment etc.). The result is that those controls stay on screen even when they're not applicable (e.g when a shape is selected), taking an expensive screen space. Worse, when you double click on a shape to type text, a shape text contextual toolbar appear, making the text controls appear twice on screen! So whatever we decide wrt implementation, I still support removing the original single mode toolbar.
Maxim please give the single toolbar xml some love. For this layout it's the best decision from dev and design point of view.
To summarize, the idea of realizing the single line toolbar with the notebookbar is welcome. And there was also some agreement on Maxim's idea of attaching the contextual items to another toolbar (should be Standard). Could be handled in two separate bugs. Removing UX.
*** Bug 125787 has been marked as a duplicate of this bug. ***
contextual single toolbar is available in LibO 6.3 and customization (visibility true/false) will come with LibO 6.4. As standard single toolbar can be more powerfull than NB in general (more flexible) I will keep this bug open, but in general contextual single NB is how single toolbar should work. As they are very similar from a user perspective there is no difference (excluding customization and extension support).
(In reply to andreas_k from comment #18) > I will keep this bug open... The task is now to remove the classic single toolbar, if we all agree.
(In reply to Heiko Tietze from comment #19) > The task is now to remove the classic single toolbar, if we all agree. +1 as single toolbar didn't work as single toolbar and it's not userfull to have twice layouts with the same target. If classic single toolbar become the same features than contextual single, than I will kill contextual single.
Yes, if we can finish up the GSOC 2019 work by Sumit, then hanging a Single Mode off the NB Single is minimally functional. Customization of NB in general needs to be implemented in the Customize dialog. Bigger issue in doing this is accessibility (a11y) as for bug 107316 bcz the NB remains unsupported by accelerators, shortcuts and assigning "accessible events" to each button widget.
While the general approach we'd like to take (wrt glade vs xml) isn't yet clear, I decided to take some time to finish my patch (from comment 7), so a specific implementation could be discussed rather than general thoughts. You can likely expect something useful uploaded to gerrit in a few days.
This is how the notebookbar was implemented within cool. https://github.com/CollaboraOnline/online/blob/master/browser/src/control/Control.NotebookbarWriter.js In general it's way simplier, but sure there is some way for improvement see https://github.com/CollaboraOnline/online/issues/1257 I like the simple structure of xml which was used for toolbars. There are most stuff already available. For conxtual and tabbed simple it would be not to complicate to switch to .xml the issue is that the general notebookbar layout isn't possible with .xml only. About the show/hide stuff. On mobile there is s button to swipe the toolbar which would be also fine for desktop I think. Than we can remove all this resizing code.
Initial effort to make the single mode toolbar context aware is submitted: https://gerrit.libreoffice.org/c/core/+/135492/ https://gerrit.libreoffice.org/c/core/+/135591/ This is just the infrastructure; It doesn't include any context .xml files (should be singlemode-<context-name-in-lower-case>.xml), nor singlemode.xml was modified to remove text commands. I hope to get feedback on whether anything like this is of any use. And note that it's still a regular toolbar, so it works also outside of the "Single Mode" UI. (For example, one might replace some contextual toolbars with it, but keep some other contextual toolbars.)
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/881774e9e35055cbaed36324542bae006eedb4fb Related: tdf#125040 NB: rework print preview context It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Maxim Monastirsky from comment #24) > I hope to get feedback on whether anything like this is of any use. The appreciation of the idea has not changed as far as I read the thread. Guess you get feedback (and kudos) once the UI has changed.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9bc1ffa2153d2474b023e0860d3c9c68ee18727b tdf#125040 Make single mode toolbar context aware It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/48ca2336251d62ac2e90300cd9945fb84b1cddd8 tdf#125040 Avoid flickering on context change It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0930096c4c5ed14f46a79f03b29f21cc915d7203 tdf#125040 Recreate Contextual Single for Writer It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/230a988c9011ffc365070acf9ecd750825b0b1ec tdf#125040 Ignore the default context It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Since the Single Toolbar UI has been replaced by Contextual Single to provide some level of customization ability so can someone confirm the following: 1. It's safe to assume that the old Contextual Single can be removed? 1. Which naming to use for this UI? Stick to Single Toolbar or Contextual Single? This will affect the placement of options in .uno:ToolbarModeUI and of course documentation @Maxim may be you could provide some code pointer for removal and also (if needed) for naming.
(In reply to Rizal Muttaqin from comment #31) > 1. It's safe to assume that the old Contextual Single can be removed? Not yet: 1. Currently only Writer has the new implementation, while Impress/Draw weren't converted yet. (Calc doesn't even have the contextual single UI to begin with - Bug 142653.) 2. Various color buttons have the problem of storing the last used color separately in each button instance, which makes the color reset each time one switches the context. This bug isn't new (reported in e.g. Bug 113433, Bug 122003 and a lot more tickets in different variations), but it becomes more visible with the new implementation. One might argue that this is a regression compared to the old Contextual Single, and we probably should attempt to fix that before making the switch. 3. Just removing the old implementation isn't enough. We need also to migrate existing users to the new implementation, as otherwise they will end up with a broken UI after upgrade. > > 1. Which naming to use for this UI? Stick to Single Toolbar or Contextual > Single? I think that "Contextual" Single was named like that to differentiate it from the "Simple" Single. As soon as we have just one single line layout, we can just call it "Single Toolbar".