Bug 135110 - ENHANCEMENT: Right Click context menu in the style inspector to modify style
Summary: ENHANCEMENT: Right Click context menu in the style inspector to modify style
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Styles_Inspector
  Show dependency treegraph
 
Reported: 2020-07-24 17:11 UTC by Telesto
Modified: 2020-10-15 22:33 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-07-24 17:11:13 UTC
Description:
ENHANCEMENT: Right Click context menu in the style inspector to modify style

Steps to Reproduce:
1. Open a document with a heading paragraph style or anything other
2. Say I want to change that.. now I know which style it is, i still have to jump to the styles panel

Actual Results:
No way to access the style from Inspector panel

Expected Results:
Expected.. bit of an overstatement.. would make it easier..maybe?


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: <buildversion>
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2020-07-24 17:12:15 UTC Comment hidden (off-topic)
Comment 2 Mike Kaganski 2020-07-24 17:27:55 UTC
Absolutely.
Comment 3 Shivam Kumar Singh 2020-07-24 17:50:55 UTC
I disagree with the request.
This was a doubt i too had that whether the Inspector could allow changing of styles ,but i was instructed by my mentors by either through IRC or mail discussion that Inspector should only be able to show the properties and not change them.
Comment 4 Telesto 2020-07-24 18:40:13 UTC
(In reply to Shivam Kumar Singh from comment #3)
> I disagree with the request.
> This was a doubt i too had that whether the Inspector could allow changing
> of styles ,but i was instructed by my mentors by either through IRC or mail
> discussion that Inspector should only be able to show the properties and not
> change them.

Not sure how I should read this. The inspector should indeed not change anything. The idea of mine is a quick way to open the style dialog. So technically the Inspector changing nothing. 

Of course there still room for objection :-). However it's but unpractical to show the style name, switching to style tab & searching for the style name in question.. 

I assume Heiko is one of your mentors.. so we find out soon enough :-)
Comment 5 Heiko Tietze 2020-07-27 08:21:08 UTC
From the blog post: "Another source for discussion are interactions. For example, we could make it easy to delete style properties either with an icon that appears on hover or per context menu. But this sounds a bit dangerous as users may execute the function unintentionally, and is actually not part of the workflow. So it might be better to restrict the functionality and access the property dialog with the current selection or open the styles and formatting sidebar respectively."
(With deletion I had attributes in mind not complete styles, for example you remove CharColor from directly formatted text.)

I'm a bit split. On the one hand it sounds convenient to access PS/CS property dialogs. But it mixes two workflows. While editing a document you are supposed to apply styles from the dedicated deck (or via toolbar/menu/...).
Comment 6 Telesto 2020-07-27 09:17:40 UTC
(In reply to Heiko Tietze from comment #5)
> I'm a bit split. On the one hand it sounds convenient to access PS/CS
> property dialogs. But it mixes two workflows. While editing a document you
> are supposed to apply styles from the dedicated deck (or via
> toolbar/menu/...).

I do agree with this; based on type of functionality it shouldn't. OTOH; knowing the style might be a reason to change it.. which makes it rather practical :-)

A deck only showing information is kind of uncommon. And kind of frustrating. You know they style name.. know you have to go through multiple dialog to change it. 
I even consider being able to modify the 'style settings' directly in the Style Inspector instead of only listing those :-). OTOH it's called Inspector. And totally not the opposite of the the design.. But would be in line with a deck being productive. Only showing stuff is useful, but changing decks for it for example rather frustrating, IMHO.

However I'm also the one who want's they Navigator deck be a to way street.. So a clicked image being showing in the navigator ;-). So I can see the image name without going through all sorts of dialogs. So maybe it's me wanting odd stuff...
Comment 7 Telesto 2020-07-27 09:20:58 UTC
@Luke
Also an opinion on this?
Comment 8 Mike Kaganski 2020-07-27 09:31:34 UTC
Being able to call the same dialog from different UI places is very normal thing - especially when it's so much reasonable. I don't know which "workflow" Heiko has in mind when writes "But it mixes two workflows", because *the* workflow SI is dedicated for (inspecting and understanding why your text looks the way it does, naturally not for pure curiosity, but in attempt to fix something => to change the setting that makes it not match expectations => it's natural to want to change something when you see the source of the trouble); while I currently don't propose to be able to change individual positions, it's perfectly normal to expect double-click or context menu of a style or DF to allow opening relevant options dialog.
Comment 9 Heiko Tietze 2020-07-27 09:37:15 UTC
Okay, next question is the UI. Options:
a) make the style a (hyper)link
b) show a (icon-only) button next to the style (eg a gear)
c) access via context menu
d) double click

