Bug 106846 - CONFIGURATION: Means to enable and disable context-sensitive ability of toolbars
Summary: CONFIGURATION: Means to enable and disable context-sensitive ability of toolbars
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval, topicUI
: 107851 (view as bug list)
Depends on:
Blocks: Customise-Dialog Toolbars Writer-Toolbar-Formatting-Styles Style-Formatting-Writer-Toolbar 137760
  Show dependency treegraph
 
Reported: 2017-03-29 09:23 UTC by Thomas Lendo
Modified: 2024-01-08 09:10 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
Dialog for contextual visibility of toolbars (30.99 KB, image/png)
2017-03-29 09:25 UTC, Thomas Lendo
Details
contextual field in customization dialog (54.23 KB, image/png)
2017-04-25 14:55 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Lendo 2017-03-29 09:23:49 UTC
This feature request relates to all forms of customized toolbars, Notebookbars, sidebar panels ... I will describe it using the example of toolbars.

- Writing text, the Formatting toolbar is shown.
- Clicking on a frame, the Formatting toolbar is replaced by the Frame toolbar.
- Clicking on a picture, the Formatting toolbar is replaced by the Frame and Image toolbars.

- But if you're using a separate, new, customized toolbar e.g. for text formatting then this toolbar won't be replaced by the Frame toolbar when clicking on a frame and back when clicking in a text. -- The new text toolbar and the Image toolbar will both be shown when clicking on a picture.

Not in every case you can customize the Formatting toolbar to fulfill his/her needs, e.g. with toolbars of extensions. Or in many good UI customization instructions it's preferred to make a own place for user needs instead of changing default configuration. Or it should be possible to switch between default Formatting toolbar and customized formatting toolbar, e.g. in company environments with different needs.


Suggestion:

In a bar customization dialog it should be possible to anchor a bar (like context menus) to one or more specific objects. Choices (derived from the contest menu customization dialog): comment, form control, image, media, OLE object, print preview, shape, table, text, text frame.

A custom text formatting toolbar isn't necessary in the print preview, a custom image toolbar isn't necessary for texts.

Default bars shouldn't be editable so that users can't destroy anything.
Comment 1 Thomas Lendo 2017-03-29 09:25:40 UTC
Created attachment 132247 [details]
Dialog for contextual visibility of toolbars
Comment 2 V Stuart Foote 2017-03-29 12:27:01 UTC
See implementation of this as a useful, and probably necessary, control framework to support MUFFIN--but implementation correctly across the GUI would require a lot of refactoring.

IIUC existing contextual controls are not as modular as they would need to be to unify the behavior.

