Bug Hunting Session
Bug 124835 - Contextual toolbars make UI jumping
Summary: Contextual toolbars make UI jumping
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 125816 (view as bug list)
Depends on:
Blocks: Toolbars
  Show dependency treegraph
 
Reported: 2019-04-19 05:33 UTC by andreas_k
Modified: 2019-09-18 12:56 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Single Line Toolbar - contextual (163.28 KB, image/png)
2019-04-23 19:43 UTC, andreas_k
Details

Note You need to log in before you can comment on or make changes to this bug.
Description andreas_k 2019-04-19 05:33:51 UTC
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.
Comment 1 V Stuart Foote 2019-04-19 13:34:59 UTC
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!
Comment 2 Heiko Tietze 2019-04-22 09:10:01 UTC
We should make the standard layout as best as possible and not introduce special treatments for the various MUFFINs.
Comment 3 V Stuart Foote 2019-04-22 13:19:54 UTC
(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
Comment 4 V Stuart Foote 2019-04-22 13:22:02 UTC
> Back to the "dynamic" nature of the Sidebar GUI--as in bug 33223
bug 33223#c23
Comment 5 V Stuart Foote 2019-04-22 13:26:13 UTC
(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.
Comment 6 andreas_k 2019-04-22 19:27:35 UTC
> 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.
Comment 7 andreas_k 2019-04-22 19:30:11 UTC
and single line toolbar and sidebar don't have any connection to notebookbar.
Comment 8 V Stuart Foote 2019-04-22 22:29:40 UTC
(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.
Comment 9 V Stuart Foote 2019-04-22 23:47:22 UTC
@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.
Comment 10 andreas_k 2019-04-23 19:43:15 UTC
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.
Comment 11 andreas_k 2019-04-23 19:50:33 UTC
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
Comment 12 Heiko Tietze 2019-04-24 07:37:36 UTC
(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.
Comment 13 andreas_k 2019-04-24 08:10:36 UTC
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.
Comment 14 V Stuart Foote 2019-04-24 13:25:41 UTC
(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.
Comment 15 Maxim Monastirsky 2019-05-01 13:51:32 UTC
(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.
Comment 16 andreas_k 2019-05-01 14:10:54 UTC
+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, ...
Comment 17 andreas_k 2019-05-01 14:49:51 UTC
Can someone give an example how to make new sidebar docks and add them or first steh how to make them.
Comment 18 V Stuart Foote 2019-05-01 17:27:50 UTC
(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
Comment 19 Thomas Lendo 2019-05-04 20:28:46 UTC
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.
Comment 20 Maxim Monastirsky 2019-05-04 22:47:27 UTC
(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.
Comment 21 Thomas Lendo 2019-05-05 12:21:10 UTC
(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.
Comment 22 Heiko Tietze 2019-05-09 13:27:03 UTC
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.
Comment 23 andreas_k 2019-05-09 13:48:48 UTC
Yes please work on it maxim.
Comment 24 V Stuart Foote 2019-06-10 05:04:29 UTC
*** Bug 125816 has been marked as a duplicate of this bug. ***
Comment 25 andreas_k 2019-07-16 21:33:12 UTC
Is there some progress maxim?