Bug 100604 - Should "Clear Direct Formatting" uno:ResetAttribute always be enabled?
Summary: Should "Clear Direct Formatting" uno:ResetAttribute always be enabled?
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Context-Menu
  Show dependency treegraph
 
Reported: 2016-06-25 16:47 UTC by sworddragon2
Modified: 2016-10-05 22:16 UTC (History)
6 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 sworddragon2 2016-06-25 16:47:17 UTC
On opening Writer and moving the cursor to any unformatted text the "Clear Direct Formatting" context menu entry and button in the symbol bar are not disabled.
Comment 1 Buovjaga 2016-06-25 19:45:10 UTC
Confirmed.

Was it different before?

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.0.0.alpha0+
Build ID: c13f60e7cd18df6b0ab70289f5b91ee01e4ae126
CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8)
Built on June 18th 2016
Comment 2 Cor Nouws 2016-06-25 20:17:48 UTC
(In reply to Buovjaga from comment #1)

> Was it different before?

nope...
Comment 3 m_a_riosv 2016-10-01 21:44:15 UTC

*** This bug has been marked as a duplicate of bug 86606 ***
Comment 4 V Stuart Foote 2016-10-02 15:44:23 UTC
(In reply to sworddragon2 from comment #0)
> On opening Writer and moving the cursor to any unformatted text the "Clear
> Direct Formatting" context menu entry and button in the symbol bar are not
> disabled.

Why would they be disabled? The UNO command uno:ResetAttributes remains active at all times. It is not implemented to be a selection driven activation, but shifts focus of its action to object that is selected.

Meaning that when cursor is present in the document canvas with no selection made--the cleared attribute would apply to the character the text cursor is sitting on, or the word containing it, or to the paragraph depending on the class of attribute being cleared.

And of course the UNO ResetAttributes used for the "Clear Direct formatting" entry in the context menu was removed at 5.2 (see bug 86606 and bug 81132 for ongoing work to reduce context menu emphasis on Direct Formatting).
Comment 5 Heiko Tietze 2016-10-02 20:25:35 UTC
(In reply to V Stuart Foote from comment #4)
> Why would they be disabled?

Would be a nice indicator if the object is formatted directly, not necessary but a nice to have. However, it sounds not that simple to implement.
Comment 6 Yousuf Philips (jay) (retired) 2016-10-03 21:26:33 UTC
As you can type some words in bold, click 'clear direct formatting' and then type words not in bold (which is the same for clicking italics, underline, etc.), there isnt a need for it to be disabled. For me this isnt a bug and agreed with stuart.
Comment 7 sworddragon2 2016-10-04 23:40:51 UTC
I have troubles to understand what comment #4 is pointing to or it makes not much sense - at least I can't evaluate its information now. Comment #5 has given a nice-to-have use-case for this enhancement. Having the need to modify something to figure this out (as I think comment #6 tries to imply) seems to be not right. Also WORKSFORME is the wrong solution for this ticket as it still doesn't work as requested. I'm changing back its state and changing the type of this ticket to an enhancement. If this feature is not wanted I think the solution should be set to WONTFIX or maybe INVALID instead.
Comment 8 V Stuart Foote 2016-10-04 23:57:25 UTC
Let me make it simple-- WONTFIX

There is no need at all to change the .uno:ResetAttributes behavior to implement a context aware sense.

The command as implemented works when called from Menu (Format -> Clear Direct Formatting), from its dedicated button on the Formatting Toolbar, and from its global short-cut (<Ctrl>+M). Any applicable direct formatting--based on internal logicl of the command--is cleared.

No reason to gum things up by trying to make its buttons context aware. 

The context menu entry for the command was removed at 5.2--but could be restored (bug 102915), no viable use case for making its representation on the Toolbar button or the context menu stateful--it is always enabled.
Comment 9 Octavio Alvarez 2016-10-05 00:41:46 UTC
(In reply to sworddragon2 from comment #7)
> I have troubles to understand what comment #4 is pointing to or it makes not
> much sense - at least I can't evaluate its information now.

I had trouble too, but let me try to explain.

1. In a new document hit Ctrl+U, type UNDERLINE, hit Ctrl+M, type UNFORMATTED, hit Ctrl+U and type UNDERLINE once again. No spaces, so you form one long word.

2. Place cursor between the double T without selecting any text.

Under your suggestion, the Clear DF actions should be disabled because it would do nothing and it would give visual feedback of the lack of DF. However, hitting Clear DF actually *does* something: it clears the whole word, just like Ctrl+U would underline the whole word.

This means that disabling Clear DF would currently existing functionality.

Although it sounds like a nice idea to have the button give feedback on whether the text is directly formatted or not, I consider it confusing to have it enabled when the cursor is at some unformatted part of the word but the button enables because other parts of a word have some DF.
Comment 10 sworddragon2 2016-10-05 22:16:35 UTC
I have now noticed that this ticket is reported against the Writer module while I have said in bug #86606 that I did still see this behavior in Calc. But I think that shouldn't matter much as I assume keeping "Clear Direct Formatting" always enabled is the wanted behavior then for every module.