The font colour/color picker dropdown in Impress and Calc is a) defective and b)inconsistent with the same control in Writer (where the behaviour is as one would expect) - this is compounded by the lack of indication of the current colour choice in the dropdown grid. The behaviour should be as implemented in Writer, or better and the current colour should be clearly highlighted in the dropdown (I put these in the same bug report as I class the bug as a deficiency in the usability i.e. one problem, rather than two functional deficiencies) To recreate usable example behaviour. This works as described in Writer, anywhere on a page and in Calc, where the two words are contained in a single cell 1/ Open Writer/Calc and write two words, separated by a space on the Writer page or in a single Calc cell 2/ double click on the first word to select it 3/ press the drop down button for the toolbar colour picker tool and select a colour from the dropdown. This should change the selected text's colour to the colour selected. NB the currently selected colour is not marked or highlighted in any way in the dropdown grid 4/ double click on the second word to select it 4b/ the colour picker tool should still display the colour specified in step 3 despite the selection of different coloured text 5/ press the left half of the colour picker tool to apply the originally specified colour to the newly selected second word too. To recreate the unusable example behaviour. This works as described in Impress, even within the same text area and in Calc, where the two words are in different cells 1/ Open Impress/Calc and write two words, separated by a space in an Impress text area or in two cells in Calc 2/ double click on the first word to select it 3/ press the drop down button for the toolbar colour picker tool and select a colour from the dropdown. This should change the selected text's colour to the colour selected. NB the currently selected colour is not marked or highlighted in any way in the dropdown grid 4/ double click on the second word to select it 4b/ the colour picker tool will now change colour to match the colour of the selected text - this is the problem, in conjunction with the lack of highlighting of the current colour, that renders the Impress picker unusable. 5/ There is no way to re-apply a single colour to many text selections, without memorising which colour in the grid is to be used. I have found the same behaviour to be the case on my work laptop (K)ubuntu -Maverick and my home and work desktops, running SuSE 10.3 & 11.1, all with with LO 3.3.1 (as far as I recall - I'm away from work at the moment) I would like to see at least the following three use cases supported consistently Use Case 1 Actor: User of all OO component applications Goal:Set a text colour and apply it repeatedly to selected text Notes: Implementation behaviour should be the same in all OO applications Use Case 2 Actor: User of all OO component applications Goal:Select some text (that has a single colour applied) and use it as a model to apply it to other text Notes: Implementation behaviour should be the same in all OO applications Use Case 3 Actor: User of all OO component applications Goal:Select some text (that has a single colour applied) and copy the colour specification for use elsewhere. Not the colour itself but a composite RGB or CMYK value (+alpha channel, if required) Notes: Implementation behaviour should be the same in all OO applications. General feature note: It would be great to allow different colour models to be used. Like in Inkscape - Indexed Palettes, RGB sliders, HSL sliders, CMYK sliders, Wheel. All of them allow the RGBA value to be copied and/or pasted
I use color pickers frequently, so I doubt that they are unusable. That's all not completely wrong and not really new, for example we had Bug 32376 - [EasyHack] Set default color to the current one in toolbar popups and others for those usability and inconsistence issues @NohWayJose: did you already check whether your wishes have already been reported? With what result?
Created attachment 46187 [details] Impress illustration, with screen grabs of the problem behaviour This illustrates the problem in Impress but it also exists in Calc but not Writer, where the font picker works as expected
(In reply to comment #1) > I use color pickers frequently, so I doubt that they are unusable. My step by step description of how "to recreate the unusable example behaviour" numbers 4b & 5 explains this fairly explicitly. They are usable providing the user is happy with either having to remember the position of the colour they require or their colour choice is sufficiently distinct from the other colours, so that the choice is easy. For picking a particular colour from similar colours/hues/tones, it requires significantly more concentration to get an exact match. And why should the user have to, when we could do what Writer does and persist it in the button and mark it in the grid. > > That's all not completely wrong and not really new, for example we had > Bug 32376 - [EasyHack] Set default color to the current one in toolbar popups > and others for those usability and inconsistence issues > I must admit that I did try to find existing bugs but missed #32376 - sorry about that. However, I think my description is clearer and covers the larger issue of the use cases that the solution should address. > @NohWayJose: > did you already check whether your wishes have already been reported? With what result? I tried all this on my OpenSuse 11.4 machine, with LibreOffice 3.3.1 OOO330m19 (Build:8)tag libreoffice-3.3.1.2 and so far as I can see, it operates as I originally described. I gather from bug #32376 that this should have been resolved fixed in February, so there's a chance my version predates that (not sure how to find out)
May I just confirm that this bug exists in LibreOffice 3.3.2 (release)
<http://wiki.documentfoundation.org/BugReport_Details#Version>
+1 for this. The only difference I see in libreOffice 3.4 (writer) is that when color picker is set to red, then a black word is selected, then the color picker open, the selected color in the picker panel should be black (current text selection color), while it currently stays red (currently selected color)
--- On Mon, 6/13/11, bugzilla-daemon@freedesktop.org <bugzilla-daemon@freedesktop.org> wrote: From: bugzilla-daemon@freedesktop.org <bugzilla-daemon@freedesktop.org> Subject: [Bug 36646] Unusable font color / colour picker in Impress and Calc To: n0h_way_j0se@yahoo.com Date: Monday, June 13, 2011, 10:29 AM https://bugs.freedesktop.org/show_bug.cgi?id=36646 --- Comment #6 from Gaetano Giunta <giunta.gaetano@gmail.com> 2011-06-13 08:29:51 PDT --- +1 for this. The only difference I see in libreOffice 3.4 (writer) is that when color picker is set to red, then a black word is selected, then the color picker open, the selected color in the picker panel should be black (current text selection color), while it currently stays red (currently selected color)
This bugs covers way to much ground IMHO. It should be split into multiple concrete changes. Bug 34425 covers quite a bit of it. Whatever is not covered by it should be split of in a separate bug. If everything is covered by 34425, this is a duplicate and should be fixed as such. ;) However: Do NOT extend the scope of 34425 to let it cover more. 34425 is a EasyHack and can thus not be extended in scope.
I am closing this as a duplicate and want to advise everyone to follow the new meat bug at bug 45671
Disregard the above comment, adding that was an accident.
This is a general UI issue, right? Therefore changed 'Component' field accordingly.
Reenabled with: http://cgit.freedesktop.org/libreoffice/core/commit/?id=7838d6749e0987de5cb78035885dd9e3323426d1 and seems to be stable ever since, closing.
Ups, disregard that (wrong bug).
Needinfo as per comment 8
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO
Apologies - these were accidentally set to FIXED instead of INVALID - sorry for the noise