I was (am?) having a hard time trying to understand the color gradients.
I think I got it now, but please confirm.
Here is the picture.
You can find more about it from here.
[color=red]Edited by theBlackDragon:
–> Made sticky.[/color]
hi
was playing with it tonight : ).
You’ve got it !!! ( and helped me with your graph, thx )
Could you poste an example code. I would like to make some gradient icon for my FvwmButtons taskbar (using FvwmIconMan).
Erm… the picture itself is pretty self-explanatory example code
[size=75](well, apart from that it seems it depends how the last segment is interpreted based on wether there are 2, 4, 6, 8 etc. segments, or 3, 5, 7, 9 etc.)[/size]
But since you asked, this is what I’m using for my current “adapt”-theme:
Colorset 2 VGradient 32 2 #e5e5dd 50 #670000 50 #e82b02And the result looks something like this (the titlebars).
For colours, you can use either of the 2 rgb notations (rgb:rr/gg/bb, #rrggbb), or a colour name from rgb.txt.
Ok this seems to work fine:
Colorset 61 HGradient 32 2 #e5e5dd 50 #670000 50 #e82b02
DestroyDecor newstyle
AddToDecor newstyle
+ TitleStyle Center Height 18
+ TitleStyle AllActive Colorset 61But when I change the Colorset to this it does not work anymore:
Colorset 61 HGradient 32 2 Red 4 BlueI have also tried this from the manpages but it does not work either:
Colorset 61 Blue Red HGradient 8 3 Blue 1000 Green 1 Yellow 1000 Redany hints?
BTW: How did you come up with: #e5e5dd, #670000, #e82b02? In the rgb.txt file I found on my system there was no entries like that. Could be nice if it was possible to choose some colors (eg from photoshop) and then see these corresponding values.
rgb notation just means you tell the amount of each colour; red, green, blue in hexadecimal format for fvwm. Each color can be made from different values for these three colors (well to be honest, I’m not certain of that)
In rgb.txt, they are in different format, and mapped to a name. So rgb.txt has only a limited amount of colours.
It is always safe to give colours in rgb notation since one might be missing the whole rgb.txt -file (or then in some location X won’t find it). You can find out the colours you want in the right format in Photoshop (or Gimp) with the colour picker; just look for a similar format (I think it’s under the label of “web-colour” in Photoshop)
EDIT: Now that I think about it, I think I remember that the new 7-releases of modular X doesn’t have a rgb.txt, but then again, I might remember all wrong.
Pretty much it can, yes. Note that the degree to which those colours is comprised depends upon how well the XServer (in this case) can manage the colours, and whether the hardware you’ve got can display them. The human eye can only perceive a certain colour range before it just sees the same colour.
A little bit of history for you. X11 as a server has to cater for almost all kinds of colour terminals with different values. The values in rgb.txt are therefore quite generic for that reason alone. Back in the day, before PCs were some form of commodity, the big mainframe terminals is what X11 used to run on, with some very interesting hardware.
If that happens, you’ll run into a lot of trouble from programs that do specify colours in a named format. It won’t just be FVWM that complains either.
Look on freshmeat.net for ‘gcolor2’.
Absolutely not! Without rgb.txt, you wouldn’t be seeing colour in half the applications you do now.
– Thomas Adam
Erm… Ok…? Thanks for answering to my answer. 
Bigblop, your non-working gradient lines are badly formed, please re-read the explaining gradient picture. Segment is the keyword here.
Relax – it’s a discussion, not a picking-holes-in-answers exercise. :)
– Thomas Adam
in you original post you say that n can be from 2 to 1000, but why is 32 not allowed?
Colorset 61 HGradient 32 2 Red 4 Blue
And here I was, thinking that the example was clear as ice. Apparently not.
Let’s try again, shall we?
If you only have two colours, you don’t need to make a segment (well you do make a segment, but you don’t need to define it if there’s only one segment). Lets say a segment is a transform of one colour into another.
You can define a gradient in two ways:
-
If you only want one segment, you can just define the number of colours, a starting colour, and the ending colour.
-
If you want more than just two colours, you can make segments. The second “argument”, then, is to define the number of segments. In the example picture, there are five segments. So the “n” is actually representing the number of colours used for the whole gradient (consisting of segments).
Would you believe all this reads in the manual page? Neither would I, it’s just so amazing.
Anywhoo, after you first define the number of colours, and second define the number of segments, you can move on forward defining your first colour. After you’ve done that, you define at what percentage does it begin transforming into the colour defined after that (the beginning of segment is 0%, and the end is 100%, but for the last segment, it gets reversed if the total number of segments is pairless [this, I could very well be just making up, since I haven’t tested it]). Repeat as many times as you have segments.
Confused? Me too.
I mean, why the hell did Thomas get mainframes as kid, when all the rest of us got to play with lousy commodore-whatever-they-were, playing some dull donkeykong with a wooden joystick. 
My dad is a hydrometallurgist. His place of work during the 80s and early 90s was at a chemical plant that had a lot of cool “hardware” (at that time). They used UNIX mainframes. I remember them well, for some reason. :)
I still went through the motions with the home-PC stuff. I own and still use three BBC Master computers, as well as owning a ZX Spectrum +2 computer, with built-in tape-deck. It’s cool. :)
As for the colorset thing (I don’t want to completely randomise this thread with my ramblings), the gradient algorithms that are used do some very complex things – they have to since the hue change from one colour to another is computed – it’s not stored anywhere. That’s primarily why the colorset definitions have to be that specific, and whilst they might appear somewhat daunting to begin with, you’re best bet (bigblop, really) is to read ‘‘man FvwmTheme’’ and the COLOR GRADIENTS section of ‘‘man fvwm’’. Of course, I don’t really mean “read” as in “understand” [1] – but more to try out the examples listed therein.
– Thomas Adam
[1] I’ve never read the entire FVWM man page – I just have the ability to memorise those parts I need to.
Ok, I’m joining the fun 
To be honest, I got a gradient and a question:
[code]
Border
Colorset 2 HGradient 20 #c3551a #b90882[/code]
Works like a charm, except when the window changes its size itself (rox filer). Then the existing Gradient gets tiled or cut off to fit he new window size. When I focus out and in again the border gets redrawn. Is there any way to redraw it when he window size changes?
You may have a look at the module FvwmEvent. It enables you to react on various kinds of WM events like iconifying windows etc.
No. FvwmEvent won’t help you here.
I haven’t looked inside the fvwm source, but I assume fvwm initiates recalculating of the gradient only on user interaction.
“If there is no user interaction, there is no change, therefore nothing to do.”
Sounds reasonable to me, but my beloved rox does disagree
Maybe next week I’ll gonna dig into it and write a patch (depending on my limited capabillitie, of course).
Or rox gets his own (gradient free) border alltogether.
But FvwmEvent sounds funky anyway
It redraws the gradient on ConfigureNotify changes.
Disagrees how? You need to be a lot more specific.
– Thomas Adam
Sorry, my fault
When you change to another directory, rox adjusts the size of the window to fit the content of the new directory, shrinking or increasing it.
While the window border is redrawn to fit the new window size, the gradient seems to stay the same and is just tiled.
Here is an example:
