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.
Was it different before?
Arch Linux 64-bit, KDE Plasma 5
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
(In reply to Buovjaga from comment #1)
> Was it different before?
*** This bug has been marked as a duplicate of bug 86606 ***
(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
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).
(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.
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.
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.
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.
(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.
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.