[Libreoffice-bugs] [Bug 135871] Highlighting no fill is not the same as no fill; there is still direct formatting present according to paragraph style

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=135871

--- Comment #29 from Telesto <telesto at surfxs.nl> ---
(In reply to Heiko Tietze from comment #28)
> (In reply to Telesto from comment #27)
> > new proposal (only brainstorming)...
> 
> Overloading the toolbar with unfamiliar tweaks might not solve the confusion
> fromn the beginning. It would be helpful for you (and I have to admit it's a
> tempting idea for me too) but Benjamin has no idea why the bold button
> becomes "stylish".
> But let's do a step more: How about a special deck that gives feedback why
> bold is set. Maybe with a tree to illustrate the hierarchical relation...


Benjamin doesn't touch styles, so everything will be the same for him :-). 

So we are already talking about users (Eve) who does use styles. And in the
current implementation it's hard to tell if something is a style (say bold by
CS Strong Emphasis) or bold DF. You can't see it except, sidebar is at CS
styles deck or with Style inspector. 

So bold having a 'stylish' indicator only shows with PS/CS with bold turned on.
And as far I'm cornered it's only a dot * in right corner of the bold button
(but not a designer).

If you toggle bold to unbold, DF is set overriding PS/CS. If you toggle unbold
to bold again DF is removed (which surely an improvement above the current
situation) and toggle button will show B*. The indicator is only an aid (it
does still work the same). Except if bold being disabled in PS/CS setting bold
DF is toggled; and removing it again when untoggled. Visa versa if BOLD being
enabled in PS/CS, the bold toggle we be active (with PS/CS indicator aid),
pressing it will unbold (with DF). Pressing it again and it's back to PS/CS
style (without DF)

The major change would be that when bold (DF) is reverted to unbold, they
'bold' DF gets removed, instead of being changed in an active unbold DF.

And the system pretty idiot proof. There is no change in behavior without
indicator. Is only an aid. So if Bold* appears, Benjamin might not know what it
means, but shows up right.

Benjamin can even mishmash Liberation Serif* and Liberation Serif (without
star) without consequences. Except if he starts formatting with PS/CS. At that
point he will notice that Liberation Serif is a manual DF style and Liberation
Serif* being automatic style.

The currently situation is worse. Say Liberation Serif is set. You change it to
Liberation Mono and back to Liberation Serif. This isn't Liberation serif* (so
PS style anymore). It's DF formatting looking like PS style, but without being
the case. And even worse, you can't 'return' to PS/CS except by CTRL+M
(removing all DF). So it makes for more easier to manage for people who do want
to work with styles.

The whole *thing would also by useful for bug 88559 or bug 136433. Those
dialogs suffer from the same problem.

So I'm not seeing any usability problem; I certainly don't want more decks :-).
CS being on a different deck compared to PS is already an issue :-). Even more
flip-flopping around. And doesn't solve the matter of ODT being riddled with
DF; nor solves it the 'styles setting problem'.

So this squeezes quite a number of issues. And matches even Thomas Lendo his
proposal. No-fill keeps being called no-fill (in both cases). And automatic
automatic.. So this in my perspective rather small low key 'tweak' in behavior
and rather natural.

Of course the DEV department must be able to implement this. However would love
Thomas his view :-)

However, in contrary of what I stated, there is a need for a no-fill
alternative for highlighting. Else you can't revert to inherited in the Page
Style dialog (in child parent relations) where the child has been changed.. and
someone wants to return to 'inherited from parent'.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200916/c6a9a65e/attachment-0001.htm>