Design and UX aside, need some sense from devs as to scope/feasibility of the enhancement.
Comment 3 Heiko Tietze 2017-03-30 13:42:43 UTC
At least it's not UNCO.
Comment 4 Yousuf Philips (jay) (retired) 2017-04-25 14:41:06 UTC
(In reply to Thomas Lendo from comment #1)
> Created attachment 132247 [details]
> Dialog for contextual visibility of toolbars

Nice idea but unfortunately it wont be able to do what is needed.

Similar to setting the style of a toolbar, we need to be able to set the contextual nature of a toolbar. The contextual object types can be grabbed from here[1] and here[2] are their string equivalents. They will be presented in a drop down menu list and will alter the behaviour of the ContextSensitive[3] attribute of toolbars when its set to anything other than the first entry - 'No'.

@Maxim, @mkara: Wasnt able to find anything in the code to tie the contextual behaviour of existing toolbars with the EnumContext values, as that would be the key part to make this issue work. Any thoughts?

[1] http://opengrok.libreoffice.org/xref/core/include/vcl/EnumContext.hxx#64
[2] http://opengrok.libreoffice.org/xref/core/vcl/source/window/EnumContext.cxx#156
[3] http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/UI/WriterWindowState.xcu#142
Comment 5 Yousuf Philips (jay) (retired) 2017-04-25 14:55:29 UTC
Created attachment 132833 [details]
contextual field in customization dialog
Comment 6 Maxim Monastirsky 2017-04-25 21:39:38 UTC
(In reply to Yousuf Philips (jay) from comment #4)
> The contextual object types can be grabbed
> from here[1] and here[2] are their string equivalents. They will be
> presented in a drop down menu list
We also need to map contexts to applications, so e.g. pivot table context won't show in the list if opened from Writer.

> @Maxim, @mkara: Wasnt able to find anything in the code to tie the
> contextual behaviour of existing toolbars with the EnumContext values
There is no such code. Current handling of context toolbars predates EnumContext.
Comment 7 Yousuf Philips (jay) (retired) 2017-05-15 11:50:31 UTC
*** Bug 107851 has been marked as a duplicate of this bug. ***
Comment 8 Thomas Lendo 2017-05-17 21:39:04 UTC
(In reply to Yousuf Philips (jay) from comment #5)
> Created attachment 132833 [details]
> contextual field in customization dialog
How can toolbars assigned to more than one object in a drop down list, e.g. a single toolbar for frames and images?
Comment 9 Yousuf Philips (jay) (retired) 2017-05-18 08:24:17 UTC
(In reply to Thomas Lendo from comment #8)
> How can toolbars assigned to more than one object in a drop down list, e.g.
> a single toolbar for frames and images?

Yes it wouldnt be possible to have a single toolbar be used for multiple contexts in a drop down list, but ideally we should only have a single toolbar appear per context rather than 2 toolbars appear for a single context (e.g. bug 87362). One solution would be to have drop down list entries that had multiple contexts in it, e.g. 'frame, image, ole-object'.
Comment 10 Buovjaga 2018-10-13 14:21:46 UTC
Didn't have time to read everything, how is this different from bug 36976?
Comment 11 V Stuart Foote 2018-10-13 16:36:07 UTC
(In reply to Buovjaga from comment #10)
> Didn't have time to read everything, how is this different from bug 36976?

They are the same, but this has more substantive dev analysis of the issue(s), a bit of QA cleanup to dupe the older 36976 and friends to here... or not?
Comment 12 Thomas Lendo 2018-10-13 17:53:43 UTC
Hm, I thought this bug is about asigning a toolbar to any contextual behavior. The other one is to have the ability to stop/start the 'popping-up' of a contextual toolbar (but it should still be assigned to a special object).
Comment 13 V Stuart Foote 2019-06-08 13:57:22 UTC
*** Bug 125787 has been marked as a duplicate of this bug. ***
Comment 14 V Stuart Foote 2019-06-09 23:02:28 UTC
*** Bug 125816 has been marked as a duplicate of this bug. ***
Comment 15 V Stuart Foote 2019-09-18 12:09:33 UTC
*** Bug 127039 has been marked as a duplicate of this bug. ***
Comment 16 Eyal Rozenberg 2020-11-12 20:28:14 UTC
*** Bug 137760 has been marked as a duplicate of this bug. ***
Comment 17 Eyal Rozenberg 2020-11-12 20:38:27 UTC
While this feature in itself may be an enhancement, either this or another arrangement is significant in resolving a highly-annoying problem. Let me explain why (by repeating a point from my not-quite-dupe bug 137760):

An addition of a toolbar to the toolbar area resizes the viewport, and makes object in the viewport move. This is distracting when you're working on an object, e.g. a box in Impress, and you press it, expecting to type some text in - only for it to move away from where you pressed. You get the opposite effect when you click some other object - naturally only expecting it to become selected, not to move.

This phenomenon is doubly annoying if the viewport size change also affects the zoom level - which it might; and it is triply annoying if you have a "heavy" document, with numerous objects, as LO Impress or Draw often slow down significantly in the presence of these, and the redraws due to the viewport size change then take a long time.
Comment 18 V Stuart Foote 2021-06-07 17:40:25 UTC
*** Bug 137760 has been marked as a duplicate of this bug. ***
Comment 19 Eyal Rozenberg 2021-06-07 19:24:13 UTC
As per my last comment, and with my blocked bug marked as a dupe of this one - marking this one as a normal-severity _bug_ rather than an enhancement.
Comment 20 V Stuart Foote 2021-06-07 19:42:22 UTC
How is this a bug? The view port shift is annoying--but the docked TBs opening contextually is exactly as the UI is implemented.  

You could set them docked and always showing--but you'd loose a lot of screen space. You could set them floating, but they'll pop-open over content you probably want to see. You can use the Sidebar UI which is contextual. You can use the Contextual Single UI whcih limits the context portion to a single fixed location. And I'll say now--those aren't "workarounds" they are what is implemented.

What you can not do is disable the context sensitivity of the controls--that is the enhancement and even then it won't eliminate the viewport shift of exposing  a docked TB.
Comment 21 Eyal Rozenberg 2021-06-08 22:17:56 UTC
(In reply to V Stuart Foote from comment #20)
> How is this a bug? The view port shift is annoying--but the docked TBs
> opening contextually is exactly as the UI is implemented.  

It is a bug in the design, not in the implementation.

> You could set them docked and always showing

No, I couldn't. If I set, say, the Table toolbar to be visible and docked in Impress, then click a table cell, then "leave" the table by clicking some other element - the Table toolbar disappears.

Arguably, _that_ might be considered a bug in the implementation, but I'm not sure whether it's intended or unintended behavior.

> You can use the Contextual Single UI which limits the context portion to a
> single fixed location. 

1. That doesn't help - the toolbars appear and disappear in that UI mode as well.
2. That doesn't help - because even if the appearance/disappearance had not manifested in Contextual Single UI mode - it is a whole other kettle of fish which many users dislike for various reasons. One UI mode is no panacea for issues with another UI mode, especially the default one.
Comment 22 Buovjaga 2021-06-09 05:03:51 UTC
(In reply to Eyal Rozenberg from comment #21)
> (In reply to V Stuart Foote from comment #20)
> > How is this a bug? The view port shift is annoying--but the docked TBs
> > opening contextually is exactly as the UI is implemented.  
> 
> It is a bug in the design, not in the implementation.

You can't just go moving the goalposts like this as it would mean losing a useful way of categorisation for no reason. This edit war stops now.
Comment 23 Eyal Rozenberg 2021-06-09 06:52:43 UTC
(In reply to Buovjaga from comment #22)
> You can't just go moving the goalposts like this 

No goalposts are being moved. Bugs on this site are occasionally about the design rather than the implementation, and I have never seen this custom contested before.

> as it would mean losing a useful way of categorisation for no reason.

If the categories are "change how things are intended to work" vs "make things work the way they were intended", then like I said - this is not a categorization effected by the Severity field.

An enhancement severity is used when "it would be better if", and other severities are used when there's something wrong with the existing state of affairs.

> This edit war stops now.

A "war" does not stop with someone making another "attack" and declaring it is the last. 

Generally, if you disagree with a good-faith edit, what should happen is an exchange of opinions and the reaching of an agreed state of the fields in question. If I was wrong in my edit, please convince me.

Specifically regarding severity - differences of opinion should be settled on the side of non-enhancement. The reason is that if current behavior is seen is inappropriate/unacceptable by some, and merely sub-optimal by others, then it typically is, indeed, inappropriate/unacceptable for some - and thus not just an enhancement.

I am suggesting somewhat of a compromise by marking the Severity as minor.
Comment 24 Telesto 2022-04-27 09:44:57 UTC
Most duplicates where asking for what's described in bug 38850, IMHO. What's being ask here (OP) appears to be different.