[Libreoffice-ux-advise] [Bug 112852] Should unapplying Bold remove the attribute or force text to Regular?

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #6 from Octavio Alvarez <octallo at alvarezp.org> ---
Then I chose option (a) ;-) Out of kidding, option (a) is not a bad option
either and I am open to it if it makes it easier to understand. It's a sign
that it may be easier for other users too.

However, at risk of sounding too verbose, I think a clarification is in order:

My suggestion is [so far] strictly about *the application / un-application of
default formatting* because it clearly breaks the user expectation as currently
implemented. It has [so far] nothing to do with changing styles. Changing a
style is just the easiest way to expose the broken behavior. Another way is
through the paintbrush as DF plays a role on how it works:

1. New document.
2. Type "Plain" and hit Enter.
3. Type "ForcedRegular" and hit Enter.
4. Type "Heading 1", and hit Ctrl+1.
5. Hit Ctrl+B twice on "ForcedRegular"
6. Place cursor between "a" and "i" in "Plain". Hit Paintbrush. Hit the "a" in
"Heading". Nothing happens at all.
7. Place the cursor between "r" and "c" in "ForcedRegular". Hit Paintbrush. Hit
the "a" in "Heading". The word "Heading" turns regular.

This manifests in issues #112872. Some users think this inconsistent, some
think the Paintbrush does not properly work. I think it works but it has an
inconvenient algorithm. Please note: my suggestion won't fix the paintbrush, in
fact, my suggestion may even make the the paintbrush feel even more broken but
it will clear one of the most invisible variables that occur when editing
documents to give a more consistent UX. The paintbrush tool itself is broken
(hint: it should replace all formatting on the target, not just add DF,  with
the formatting of the source, including styles, but that's another story).

Also, think what happens when a user saves a document and sends it to somebody
else for modification. Invisible Direct Formatting can be all over the
document, with Writer being prone to be perceived as plain broken.

With this clarification, I understand your question as a proposal to *extend my
suggestion* in order to make it as congruent / compatible as possible with
other work flows in the program. I choose option (b) just because I can [so
far] only affirm brokenness about DF. This does not invalidate my suggestion,
only the proposed extensions, so we are back to my suggestion as originally
suggested:

When applying Direct Formatting, attributes that end up matching the underlying
styles [1] should be unset.

[1] By styles I mean the resulting style after calculating the style hierarchy.

However, I am also open to accept your proposed extension to apply this logic
when changing styles too. Your scenario sounds much more likely to occur by
mistake (as in "Oops, I applied the wrong style let's reapply the correct one")
but if this makes a user lose its DF, the user will always have Ctrl+Z, which
is much more well known and understood.

-- 
You are receiving this mail because:
You are on the CC list for the bug.