Subject: New fvwm-2.0.43 feature

From: Ondrej Popp <[email-masked]>
Date: Mon, 07 Oct 1996 21:46:26 +0100

Hi,
I would like to contribute a new feature I've built into
Fvwm last weekend.

With this feature, it is possible to set automaticaly
the foreground/background colors of a swallowed X/Xt/Xm/Xmt -
application to the fore/back colors of the button in question, or to the
the general colors of FvwmButtons.

If you want uniformly colored buttons, you can set the
general colors on FvwmButtons. Like this, 
*FvwmButtonsFore	gold2
*FvwmButtonsBack	chocolate4

Although this works fine for action buttons, it does not work
for swallowed X(t/m/mt)-programs, because they inherit their colors
from the window manager during their initialisation phase.
And the Fore/Back colors of the window manager are not necessarily
the Fore/Back clors of the FvwmButtons.

To solve this I modified the  fvwm-2.0.43/modules/FvwmButtons/parse.c
file to allow command substitutions.

With this modification, you can add the %f %F (foreground), %b %B
(background) operators to the Exec command that is going to spawn
the X application. During parsing, these operators are substituted
for the actual fore/back colors of the button or for the general
colors of FvwmButtons in that order of priority.

here is an example,

*FvwmButtons(Title "CD Rom",Swallow "XCdrom" `Exec Xcdrom -fg %F -bg %B
> /dev/console &`)

in this example, the X application Xcdrom is executed with the standard
X toolkit options
-fg %F -bg %B. During the parsing phase of FvwmButtons these operators
are going to be
substituted for the actual colors, so when the program is spawned it
gets the right colors.

to implement this I added a new function,
 
static char *ProcessSpawnCommand(button_info *b, button_info *ub, char
*spawn_command)

to the parse.c file. This function does the substitutions. It processes
the original
*spawn_command, looks for the actual colors in the *b and *ub
button_info structures
and returns the modified spawn_command to be used to spawn the X
application.

This function is called at two places, inside match_string() to get it
working.
Oh, yeah... I also suspended the actual spawning in case 7 to later,
because at that point the Fore/Back colors of the button may not be
defined yet.
(if the private Fore/Back colors of the button are defined *after* the
Swallow command.
 I dont know if this is legal, but that is the way dotfile generates it.
Great tool,
 by the way, no more typing errors, etc...) 

I also modified the FvwmPager module, to add the -fg -bg and -hi options
for
setting the fore, back and the highlight colors respectively.

with this modification, you can also get the colors of FvwmPager right
when you
swallow it. Here is an example,

*FvwmButtons(8x1,Swallow "FvwmPager" `Module FvwmPager 0 3 -bg %b -hi
%f`,Padding 0 0)

In this example, the background of the FvwmPager module is set to the
background of
FvwmButtons and the highlight color is set to the foreground of the
FvwmButtons.
The foreground remains as defined in the fvwmrc file.

The changes to FvwmPager consist of the introduction of three
new variables,  
char *arg_PagerFore,
char *arg_PagerBack,
char *arg_HilightC  in main(int argc, char **argv)

I've also modified the ParseOptions() function to 
void ParseOptions(char *arg_PagerFore, char *arg_PagerBack, char
*arg_HilightC)
to process these arguments accordingly. The commandline options take
precedence
before the settings in the fvwmrc file. I reshuffled the calling order
in main a little bit because I needed Scr.d_depth earlier.
I also modified the external declaration of ParseOptions(...) in
FvwmPager.h
to reflect its new arguments.

In the following attachement you will find the three modified files.

Can somebody please look at the modifications I made, because I am not
too
familiar with the fvwm source yet. I have only been at it for one
afternoon yet.
I am especially not sure if the *ub button_info structure always holds
the right
color information if the button has no defined colors itself. And if
not, where to get them
from in that case. Also what happens if you introduce more hierarchy in
it with the 
containers. I've protected the code against crashes if the colors can
not be found, but it is
ofcourse better to solve it the right way. I think it might take me an
other afternoon
or maybe longer to figure all this out, when somebody else just knows
these things by head.

Well, having said that, it works great for me, and I hope it is going to
be
of use to other people as well.

Greetings from Holland,
Ondrej Popp