Download it now!
Bug 91812 - text background sidebar button doesnt change the text background color in the toolbar
Summary: text background sidebar button doesnt change the text background color in the...
Status: RESOLVED DUPLICATE of bug 82438
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Split-Group-Buttons-Color
  Show dependency treegraph
 
Reported: 2015-06-02 13:38 UTC by Yousuf Philips (jay) (retired)
Modified: 2017-10-24 11:27 UTC (History)
2 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 Yousuf Philips (jay) (retired) 2015-06-02 13:38:58 UTC
With the text formatting toolbar active in Draw or Impress, if you set the text background color in the toolbar, it will not change the text background color found in the character section of the properties tab. Though setting it in the sidebar does change it in the toolbar.
Comment 1 Katarina Behrens (Inactive) 2015-06-02 16:36:00 UTC
For me it's the other way round: 

1) Changing colour from toolbar updates the icon in sidebar (sometimes w/ some delay, but it ultimately does)

2) Changing colour from sidebar doesn't update the icon in toolbar

Can anyone else confirm either of those behaviours? (you'd need a daily build for that).
Comment 2 Yousuf Philips (jay) (retired) 2015-06-03 03:13:59 UTC
Yes i was mistaken. :D
Comment 3 Katarina Behrens (Inactive) 2015-06-10 11:26:08 UTC
Maxim says:

Well, for me this is the desired result:

1. A simple button (i.e. with ToolBoxItemBits::DROPDOWNONLY bits) should show the current color of the selected text/object.

2. A split button (i.e. with ToolBoxItemBits::DROPDOWN bits) should initially show some common color, and later the last used one, for easy re-applying it on another text/object.

3. All buttons of the same kind (simple vs split), and that are representing the same text attribute, should be synced, and show the same color, regardless whether they are on the toolbar or on the sidebar.

This means that if we have .uno:Color on both the toolbar and the sidebar, and *both* are split buttons, they need to be synced - but with the last used color, not with the current one (i.e. if you move the cursor to a text with a different color, it shouldn't affect the button). That's why SvxColorToolBoxControl::StateChanged has the check for bSidebarType, so split buttons won't be updated with the current color, but keep the last used one. This bSidebarType is simply used for distinguish between simple and split buttons, allowing them to share the same code, it's just poorly named (because most of the buttons in the sidebar are simple buttons - except the ones from the text panel, and all the toolbar buttons are split ones).

Now, this scenario of syncing split buttons is not yet implemented (and already reported in tdf#82438). The problem is that the last used color is stored inside PaletteManager, and we have separate instance of it for each visible button. This causes also that the last used color resets after closing and re-opening the toolbar (because SvxColorToolboxControl instances are destroyed together with the toolbar) - see tdf#61868, tdf#71413, tdf#72991, tdf#83789.

One possible solution is to turn PaletteManager into a singleton, so we'll have only one instance, and could manage all visible buttons from there. That way we could also sync the "recent colors" palette between all visible pickers, and maybe also the currently chosen main palette. Right now each visible button has its own instance of all these settings. Even worse - right now each instance has its own list of all palettes and their colors, thus wasting resources. Such kind of things surely should be managed in a centralized way.
Comment 4 Katarina Behrens (Inactive) 2015-06-10 14:00:26 UTC
To summarize the above and how it was meant to be implemented:

* font and text background buttons in toolbar should be split buttons and should show last used colour
* font and text background buttons in sidebar should be simple buttons and should show the colour of font/background of currently selected object (which is not necessarily the last used one)

Please correct me if I'm wrong
Comment 5 Maxim Monastirsky 2015-06-10 14:26:50 UTC
(In reply to Katarina Behrens (CIB) from comment #4)
> To summarize the above and how it was meant to be implemented:
> 
> * font and text background buttons in toolbar should be split buttons and
> should show last used colour
> * font and text background buttons in sidebar should be simple buttons and
> should show the colour of font/background of currently selected object
> (which is not necessarily the last used one)
That's not what I meant. Sidebar buttons could be split buttons as well. What I said is:

1. A split button shouldn't be updated from the currently selected text - which is what the gerrit patch seems to break.

2. If there are several visible split buttons for the same attribute (for example - one on the toolbar and the other on the sidebar), would be great if all of them would be synced with the last selected color. I believe this is what this bug and Bug 82438 is about.
Comment 6 QA Administrators 2016-09-20 10:02:26 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2017-07-13 10:03:33 UTC
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
Comment 8 Maxim Monastirsky 2017-10-24 08:34:42 UTC

*** This bug has been marked as a duplicate of bug 82438 ***