[systemd-bugs] [Bug 53937] RFE: Customizable colors of messages at bootup

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=53937

--- Comment #9 from Zbigniew Jedrzejewski-Szmek <zbyszek at in.waw.pl> ---
> I'm fairly confident in the parts that get/parse the configuration options, Yes, that part looks good.

> I'm not sure about the variables/macros/functions that actually use the
> colors.
It's a start, but...

- There's no need to keep the "ansi"/"ANSI_" prefix in color variables and
constants.

- I think it would be better to keep the ANSI_* constants, so you have e.g.
#define ANSI_RED_ON "\x1B[31m"
#define COLOR_BAD ANSI_RED_ON

- Would it be possible to call the colors by syslog priority
levels: ColorDebug, ColorWarning, ColorInfo, ColorNotice, ColorWarning,
ColorError, ColorCritical, maybe with an additional ColorSuccess for green?
This
would make it easier to relate to existing terms. You said that you went over
places that colors are used, would it conflict significantly anywhere?

- Since those "constants" are now configurable, they must become arguments to
the printf format strings almost everywhere:

-        fputs("\r\x1B[?25l" ANSI_HIGHLIGHT_GREEN_ON, stdout);
+        fprintf(stdout, "\r\x1B[?25l%s", color_good);

Efficiency is not "important". Output to the console is always excruciatingly
slow, and the extra access to a variable is not an issue.

Also, at some point we would like to extend to 256 colors. I don't think
there's anything in your patch which would be a problem, but please keep that
in mind.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20140111/08e6a05e/attachment.html>