Bug 54024 - RGB color values not showing with custom colors
Summary: RGB color values not showing with custom colors
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.5.4 release
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:4.3.0
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-24 20:06 UTC by Bart
Modified: 2014-04-10 18:01 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
see comment 4 (8.32 KB, application/vnd.oasis.opendocument.text)
2013-12-04 17:26 UTC, Bart
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bart 2012-08-24 20:06:37 UTC
When a drawing has a custom fill color (one that is not in the pallet), and you open it's Area properties window, the Area tab shows the right color, but when you then go to the Color tab, RGB is set to 0 0 0 and showing black color.

Doing the same with a drawing that has a fill color that is in the pallet, the Color tab will show the right values.

This bug is a bit of a downy because, if you don't know the original RGB values, it prevents to pick up the custom color and put it in the pallet.

Bart.
Comment 1 A (Andy) 2012-12-26 15:37:20 UTC
not reproducible with LO 3.6.4.3. (Win7 Home, 64bit)
Comment 2 Jorendc 2013-05-19 15:52:09 UTC
I think I also can not reproduce this behavior using Linux Mint 15 x64 with LibreOffice 4.0.3.3.

@bug reporter: is it possible to attach a sample document which we can reproduce this behavior.

Thanks in advance,
Joren
Comment 3 Julien Nabet 2013-11-30 00:22:35 UTC
No feedback since 6 months, I put it as WFM following Joren's comment.
Comment 4 Bart 2013-12-04 17:24:43 UTC
Bug still there in LibreOffice 4.0.3.3 (on Xubuntu)

To reproduce:
- In Writer, add a rectangle
- click right on it and choose Area in the context menu
- goto tab Colors, type a bogus name and change the RGB values
- click OK
- if a message says the color ain't saved, choose Add
- click right on the rectangle, choose Area and goto tab Colors
- if you saved the color
  - click Delete and then OK (now the color is not in the pallet anymore)
  - click right on the rectangle, choose Area and goto tab Colors
- check the RGB values, they are set to 0 0 0 (showing black color)

I added a sample document with a rectangle. It has it's area filled with a color named 'test' and R=123, G=213, B=123.

Sorry I missed comments 1 and 2. I hope someone still will try to solve this little bug ...

Thanks,
Bart.
Comment 5 Bart 2013-12-04 17:26:15 UTC
Created attachment 90259 [details]
see comment 4
Comment 6 Julien Nabet 2013-12-04 18:59:42 UTC
Bart: thank you for your feedback.
On pc Debian x86-64 with master sources updated yesterday, I reproduced this.
Comment 7 Julien Nabet 2014-01-25 00:32:27 UTC
Bart: on pc Debian x86-64 with master sources updated today, I noticed that when I opened the file with the color name entry deleted:
- first time I go to Color tab : RGB values are not retrieved (0,0,0 => Black)
- I go to Area tab and go back to Color tab: RGB values are retrieved 

Caolán: I noticed that if I added this:
 *pPageType = PT_COLOR;
in cui/source/tabpages/tpcolor.cxx, line 429 so to have this:
    427         if( pColorList.is() )
    428         {
    429             *pPageType = PT_COLOR;
    430             if( *pPageType == PT_COLOR && *pPos != LISTBOX_ENTRY_NOTFOUND )

It worked on master sources (I mean RGB values in Color Tab)
Of course, it's just a test and *pPageType == PT_COLOR just below becomes useless with this.

With this Opengrok search,  http://opengrok.libreoffice.org/search?q=pPageType&project=core&defs=&refs=&path=&hist=, I also noticed a kind of pattern:
- tpbitmap.cxx
- tpgradnt.cxx
- tphatch.cxx
and tpcolor.cxx slightly different.
But I don't understand how this kind of pattern might work.
Any idea?
Comment 8 Commit Notification 2014-01-28 11:30:11 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7be0997a0235b05fed9d448e642e0575a4e6e017

Related: fdo#54024 decrazy the Dialog Type for a start anyway



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2014-04-08 11:20:59 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a3416803959b2eb472d5946cbeb8048582f83123

Resolves: fdo#54024 color values not showing with custom colors



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 10 Caolán McNamara 2014-04-08 11:22:56 UTC
seems to work with that, testing appreciated
Comment 11 Julien Nabet 2014-04-10 18:01:11 UTC
With master sources git updated today (b7c7bd3de0fdadaf5e4769e0759d68ad17fb7bd0), I don't reproduce this anymore.
Thank you Caolán!