Kde colors

Bash/awk script that reads the colors from the actual kde color scheme, converts them from rgb (decimal) format to the fvwm hex format and echo the equivalent SetEnv lines for fvwm. You can piperead it from fvwm and then use the variables to make your own colorsets and colorize fvwm to blend with your kde color scheme.

Updated: february, 17 of 2008


COLORS_FILE="$(grep kcsrc ${HOME}/.kde/share/config/kdeglobals)"
echo "SetEnv kde_colors_file \"${COLORS_FILE}\""

echo "UnsetEnv activeBackground"
echo "UnsetEnv activeBlend"
echo "UnsetEnv activeForeground"
echo "UnsetEnv activeTitleBtnBg"
echo "UnsetEnv alternateBackground"
echo "UnsetEnv background"
echo "UnsetEnv buttonBackground"
echo "UnsetEnv buttonForeground"
echo "UnsetEnv foreground"
echo "UnsetEnv frame"
echo "UnsetEnv handle"
echo "UnsetEnv inactiveBackground"
echo "UnsetEnv inactiveBlend"
echo "UnsetEnv inactiveForeground"
echo "UnsetEnv inactiveFrame"
echo "UnsetEnv inactiveHandle"
echo "UnsetEnv inactiveTitleBtnBg"
echo "UnsetEnv linkColor"
echo "UnsetEnv selectBackground"
echo "UnsetEnv selectForeground"
echo "UnsetEnv visitedLinkColor"
echo "UnsetEnv windowBackground"
echo "UnsetEnv windowForeground"

