Download it now!
Bug 36646 - Unusable font color / colour picker in Impress and Calc
Summary: Unusable font color / colour picker in Impress and Calc
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: color_handling
Keywords:
Depends on: 34425
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-27 16:19 UTC by NohWayJose
Modified: 2013-10-25 16:18 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Impress illustration, with screen grabs of the problem behaviour (75.63 KB, application/vnd.oasis.opendocument.presentation)
2011-04-30 03:31 UTC, NohWayJose
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NohWayJose 2011-04-27 16:19:55 UTC
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
Comment 1 Rainer Bielefeld Retired 2011-04-27 22:34:23 UTC
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?
Comment 2 NohWayJose 2011-04-30 03:31:52 UTC
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
Comment 3 NohWayJose 2011-04-30 03:33:43 UTC
(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)
Comment 4 Alex 2011-06-06 14:01:36 UTC
May I just confirm that this bug exists in LibreOffice 3.3.2 (release)
Comment 5 Rainer Bielefeld Retired 2011-06-06 21:38:58 UTC
<http://wiki.documentfoundation.org/BugReport_Details#Version>
Comment 6 Gaetano Giunta 2011-06-13 08:29:51 UTC
+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)
Comment 7 NohWayJose 2011-06-24 01:28:10 UTC
--- 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)
Comment 8 Björn Michaelsen 2011-12-23 18:33:48 UTC
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.
Comment 9 Stefan Knorr (astron) 2012-02-06 06:59:57 UTC
I am closing this as a duplicate and want to advise everyone to follow the new meat bug at bug 45671
Comment 10 Stefan Knorr (astron) 2012-02-08 07:59:25 UTC
Disregard the above comment, adding that was an accident.
Comment 11 Roman Eisele 2012-05-04 07:37:32 UTC
This is a general UI issue, right? Therefore changed 'Component' field accordingly.
Comment 12 Björn Michaelsen 2013-02-23 19:23:40 UTC
Reenabled with:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=7838d6749e0987de5cb78035885dd9e3323426d1

and seems to be stable ever since, closing.
Comment 13 Björn Michaelsen 2013-02-23 19:24:49 UTC
Ups, disregard that (wrong bug).
Comment 14 Björn Michaelsen 2013-02-23 19:27:15 UTC
Needinfo as per comment 8
Comment 15 QA Administrators 2013-09-24 01:58:47 UTC
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
Comment 16 QA Administrators 2013-10-25 15:19:45 UTC
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
Comment 17 QA Administrators 2013-10-25 16:18:39 UTC
Apologies - these were accidentally set to FIXED instead of INVALID - sorry for the noise