In libo there are different general layout options like - standard - single line - sidebar Single line and sidebar has one toolbar in difference to standard toolbar, but when you select an image, ole object, ... there popup the second context related toolbar. This is good for standard toolbar where you have always two toolbars, but in sidebar mode the context related options are available in the sidebar so there is no need to show the toolbar also. In single line toolbar the user say she/he wants one line. Now the single line toolbar is like in context-all you get one toolbar and everywhere else it has the same behavior than standard toolbar. When you have ordinary one toolbar and at context related items two, the ui jump AND the context, the user document, the zoom level, ... this is an worse behavior nobody wants and the user define themself. I will use the sidebar, or I have space for one line.
Valid observation, but not clear this needs any fix. The MUFFIN Notebookbar does hold app frame steady for the Tabbed and Groupedbar Compact modes, while the Single and Sidebar modes still correctly respond with contextual toolbars for those objects that require them. Contextual toolbars for those modes still seems appropriate--there is no alternative. One solution might be that context activated toolbars for the Single and Sidebar modes are placed onto a dynamic deck in the Sidebar--just wrap the action buttons onto a content panel? Very MUFFIN!
We should make the standard layout as best as possible and not introduce special treatments for the various MUFFINs.
(In reply to Heiko Tietze from comment #2) > We should make the standard layout as best as possible and not introduce > special treatments for the various MUFFINs. OK. But any reason we could not push toolbars onto the Sidebar as a new Toolbar deck? When needed for context--rather than a popup toolbar (shifting UI eleemnts)--buttons of the toolbar would wrap into a content panel. With some suitable handling of splitbutton actions. Back to the "dynamic" nature of the Sidebar GUI--as in bug 33223
> Back to the "dynamic" nature of the Sidebar GUI--as in bug 33223 bug 33223#c23
(In reply to V Stuart Foote from comment #4) > > Back to the "dynamic" nature of the Sidebar GUI--as in bug 33223 > bug 33223#c23 Rats, wrong cmnt in bug 33223, what I wanted was #c16 for Maxim's note about ability to hold toolbars in content panels, and to allow their customization.
> One solution might be that context activated toolbars for the Single and > Sidebar modes are placed onto a dynamic deck in the Sidebar--just wrap the > action buttons onto a content panel? All I want to say is that there is no strategy like in the Standard Toolbar where you have one Standard Toolbar line and the second Toolbar is contextual. If you have Single line Toolbar you may define one area that is always the same and than contextual. Sidebar Layout is for me easier. All contextual stuff is in the sidebar and in the single toolbar line there are some generic stuff.
and single line toolbar and sidebar don't have any connection to notebookbar.
(In reply to andreas_k from comment #7) > and single line toolbar and sidebar don't have any connection to notebookbar. Sure they do, they're all MUFFIN (Glade XML as opposed to .src) Just some elements arrived earlier than others... the NB flavors just the latest. Some old (2015) discussion... https://smehrbrodt.wordpress.com/2015/11/24/improving-the-toolbars-in-libreoffice/ and see bug 92218, bug 101249, bug 106470 for how things evolved.
@Maxim, Samuel -- any thoughts on comment 3, idea of pushing toolbars activated as context onto a Sidebar content panel? User choice to Pop-up toolbars as now but provide option for context activated toolbar's buttons to show in Sidebar. Goal of holding the GUI and document zoom stable.
Created attachment 150961 [details] Single Line Toolbar - contextual attached the single line tollbar layout at text context and graphic context. You see the behaviour is complete different. from my point of view there is an guide for sidebar toolbar layout and single line toolbar layout that should be followed.
Single Line Toolbar layout ========================== - user want's only one toolbar (cause otherwise they use standard toolbar) - "standard" toolbar AND contextual toolbars has to fit into one toolbar, cause there is no sidebar activated where contextual stuff is located. - as everything is more compact than in standard toolbar you need separate contextual .xml files. - Everything can be done with notebookbar, but I prefer .xml files cause they are way more easy to maintain. ========================== -> make an separate toolbar folder for single line toolbar than you can edit all contextual toolbars complete separate from standard toolbar layout Sidebar Toolbar layout ====================== - Sidebar is activated as all contextual stuff is available via the sidebar (and most of the time the sidebar is better, has more space, than an toolbar), no contextual toolbar is needed - One standard toolbar for general stuff ========================== -> deactivate all contextual toolbars show only standard toolbar
(In reply to V Stuart Foote from comment #3) > Back to the "dynamic" nature of the Sidebar GUI--as in bug 33223 That's one solution, okay as a generic approach. (The unclear UI layout feels bad but there is no clear showstopper that comes in my mind.) (In reply to andreas_k from comment #11) > - user want's only one toolbar (because otherwise they use standard toolbar) > - "standard" toolbar AND contextual toolbars has to fit into one toolbar, This solution is the closest to the idea of single toolbars. (In reply to andreas_k from comment #11) > - Everything can be done with notebookbar... Yes, and we remove the single toolbar. Initial effort might be a bit higher but the maintenance later is the same. My preferred solution. (In reply to andreas_k from comment #11) > Sidebar Toolbar layout > ... > -> deactivate all contextual toolbars show only standard toolbar The sidebar is a different topic. Unless we go the 'sidebar as toolbar container' way.
Ok than l will do an single line notebookbar to replace the single line toolbar. For the sidebar layout which contextual item isnt available in the sidebar? I really like to bring all layouts in an good shape.
(In reply to andreas_k from comment #13) > Ok than l will do an single line notebookbar to replace the single line > toolbar. > Don't know that we need to replace the Single toolbar mode that Jay did with a Notebook bar--but it might be another MUFFIN to provide. > For the sidebar layout which contextual item isnt available in the sidebar? > I really like to bring all layouts in an good shape. No, if we are to adopt Single toolbar mode with a Sidebar deck to hold any context sensitive toolbars--they would need to go into a Content panel holding just the controls for the Toolbar as customized by user. We could not use an exiting Content panel--widgets positioned to different panels would be horrible UX. Rather, think here the Deck would contain the elements of what would otherwise pop-up in the activated context sensitive toolbar--but packed into a Content panel. Perhaps with a Tab bar button widget to toggle the behavior: 1.) show context sensitive Toolbar(s) as Toolbar, 2.) show context sensitive Toolbar(s) packed onto a Sidebar content panel (maintain use customizations of selection and sequence) when activated.
(In reply to V Stuart Foote from comment #9) > @Maxim, Samuel -- any thoughts on comment 3, idea of pushing toolbars > activated as context onto a Sidebar content panel? Sorry, but I don't like this idea. IMHO everything which is in the sidebar by default, should be done in a "sidebar way" - meaning having dedicated and carefully designed panels/decks. The sidebar already deals with context-related stuff in its "Properties" deck - that what it was designed for, with panels for text, images, shapes etc. And likewise there should be panels for all other contexts (e.g. tables in Writer), not just as a generic "toolbar inside a sidebar container" kind solution. And bug 33223 is unrelated, because it talks about some customization possibility, while here we talk about the default sidebar behavior wrt contextual commands. So I agree with Andreas that the sidebar mode should consist of a standard toolbar (which also server as a place for customization, as the sidebar itself isn't and won't be customizable to the level of toolbars) + the sidebar, and no other context toolbars popping ever.
+1 for maxim. There is context related stuff missing in sidebars this should be added to the sidebar. + one standard toolbar with context related stuff as long as the settings are not available in the sidebar like alignment, ...
Can someone give an example how to make new sidebar docks and add them or first steh how to make them.
(In reply to andreas_k from comment #17) > Can someone give an example how to make new sidebar docks and add them or > first steh how to make them. See bug 91806 and unit test commits for our fledgling Sidebar controller API [1] Also, Andre Fischer (IBM) had laid out in Wiki programming details for developing against the Sidebar Deck/Content panels, including example toy panel widgets [2] And, some comment on using implementing Macro based sidebar content (requiring an UNO helper) in AOO Forum [3] @Tomaž, anything to add to help Andreas, not aware of anything written up internally for LibreOffice... =-refs-= [1] https://gerrit.libreoffice.org/#/c/16180/ [2] https://wiki.openoffice.org/wiki/Sidebar_for_Developers [3] https://forum.openoffice.org/en/forum/viewtopic.php?f=47&t=62176
I don't see any benefit in moving contextual toolbars into sidebar tabs for users who don't use the sidebar during normal use. Popping sidebar vs. popping toolbar -- what's better? Personal note 1: I move contextual toolbars into the bottom of the LibO UI so that the content won't move up and down. Personal note 2: I'm one of the 'old users' who like toolbars and use not only 1 (single toolbar) what is a castration of the power of toolbars for me. So, moving contextual toolbars to other parts of the LibO UI are no good solution for such users.
(In reply to Thomas Lendo from comment #19) > I don't see any benefit in moving contextual toolbars into sidebar tabs for > users who don't use the sidebar during normal use. Popping sidebar vs. > popping toolbar -- what's better? Thomas: The discussion here was about users who *explicitly* enable the sidebar mode via View > UI > Sidebar, not about the "Standard Toolbar" mode. > Personal note 1: I move contextual toolbars into the bottom of the LibO UI > so that the content won't move up and down. That won't help. At least in Impress/Draw the zoom changes anyway.
(In reply to Maxim Monastirsky from comment #20) > (In reply to Thomas Lendo from comment #19) > > I don't see any benefit in moving contextual toolbars into sidebar tabs for > > users who don't use the sidebar during normal use. Popping sidebar vs. > > popping toolbar -- what's better? > Thomas: The discussion here was about users who *explicitly* enable the > sidebar mode via View > UI > Sidebar, not about the "Standard Toolbar" mode. Argh sorry, I should have read it more carefully. I'm with you in comment 15 and Andreas in its initial idea and comment 6.
We discussed the topic in the design meeting. The majority welcomes Maxim's solution that brings more flexibility to the classic toolbar. Users likely don't care about the underlying technology and developers did not complain. So please go ahead.
Yes please work on it maxim.
*** Bug 125816 has been marked as a duplicate of this bug. ***
Is there some progress maxim?
*** Bug 138188 has been marked as a duplicate of this bug. ***
*** Bug 149282 has been marked as a duplicate of this bug. ***
(In reply to sdc.blanco from comment #27) > *** Bug 149282 has been marked as a duplicate of this bug. *** Have I DUP'ed bug 149282 to the right place? I focused on the summary (which does not mention Sidebar), while the discussion here seems directed to that focus. With "standard" layout contextual toolbar DOCKED: no jump in document canvas contextual toolbar UNDOCKED: (significant) jump (especially irritating when selecting images, frames, drawing objects, OLE objects prior to right-click, or leaving these objects to enter text.) Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 09822cf77cdbe32b03553cd05154100b5f2591d0
(In reply to sdc.blanco from comment #28) > Have I DUP'ed bug 149282 to the right place? Jumping UIs is a PITA since the first time. Some alternatives were discussed (eg. moving the TB content into the sidebar, or the HUD solution), and the NB (and probably the Ribbon) was introduced to deal with the problem. This ticket focuses on the "Sidebar" mode but I don't see what the proposed solution of a Standard TB as a placeholder for contextual content means. The sidebar mode has a Standard TB - maybe it means some space that is empty without context. We have bug 135501 (and other) challenging the large number of UI variants and bug 149230 that contradicts the DF focused standard toolbar / sidebar UI concept.
(In reply to Heiko Tietze from comment #29) > (In reply to sdc.blanco from comment #28) > > Have I DUP'ed bug 149282 to the right place? > This ticket focuses on the "Sidebar" mode but I don't see what the proposed > solution of a Standard TB as a placeholder for contextual content means. The > sidebar mode has a Standard TB - maybe it means some space that is empty > without context. Then maybe I should unDUP my ticket? As noted in comment 28, the problem arises only when toolbars are undocked. A placeholder maybe "solve" the problem, but loses the "undocked" toolbar, no? Meanwhile, the canvas remains stable when a popup dialog box appears. Is it because it takes the "focus"? (in effect locking the canvas?), while an undocked toolbar must not lock the canvas, hence the jump? But -- as a genuine naive question -- it is hard to understand why such a behavior (an undocked toolbar popping up) cannot be fixed in relation to the Standard TB inferface. If that is a legitimate request (and distinct from this ticket), then maybe I should unDUP, because my ticket was meant only to be aimed at the expected behavior of the Standard interface, not to make new or alternative designs.
Speaking of the UI jumping problem in general, the solution is likely always to have all context depending controls appear in the same place, and not in 10 different toolbars. It can be a tabbed UI, or a single toolbar with the context controls appended to its end (i.e. Contextual Single), or a regular two toolbars layout, with the second toolbar being a "context toolbar", that changes its controls based on the context (like in e.g. Inkscape), or a sidebar mode where context controls are in the sidebar. It doesn't matter. The key is to have only one context-aware area.
*** Bug 157866 has been marked as a duplicate of this bug. ***
(author of bug 157866) The way this bug seems to stand right now, the title seems to be more general. I'm reading about all sorts of suggestions that involve: * using another UI mode * placing contextual controls in the sidebar * new/weird docking for contextual controls etc. Personally, I don't (think I) like any of these options; although maybe I'm not fully following all suggestions. Mock-ups or other illustrations of what's currently on the agenda would be appreciated. Anyway, I filed bug 157866 so that the content doesn't jump around when the contextual UI appears; followers of this bug are kindly requested to also give some thought to that issue, independently of this one.
Let me relate more specifically to some of the commands in the discussion so far: Different UI modes: This bug needs a resolution valid for each of the global UI modes. One should not think of advising users to switch UI modes to avoid "jumpy" UI (nor jump content). Some people want their ribbons (= NB, Tabbed UI); some people hate ribbons and want their multiple menus; etc. They should not need to switch. The sidebar: (In reply to Thomas Lendo from comment #19) > I don't see any benefit in moving contextual toolbars into sidebar tabs for > users who don't use the sidebar during normal use. Popping sidebar vs. > popping toolbar -- what's better? There is at least one possible answer: Toolbars would pop in and out, as you go in and out of various contexts - but the sidebar will just pop out once, and will stay visible unless the user manually push it out. Thus LO would be pressuring you to accept the sidebar being open while you're doing a certain kind of work. MSO does this (especially noticeable to me in Excel with PivotTables and with chart element properties.) Duplicates: I believe we should undup the bugs about the canvas / document content moving or being scaled with automatic UI changes like toolbar popup - and re-dup them to each other, marking them only related to this one. What say you? * Miscellany > Personal note 2: I'm one of the 'old users' who like toolbars and I would argue most users prefer the toolbar interface; and that almost all users would prefer if the choice followed a fair try-out of each UI mode for a few months. But see prolonged discussion in bug 135501.