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.
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).
Yes i was mistaken. :D
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.
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
(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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
*** This bug has been marked as a duplicate of bug 82438 ***