[ -d "$COLORS_FILE" ] && \
        echo Predeterminado de KDE, seteando colores preconfigurados... 
        echo "SetEnv activeBackground #418EDC"
        echo "SetEnv activeBlend #6B91B8"
        echo "SetEnv activeForeground #FFFFFF"
        echo "SetEnv activeTitleBtnBg #DCDCDC"
        echo "SetEnv alternateBackground #EDF4F9"
        echo "SetEnv background #EFEFEF"
        echo "SetEnv buttonBackground #DDDFE4"
        echo "SetEnv buttonForeground #000000"
        echo "SetEnv foreground #000000"
        echo "SetEnv frame #EFEFEF"
        echo "SetEnv handle #EFEFEF"
        echo "SetEnv inactiveBackground #9DAABA"
        echo "SetEnv inactiveBlend #9DAABA"
        echo "SetEnv inactiveForeground #DDDDDD"
        echo "SetEnv inactiveFrame #EFEFEF"
        echo "SetEnv inactiveHandle #EFEFEF"
        echo "SetEnv inactiveTitleBtnBg #DCDCDC"
        echo "SetEnv linkColor #0000EE"
        echo "SetEnv selectBackground #678DB2"
        echo "SetEnv selectForeground #FFFFFF"
        echo "SetEnv visitedLinkColor #52188B"
        echo "SetEnv windowBackground #FFFFFF"
        echo "SetEnv windowForeground #000000"
} || \
awk '
        BEGIN {
        /^\[/ { next }
        /^Name/ { next }
        /^# KDE/ {next }
        /\,/ && !/\#/   {
                        if ( n == 3)
                                printf("%s %s #","SetEnv",$1)
        !/\,/ && /\#/   {
                printf("%s %s %s\n","SetEnv",$1,$2)
        }' \

The results:

$ kde_colors 
SetEnv activeBackground #72C310
SetEnv activeBlend #66AE0E
SetEnv activeForeground #FFFFFF
SetEnv activeTitleBtnBg #66AE0E
SetEnv alternateBackground #2B4906
SetEnv background #595959
SetEnv buttonBackground #2F2F2F
SetEnv buttonForeground #96FF15
SetEnv foreground #FFFFFF
SetEnv frame #656668
SetEnv handle #7F7F7F
SetEnv inactiveBackground #2F5007
SetEnv inactiveBlend #66AE0E
SetEnv inactiveForeground #FFFFFF
SetEnv inactiveFrame #656668
SetEnv inactiveHandle #505050
SetEnv inactiveTitleBtnBg #83DF12
SetEnv linkColor #0173FF
SetEnv selectBackground #66AE0E
SetEnv selectForeground #000000
SetEnv visitedLinkColor #962CFF
SetEnv windowBackground #000000
SetEnv windowForeground #DAFFC7

EDIT: Added support for hex format and kde default theme, improved the detection for useful and non-useful lines.

Oh god how I hate bashism. Nice job, anyhow.

Actually is awkism mostly :stuck_out_tongue: It might not be elegant, but it solves a problem and it is portable. With sed it would be much worse :laughing:

I could make it in C, it would be probably around 500 lines of code just for this stupid thing, and I don’t like to overcomplicate the things when there’s absolutely no need. Even in perl it would probably be a longer program than it is in bash/awk.

Why do you say that? Ten to one it wouldn’t work under mawk. :slight_smile:

– Thomas Adam

I am not familiar with mawk so I can’t comment on that (indeed, it is the first time I hear of it). About sed, well, I use it a lot, but I don’t like it much. It is just that it doesn’t seem like a logical thing to my mind, but it is just a question of tastes I suppose.

That’s fine – just be aware that awk suffers “portability” issues just as much as sed does. :slight_smile:

– Thomas Adam

Bashism” isn’t portable.
You could use #!/bin/sh shebang-line instead. :slight_smile:

It is portable enough for me. I use gentoo, so, bash is a core piece of my system, anyway.

Portability is always a relative concept. Bash is more portable than a C program in the sense that it just works everywhere (where there’s bash, of course). C is more portable than bahs in the sense that you can compile it anywhere, and it will just work. But then again: not every distro under the sun ships a toolchain by default, so this is an inconvenience.

As I said above, I don’t like to overcomplicate the simple stuff, so, I believe that spending a couple of hours tinkering with C is not justified when this can done easily in a few minutes of bashism. The bash string mangling capabilities is something I love and use everyday, on both scripts and command line tasks. And regular sh doesn’t support that as far as I remember (it’s been years since I used sh at all, so forgive me if I am wrong).

Again, it’s all about tastes. Some people just hate bash as much as I dislike java (which others seem to adore, but I believe to be broken for a number of different reasons).

Spoken like a typical^H^^^H^Htrue Gentoo user. :stuck_out_tongue:

I’m sorry – but I take issue here. If you seriously think Bash is more “portable” than C, you then you can’t have done much C programming across different systems. “Compiling” means nothing if you fail to take into account macro’d definitions, off_t things, pid_t things, etc., etc. Utter rubbish.

Bashisms are an unfortunate side-effect of people using a one-track mentality. Even the use of sed(1) scuppers people on BSD for instance. The number of scripts where I see either:

for i in {1..5}; do...; done


for i in $(seq 1 5); do...; done

Where the casual disregard for people either running Bash 2.x (in the case of the former example) or BSD in the case of the latter, is astounding. Given your target audience here is Unix in general, your portability concerns should in theory satisfy all platforms that FVWM runs on.

But don’t worry, no one will hold it against you if someone comes back to you saying it won’t work on a VAX for instance. No one uses those anymore… :slight_smile:

– Thomas Adam

That’s taking it out of context :stuck_out_tongue:

I explained in which sense bash is more portable than C, and in which sense C is more portable than bash. And I don’t think I am wrong.

Being that said, when I speak about portability, I really mean that it is portable for me. If I were really interested in providing a solution for a wider audience, I would probably work into patching fvwm or writing a module to do this. That’d be “the right way” to do it, and would eliminate any portability issue.

I know what do you mean, but there are two views (as with everything in the life). Sometimes I would like to be a bit more skilled on the English language, so I could write a bit more accurately and express the things in a clearer and more concise way.

Well, the problem here is that everyone is free to use the tool s/he like the most. I wouldn’t call that one-track mentality, maybe it’s the other way around :laughing: Bash is a very convenient shell for a lot of people. That others do not like it does not make it any worse. There shouldn’t be any reason why bash can’t be ported to any arch/os, but to tell the truth I don’t know the details, or if there are some kind of licensing issues (bsd always has issues of all kinds, and I usually don’t like to make things complicated, when they are not).

So I hope :laughing:

Oh, OK, so a mutually-exclusive portability. I would call that a non-portability then. :slight_smile:

I’ll remember that one for next time, thanks.

– Thomas Adam

6thpink, you might want to read a little about something called POSIX, and its definitions for shell if you have the time and interest.

Also I think comparing shellscripts and C in regards of portability is a bit silly. There really isn’t much to it with shells, yet Linux posse insists using bash shebang, even if they have /bin/sh linked to bash, and even if they don’t use any bash-specific syntax (which baffles me).
And you know what? I’m totally OK with it as long as you don’t go saying it’s portable.

Btw, I tested the script on regular Bourne shell, and it would seem to be working, so it should be safe to change the shebang.

I will not continue the “portability” discussion since this is getting nowhere. I have already said that I understand what Thomas and you said, and explained my reasons, and this is getting a bit silly as you say.

I don’t like to repeat things. And the discussion is irrelevant anyway, everyone can use the shebang s/he likes the most. No need to go obsesive about this.

My main concern was the ${//} syntax, which I don’t know if works on regular sh. So, if anyone can confirm that I can change the shebang if that makes you happy. However, as I said, the fact that lots of people dislike bash doesn’t make it any worse. And even if it hurts someone feelings, bash is going to be alive for good or bad for a very very long time.

Such is reality.

Dude, I don’t love or hate bash.
And as I said, I don’t mind you doing bashisms, I only mind you doing it and saying it’s portable (POSIX being the most common definition for portability). Comprende?

No need to even try to test this, ${//} is a bashism through and through, FWIW.

– Thomas Adam

That’s what I thought.

If it works with regular sh for morbusg it might be just because it reverts to the original kde colors, which is not the intended effect. So, for sh you’d need to use sed, awk or whatever.

We define so-called “regular sh” to use your phrase as sh shipped with Solaris, for instance or that which adheres strictly to the POSIX standard.


– Thomas Adam