My take is c).
Comment 10 Mike Kaganski 2020-07-27 09:44:51 UTC
(In reply to Heiko Tietze from comment #9)

I would like c+d.
Comment 11 Mike Kaganski 2020-07-27 09:46:27 UTC
(In reply to Mike Kaganski from comment #10)
> (In reply to Heiko Tietze from comment #9)
> 
> I would like c+d.

But that would interfere with double-click collapsing/expanding subtrees -> no problem in limiting to c, or making it c+b. I don't think a makes sense - it would interfere with too much things.
Comment 12 Luke Kendall 2020-07-27 12:18:31 UTC
My opinion...
When the user sees a named style in the SI it would be expected and productive and reduce potential errors to be able to use that to call up the Paragraph or Character Style panel (etc) to let you make changes.
I think it would be very frustrating if you instead had to remember the name and navigate manually to its UI.
I feel 'c' option is essential; 'b' option greatly improves 'discoverability'.

Comment 3 seems to me a misunderstanding: it was just a way to call up the style panel quickly - not an attempt to make the inspector work like NeXTstep Inspectors (able to examine and change objects, a wonderful and elegant UX).

I fully agree with Mike in comment 8.

HTH
Comment 13 Heiko Tietze 2020-07-27 12:26:53 UTC
Enough input, let's do it.
Comment 14 Thomas Lendo 2020-10-14 20:53:06 UTC
When testing the Style Inspector, I permanently feel the urge to edit the values or to delete a single value. As other commenters mentioned, a tool that only shows something isn't that helpful.

I'm no fan of only linking values to the style dialog. Worst would be for me when the Style Inspector sidebar tab would be changed to another tab (e.g. Styles sidebar). This would break the workflow and the user has to go back to the Style Inspector manually.

Without the possibility of changing or deleting single values the Style Inspector is only a bloated variant of the Contains section in the Organizer tab of the style dialog. And this restriction of this Contains section has led to several bug reports here.
Comment 15 Mike Kaganski 2020-10-15 05:58:00 UTC
(In reply to Thomas Lendo from comment #14)
> Without the possibility of changing or deleting single values the Style
> Inspector is only a bloated variant of the Contains section in the Organizer
> tab of the style dialog. And this restriction of this Contains section has
> led to several bug reports here.

The "edit/delete single values" needs consideration. Because there are both DF and styles there; do you suggest to allow editing both? and the "single" entries there are sometimes parts of complex ones, so in UI, you modify several using a single control - are we going to allow really great flexibility of creating a UI to tweak those values independently - allowing "non-standard" combinations not possible with current UI, or are we going to create an involved logic that would limit the possible changes?

I feel that "all or nothing" is the worst attitude possible. We must implement the first - safe - step, then proceed to consideration/discussion of the next one, independently.
Comment 16 Mike Kaganski 2020-10-15 08:56:30 UTC
(In reply to Mike Kaganski from comment #15)
> The "edit/delete single values" needs consideration. Because there are both
> DF and styles there; do you suggest to allow editing both?

I want to elaborate on what makes me cautious about this specific aspect.

SI is a tool used in a place of current cursor. Its natural/intended use case is when someone inspects some place to understand why a visible result is produced. And it's reasonable to expect that user wants to "fix" something when the problem is identified.

But it is the focus on a specific place that makes it dangerous to allow editing individual parameters of styles here: user might be tempted to "tweak this little thing here", to get the wanted result, only to see (or not see!) that it broke the things elsewhere - because it was a *style* that was changed. Only allowing to open style dialog when changing style properties could emphasize that it's style that is being changed (so the change has document-wide consequences)...

So it all is not so simple as "give me that innocent-looking tool NOW!!!!". It all needs consideration.
Comment 17 Telesto 2020-10-15 13:02:54 UTC Comment hidden (off-topic)
Comment 18 Luke Kendall 2020-10-15 13:17:53 UTC Comment hidden (off-topic)
Comment 19 Mike Kaganski 2020-10-15 13:18:41 UTC Comment hidden (off-topic)
Comment 20 Mike Kaganski 2020-10-15 13:35:33 UTC
Just for clarification: the reason of comments 15 and 16 is Thomas's comment #14, which told:


> I'm no fan of only linking values to the style dialog.
> ...
> Without the possibility of changing or deleting single values the Style
> Inspector is only a bloated variant of the Contains section in the Organizer
> tab of the style dialog. And this restriction of this Contains section has
> led to several bug reports here.

This comment was a direct response to the previous decisions - so it tried to make it "the decision to add access to style dialogs is *wrong*, and should be changed". It is like "all or nothing" approach: either we introduce single attribute editing, or we don't do anything.

Of course, that could be me misreading Thomas; but my comments were not meant to hurt anyone; they were meant to show that "all or nothing" approach is not good (even if that was only me thinking about "all or nothing").
Comment 21 Thomas Lendo 2020-10-15 22:33:54 UTC
(In reply to Mike Kaganski from comment #20)
Mike, I'm not hurt and I haven't read the comments in the way as others have done apparently. You're right that we all have different age, first language, education, culture ... and we should discuss as unemotional as possible. I'm no exception. -- Sometimes it seems to be hard to convince others from the own idea and to put that into the right words especially for people with non-English first language. That also causes some misunderstandings. -- This is no chat room but a board for discussing technical issues. We should make clear, _short_ and unemotional comments.