Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 137206 - in output.py "dark" makes a colour lighter
Summary: in output.py "dark" makes a colour lighter
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks: 136244
  Show dependency tree
 
Reported: 2006-06-18 14:24 UTC by Benno Schulenberg
Modified: 2006-06-23 12:51 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
reorder to brightest first, and remove the darkteal (portage--output-color-order.patch,611 bytes, patch)
2006-06-18 14:25 UTC, Benno Schulenberg
Details | Diff
add some colour synonyms (portage--output-color-extra.patch,580 bytes, patch)
2006-06-18 14:25 UTC, Benno Schulenberg
Details | Diff
proposed color.map.5 man page (color.map.5,1.74 KB, text/plain)
2006-06-21 15:39 UTC, Benno Schulenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benno Schulenberg 2006-06-18 14:24:05 UTC
Trying to find out how to remap portage's colours, I ended up reading the code, and saw that prefixing the darker colour teal with "dark" made it lighter.  The first patch fixes this, and also reorders those two colours to brightest first, like the others are.  The second patch adds some synonyms, among them the probably more familiar words "cyan" and "magenta".  But at least "darkfuchsia" and "darkturquoise" should be added, for symmetry, imho.
Comment 1 Benno Schulenberg 2006-06-18 14:25:10 UTC
Created attachment 89492 [details, diff]
reorder to brightest first, and remove the darkteal
Comment 2 Benno Schulenberg 2006-06-18 14:25:47 UTC
Created attachment 89493 [details, diff]
add some colour synonyms
Comment 3 Zac Medico gentoo-dev 2006-06-18 15:45:16 UTC
Thanks, the teal reordering is in svn r3532.  I'm not adding or removing any colors though.  The color.map can be used to define any colors that the user wants.  There is no need to bloat output.py with more colors.  The ones that are there exist only for backward compatibility.
Comment 4 Benno Schulenberg 2006-06-21 13:42:00 UTC
Okay.  But the user should know which color names can be redefined.  Maybe put this info in a color.map man page?  And then make emerge.1 and equery.1 (and any others that use the mapping) refer to it?  ...  Yes, I'm volunteering to write the page.  :)
Comment 5 Zac Medico gentoo-dev 2006-06-21 14:19:12 UTC
(In reply to comment #4)
> Okay.  But the user should know which color names can be redefined.

Redefinition of colors is not really optimal.  We really need to replace all of the explicite use of *colors* within the portage code with *meanings* so that the user can use color.map to define the colors that they would like to convey specific meanings.

Comment 6 Benno Schulenberg 2006-06-21 15:39:20 UTC
Created attachment 89762 [details]
proposed color.map.5 man page

> We really need to replace all of the explicite use of *colors* within
> the portage code with *meanings*

That would be ideal.  But until then: here's a first shot at a color.map manpage.
Comment 7 Zac Medico gentoo-dev 2006-06-23 12:51:23 UTC
I don't think it's a good idea to document behavior that will certainly change in the near future.  After we've replaced the hard coded colors with meanings, we can document the meanings that are available to be assigned colors.  Also, the hex rgb codes from output.py should be documented, since those 16 colors are the definitive set.

The teal reordering from svn r3532 has been released in 2.1.1_pre1-r2.