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
So rather than the current "Single Mode" toolbar, or the current .UI for Contextual Single notebook bar--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! :-)
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.
*** 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.