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 enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval, topicUI
: 107851 (view as bug list)
Depends on:
Blocks: Customize-Dialog Toolbars Writer-Toolbar-Formatting-Styles Style-Formatting-Writer-Toolbar
  Show dependency treegraph
 
Reported: 2017-03-29 09:23 UTC by Thomas Lendo
Modified: 2018-10-13 17:53 UTC (History)
6 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).