fvwm-themes-devel — Developing FVWM Themes

Re: About the CVS page on sourceforge

[Alex W. <aw...@do...>]

Alex Wallis wrote:
> 
 
> Keep up the good work!
> 
I just noticed the "Anonymous FTP Space" directory contains an old
version (0.3.6) which obviously needs updating.

As a further comment, I think occasional regular announcements to the
freshmeat list and/or fvwm-workers list might deserve consideration now,
to stimulate interest and input from new users. Perhaps even the wider
fvwm list and/or fvwm-announce?

Alex

0.3.15

[Olivier C. <oli...@fr...>]

I release 0.3.15 because 0.3.14 have unused (working) files
under themes.
Olivier

Re: About the CVS page on sourceforge

[Mikhael G. <mi...@co...>]

On 07 Aug 2000 09:19:45 +0200, Olivier Chapuis wrote:
> 
> Mikhael Goikhman wrote:
> > 
> > Oh, I have added missing awol/theme.cfg, now awol theme should work well.
> > I should find a time and fix this problem, so no theme.cfg is needed.
> 
> Note, that this change will not be in O.3.14 since you commit this change
> durring I upload 0.3.14! 

This is ok, no problems. But in the future we can first update NEWS/README
file some time before release, or send an email saying "I will release a
new version in half an hour (or a day for major releases) unless there are
objections". This will increase a probability of fixing critical problems
before a release.

Regards,
Mikhael.

Re: colors again

[Mikhael G. <mi...@co...>]

On 07 Aug 2000 09:09:14 +0200, Olivier Chapuis wrote:
> 
> One remark: I do not think that WindowColorsets 1 2 are needed in Pager
> config because the Pager used automatically the active/inactive windows
> colorsets. Any way this not a problem ...

Without this command Window3dBorders will not work.

> But why January's 0.0.5 version is the latest SourceForge version?
> I will release a new version at once!

Because I uploaded 5 first versions 0.0.1 to 0.0.5 just for archive.

Regards,
Mikhael.

Re: About the CVS page on sourceforge

[Olivier C. <oli...@fr...>]

Mikhael Goikhman wrote:
> 
> The page at SourceForge is autogenerated, it can't be replaced.
> I have added a link in HP to http://fvwm.org/cvs.html instructions.
> Anyway, I don't think this is a real problem, since those who want to use
> fvwm-themes cvs, *should* use fvwm cvs too, otherwise some new changes
> may not work.
> 
> Oh, I have added missing awol/theme.cfg, now awol theme should work well.
> I should find a time and fix this problem, so no theme.cfg is needed.
>

Note, that this change will not be in O.3.14 since you commit this change
durring I upload 0.3.14! 
Olivier

Re: colors again

[Olivier C. <oli...@fr...>]

Mikhael Goikhman wrote:
> 
> I have committed many corrections for the latest colorset changes, still
> may be places to fix and improve.
>

One remark: I do not think that WindowColorsets 1 2 are needed in Pager
config because the Pager used automatically the active/inactive windows
colorsets. Any way this not a problem ...

> Olivier, do you want to release a new version? The reason is that people
> see January's 0.0.5 version as the latest due to SourceForge "feature". :)
> 

But why January's 0.0.5 version is the latest SourceForge version?
I will release a new version at once!

> Regards,
> Mikhael.
> 
> --
> FVWM-Themes-devel mailing list, fvw...@li...
> http://lists.sourceforge.net/mailman/listinfo/fvwm-themes-devel

Re: About the CVS page on sourceforge

[Mikhael G. <mi...@co...>]

The page at SourceForge is autogenerated, it can't be replaced.
I have added a link in HP to http://fvwm.org/cvs.html instructions.
Anyway, I don't think this is a real problem, since those who want to use
fvwm-themes cvs, *should* use fvwm cvs too, otherwise some new changes
may not work.

Oh, I have added missing awol/theme.cfg, now awol theme should work well.
I should find a time and fix this problem, so no theme.cfg is needed.

Regards,
Mikhael.

About the CVS page on sourceforge

[Alex W. <aw...@do...>]

Okay, I've been quiet because of work commitments and my link was messed
up by my isp, but now I'm back.

Olivier, I have a few comments about the color specs that I'll pass
along in the next few days.

I've just reinstalled my whole box, and decided to give the new
fvwm-themes cvs a try. No real problems, except....

I think the page at sourceforge for the cvs isn't really clear enough in
its instructions. I'm not very experienced at cvs but if I hadn't been
familiar with the fvwm cvs page I might not have succeeded.
Specifically, and I had to guess at this, I think it should have the
"automake --add-missing ; autoreconf" commands added to it.

Also I agree with Mikhael that the link to the January package release
should be more "up to date". Perhaps some regular beta
release(monthly/weekly?) might be appropriate for those that want to
keep current without the bother of cvs? :-)

Of course its not a real problem until we have many more users of
fvwm-themes. :-P

Keep up the good work!

Alex

Re: colors again

[Mikhael G. <mi...@co...>]

I have committed many corrections for the latest colorset changes, still
may be places to fix and improve.

Olivier, do you want to release a new version? The reason is that people
see January's 0.0.5 version as the latest due to SourceForge "feature". :)

Regards,
Mikhael.

Re: colors again

[Mikhael G. <mi...@co...>]

On 06 Aug 2000 10:28:16 +0200, Olivier Chapuis wrote:
> 
> Now current cvs have new colors files. There are surely some
> bugs ... and moreover since now we have more colors we may want
> to modify some of the colorsets in some colors file.

I will comment later.
I see some bugs: Window3dBorders in pager does not work, Shift-Alt-F12.

You have overwritten all my text corrections done to doc/colorsets,
seems that you copied that part from default/colors instead of doing
the reverse thing, now all these typos are at least in two files. :)
I will restore this later together with other planned corrections.
Yes, seems, we need cvs logs (but automatical, not manual).

I like your idea with black/white foreground in colors@cde!
Now White/WhiteBlack and especially Black/BlackWhite color schemes
make much sence. I start to think that this is what CDE does too.

Regards,
Mikhael.

colors again

[Olivier C. <oli...@fr...>]

Hello,

Now current cvs have new colors files. There are surely some
bugs ... and moreover since now we have more colors we may want
to modify some of the colorsets in some colors file.
Alex and Jos if you want to modify some colors files just
sent to me yours colors suggestions.

About cde@colors: now cde colors schemes have some text colors
(see --colors-schemes options of fvwm-themes-images). However,
I am not sure to understand the meanings of the 8 colors in a
cde colors scheme. COLOR1 and COLOR2 have a clear meaning, but
what about the others?  So, maybe the new main cde colors file
have to be modified ...

About spruce@colors: I have modified some colors (modules and 
applications); maybe there are too much green. Eric do you have
some suggestions?

Olivier

Re: Colorset 2 and Images

[Mikhael G. <mi...@co...>]

Ok, I agree that there are 2 variants - a new component defaults@, or
rearranging of styles@ and modules@. There is actually the third variant -
leave as it is now. I don't know which one to choose, any has advantages
and disadvantages. One should think more here and implement the best.

Regards,
Mikhael.

Re: Colorset 2 and Images

[Olivier C. <oli...@fr...>]

Mikhael Goikhman wrote:
> 
> On 29 Jul 2000 23:53:36 +0200, Olivier Chapuis wrote:
> >
> > > I think they all belong to styles@. Or styles-standard@,
> >
> > but there are also Modules command.
> >
> > > but probably
> > > we don't really need a new component for this. How about adding
> > > Colorset config commands for other modules? They also always the same.
> >
> > Not "in general". Modules themes designer can do what he wants with
> > the colors that colors@ provide to it. The spec is just some suggestion?
> > Moreover, we cannot do that for Buttons in the view of the number of alises.
> 
> modules@ follows styles@ anyway, because of default module styles.
> In styles@ there are only standard defaults for module colorset numbers.
> If a theme designer wants to change them, he still can do it in modules@.
> 

Ok, but how we destroy the modules config? In general, we destroy
the modules config before we configure a module and also when we
leave a modules theme. It seems difficult to change that.
So I suggest to do not move colorset "modules themes" modules config.
On the other hands we can move the fixed part of the colors config
(section IV of the spec) in style@ but we do not win a lot since we
probably need to relaod style@ each time we do a modules@ switch.
Since it is not a very good idea to move this fixed part into fvwm-themes-config.in we can introduce a new special component 
called "fixed" where we can put all the config command that have
to be read only one time? An other possibilty is to do so that 
modules@ does not "needs" style@: I do not think that we 
have to provide styles for the "modules themes" modules in style@ this 
is the task of modules@. In this case moving section IV into styles@
seems ok.

Regards, Olivier

fvwm-themes 0.3.13

[Mikhael G. <mi...@co...>]

This is a fix release, it fixes the problem with 0.3.12: switching themes.
There are some more fixes and improvements. Added buttons@cde component.

Included doc/colorsets file (updated), feel free to comment.

Regards,
Mikhael.

Re: Colorset 2

[Mikhael G. <mi...@co...>]

On 29 Jul 2000 23:53:36 +0200, Olivier Chapuis wrote:
> 
> > I think they all belong to styles@. Or styles-standard@, 
> 
> but there are also Modules command.
> 
> > but probably
> > we don't really need a new component for this. How about adding
> > Colorset config commands for other modules? They also always the same.
> 
> Not "in general". Modules themes designer can do what he wants with
> the colors that colors@ provide to it. The spec is just some suggestion?
> Moreover, we cannot do that for Buttons in the view of the number of alises.

modules@ follows styles@ anyway, because of default module styles.
In styles@ there are only standard defaults for module colorset numbers.
If a theme designer wants to change them, he still can do it in modules@.

Regards,
Mikhael.

Re: Colorset 2

[Olivier C. <oli...@fr...>]

Mikhael Goikhman wrote:
> 
> On 29 Jul 2000 22:17:23 +0200, Olivier Chapuis wrote:
> >
> > The colors files contain some configuration commands
> > that are alawys the same:
> >
> > DefaultColorset 0
> > DestroyModuleConfig FvwmScrollColorset*
> > *FvwmScrollColorset 0
> >
> > Style "*"     Colorset 1
> > Style "*"     HilightColorset 2
> >
> > Style "*"     BorderColorset 3
> > Style "*"     HilightBorderColorset 4
> >
> > ...etc.
> >
> > No objection for moving these commands into themes-rc?
> 
> I think they all belong to styles@. Or styles-standard@, 

but there are also Modules command.

> but probably
> we don't really need a new component for this. How about adding
> Colorset config commands for other modules? They also always the same.
> 

Not "in general". Modules themes designer can do what he wants with
the colors that colors@ provide to it. The spec is just some suggestion?
Moreover, we cannot do that for Buttons in the view of the number of alises.

> Anyway I don't want to hardcode them in fvwm-themes-config.
>

So at the present time I will not move these commands out of colors.
If you have no more comments on doc/colorsets I will begin the changes
in one or two days.

Jos, Alex no comments on colorsets ?

Olivier  
> Regards,
> Mikhael.
> 
> --
> FVWM-Themes-devel mailing list, fvw...@li...
> http://lists.sourceforge.net/mailman/listinfo/fvwm-themes-devel

Re: Colorset 2

[Mikhael G. <mi...@co...>]

On 29 Jul 2000 22:17:23 +0200, Olivier Chapuis wrote:
> 
> The colors files contain some configuration commands
> that are alawys the same:
> 
> DefaultColorset 0
> DestroyModuleConfig FvwmScrollColorset*
> *FvwmScrollColorset 0
> 
> Style "*"	Colorset 1
> Style "*"	HilightColorset 2
> 
> Style "*"	BorderColorset 3
> Style "*"	HilightBorderColorset 4
> 
> ...etc.
> 
> No objection for moving these commands into themes-rc?

I think they all belong to styles@. Or styles-standard@, but probably
we don't really need a new component for this. How about adding
Colorset config commands for other modules? They also always the same.

Anyway I don't want to hardcode them in fvwm-themes-config.

Regards,
Mikhael.

Re: A colorset spec

[Olivier C. <oli...@fr...>]

Mikhael Goikhman wrote:
> 
> So, please update the colorset spec and put it into cvs under doc/.

Done, also add CDE buttons, Olivier

Colorset 2

[Olivier C. <oli...@fr...>]

Hello,

The colors files contain some configuration commands
that are alawys the same:

DefaultColorset 0
DestroyModuleConfig FvwmScrollColorset*
*FvwmScrollColorset 0

Style "*"	Colorset 1
Style "*"	HilightColorset 2

Style "*"	BorderColorset 3
Style "*"	HilightBorderColorset 4

...etc.

No objection for moving these commands into themes-rc?

Olivier

Re: A colorset spec

[Mikhael G. <mi...@co...>]

So, please update the colorset spec and put it into cvs under doc/.

Regards,
Mikhael.

Re: A colorset spec

[Olivier C. <oli...@fr...>]

Mikhael Goikhman wrote:
> 
> On 28 Jul 2000 22:29:00 +0200, Olivier Chapuis wrote:
> 
> > * Modules Colorsets
> > -------------------
> >
> > Colorset 10: default module colorset: FvwmPager FvwmButtonColorset.
> >  Can be use for *FvwmIconMan*Colorset FvwmIconBoxColorset (see also
> >  colorset 12)
> >
> > Colorset 11: hilight default colorset: for hilighting a part of
> >  of an FvwmButton or a certain swallowed applications.
> >
> > Colorset 12: special colorset: as 10 but a more funny colors a gradien
> >  or a pixmap.
> 
> 
> Can't colorset 11 be used for this? I don't quite understand colorset 11.
>

Now that I think more I think it is a good idea that the pager have
its own colorset "default2 and hilight2". Pager is an important
module and one may want to hilight it in a Buttons.

Olivier

Re: A colorset spec

[Olivier C. <oli...@fr...>]

Mikhael Goikhman wrote:
> 
> On 28 Jul 2000 22:29:00 +0200, Olivier Chapuis wrote:

> > * Modules Colorsets
> > -------------------
> >
> > Colorset 10: default module colorset: FvwmPager FvwmButtonColorset.
> >  Can be use for *FvwmIconMan*Colorset FvwmIconBoxColorset (see also
> >  colorset 12)
> >
> > Colorset 11: hilight default colorset: for hilighting a part of
> >  of an FvwmButton or a certain swallowed applications.
> >
> > Colorset 12: special colorset: as 10 but a more funny colors a gradien
> >  or a pixmap.
> 
> I know you mean blackbox theme. 

No, this special color is already use in other themes as default,
olicha, aftersetp. The modules theme may want to have a clean
colorset for setting say the background of IconMan/Box or a more
funny color for these.

> Somehow I don't like the trick with
> substituting another colorset at run time when using certain theme.
> Maybe we should introduce an auto-conditional options in our CDDS, which
> are like current user-definable options, but switch is done automatically
> accourding to the given conditions. 

This will be great.


> > Colorset 13: Pager hilight colorset
> 
> Can't colorset 11 be used for this? I don't quite understand colorset 11.
>

Yes
 
> > Colorset 14: tips colorset (Pager, TaskBar)
> >
> > Colorset 15: colorsets for swallowed applications
> 
> Maybe swallowed applications should use colorsets 10/11? I don't know.
> 
> > Colorset 16: colorset for more colors in a swallowed application
> >  (e.g., xclock & xload have -hl & -hd color)
> 
> My previous idea to have -hl & -hd in one colorset (fg/bg) pobably can't
> work, because black/black is bad for bg/fg and I don't want to make this
> xclock/xload specific. On the other hand I have no better ideas.
> 
> > Colorset 17: colorset for a normal button in the AppMans (IconBox, IconMan,
> >  TaskBar, WinList)
> 
> AppMan name is ok, but I like more a generic name WinList for modules that
> show a list of windows. :)  AppList? But why app, it handles any window,
> it may be several windows per application. Somewhat off-topic.
> 
> > Colorset 18: colorset for a button which represent a window
> >  with the focus in the AppMans.
> >
> > Colorset 19: colorset for a button which represent an iconified
> >  window in the AppMans.
> 
> Still 3 colorsets for WinLists? There are so many boolean window states
> like iconified (maximized, shaded, sticky, visible), some of them may be
> supported in some feature, maybe to leave a colorset for this additional
> state? Or a bad idea?
> 
> But at least we need a way to mark a selected window button (i.e. the one
> with a mouse pointer on it). FvwmIconMan supports this. Alex wanted this
> and I promissed to do something here.
> 

So I have to add a colorset pointed button and reserve one colorset
for future use or more?

> > Colorset 20: FvwmIdentColorset
> >
> > Colorset 21: FvwmScrollColorset (do we need this colorset, colorset 32 is
> >   ok? or Colorset 0?)
> 
> Or 10. :) Well, probably we don't need this, but what colorset to use?
> Is it a good idea to suggest colorset 0 *or* 32 for FvwmScrollColorset?
> 
> > Colorset 22: FvwmConsole
> 
> Don't you like it to be the same color as a root term? :)
> 

I prefer a specific color, it can be the root colorset in some color
themes :)

> > Colorset 23: dynamic colorset (a colorset that can change during use
> >   without affecting the whole look, e.g., for FvwmScript-ColorsetBrowser)
> 
> Ok, temporary colorset. But should it belong to module colorsets?
> 
> > Colorset 24 to 25: reserved for modules themes
> >
> > Colorset 26 to 29: reserved for future use
> >
> > * Applications colorsets (Form and Script are here!)
> >
> > Colorset 30: default (text) colorset for terminal like application
> >   (E.g., xterm in our menu)
> >
> > Colorset 31: (text) colorset for remote shell/applications
> >
> > Colorset 32: (text) root colorset
> 
> We need a special term colorset (current 22), we use it in a special xterm
> viewer windows (top/less/tail -f), I worry about it more than about a root
> term colorset. Root term is not even that some people have, maybe to call
> it admin term colorset and include FvwmConsole term in it? :) Anyway in
> the future FvwmConsole will be FvwmCommand in xterm.
>

Yes but the future may be in a very long time ...
 
> I think it is ok to have a separate colorset for special viewers and text
> editors. The following was supposed to be should be 33, I think.
>

Yes, it is a good idea, but we may want to use a special colorset.

Olivier

Re: CVS and a question

[Mikhael G. <mi...@co...>]

On 29 Jul 2000 00:51:04 +0200, Olivier Chapuis wrote:
> 
> I think it will be good to change the default background.
> Any idea?

I would prefer 'default' theme to be light and fast, and work for everyone
if possible. So gradient is not an option, I suppose. Maybe 5 color patern.

Jos, can you create an FVWM logo using 5 colors (similar to win-fvwm.xpm)?

> PS: adding files seems to work :)

Why not? I bet deleting works too. :) You can even start fvwm-themes-web
repository in parallel to fvwm-themes.

> PS: I think it is good idea to send a message when we commit.

This requires me to open my (remote) mail client before and after my work
on fvwm-themes and write logs twice. I was so used to read ChangeLog,
which is more informative than cvs logs, that I start to think not to have
auto logs at all (half seriously).

Regards,
Mikhael.

Re: A colorset spec

[Mikhael G. <mi...@co...>]

On 28 Jul 2000 22:29:00 +0200, Olivier Chapuis wrote:
> 
> Here a spec for fvwm-thmes colorsets
> Any suggestions are welcome before I begin the work on colorset.
> 
> 1- Fvwm colorsets:
> ------------------
> 
> Colorset 0: default colorset.
>  I think that we have to add "DefaultColorset 0".
>  This color is used by the geometry window. is it
>  use for other windows?

It is used in FvwmScript-NoteMessage. Btw, maybe make this script to be
like 3d button? I.e. it will look like a big feedback window.

> Colorest 1 and 2: Colorset, HilightColorset
>  The colors of the shaded and hilight part of the title bar of
>  a window (with and without the focus), the color of the icons title
>  bar. Colors of the windows of FvwmPager. Is these colors used in othe
>  situation?
>  Note that we will not use this color for setting the color of the 
>  normal part of the title bar of a window. For this we use
>  TitleStyle and ButtonStyle (in general) because these commands are
>  more powerful that the above style.
> 
> Colorest 3 and 4: BorderColorset,  HilightBorderColorset
>  Colors of the borders of the windows
> 
> Colorset 5, 6 and 7: colorset for menu: as now

Ok.

> Colorset 8, 9: reserved for future use! is it a good idea to reserve 
> intermediate colorsets? Or do we have to put it all at the end?

I don't know.

> * Modules Colorsets
> -------------------
> 
> Colorset 10: default module colorset: FvwmPager FvwmButtonColorset. 
>  Can be use for *FvwmIconMan*Colorset FvwmIconBoxColorset (see also
>  colorset 12)
> 
> Colorset 11: hilight default colorset: for hilighting a part of 
>  of an FvwmButton or a certain swallowed applications.
> 
> Colorset 12: special colorset: as 10 but a more funny colors a gradien
>  or a pixmap.

I know you mean blackbox theme. Somehow I don't like the trick with
substituting another colorset at run time when using certain theme.
Maybe we should introduce an auto-conditional options in our CDDS, which
are like current user-definable options, but switch is done automatically
accourding to the given conditions. This way we don't need colorset 12.
colors@blackbox can simply have this auto option. This breaks the Jos
idea of parsing colors@ components externally, but it is already broken in
colors@cde anyway, and probably there is nothing we can do about this.

> Colorset 13: Pager hilight colorset

Can't colorset 11 be used for this? I don't quite understand colorset 11.

> Colorset 14: tips colorset (Pager, TaskBar)
> 
> Colorset 15: colorsets for swallowed applications

Maybe swallowed applications should use colorsets 10/11? I don't know.

> Colorset 16: colorset for more colors in a swallowed application
>  (e.g., xclock & xload have -hl & -hd color)

My previous idea to have -hl & -hd in one colorset (fg/bg) pobably can't
work, because black/black is bad for bg/fg and I don't want to make this
xclock/xload specific. On the other hand I have no better ideas.

> Colorset 17: colorset for a normal button in the AppMans (IconBox, IconMan,
>  TaskBar, WinList)

AppMan name is ok, but I like more a generic name WinList for modules that
show a list of windows. :)  AppList? But why app, it handles any window,
it may be several windows per application. Somewhat off-topic.

> Colorset 18: colorset for a button which represent a window
>  with the focus in the AppMans.
> 
> Colorset 19: colorset for a button which represent an iconified
>  window in the AppMans.

Still 3 colorsets for WinLists? There are so many boolean window states
like iconified (maximized, shaded, sticky, visible), some of them may be
supported in some feature, maybe to leave a colorset for this additional
state? Or a bad idea?

But at least we need a way to mark a selected window button (i.e. the one
with a mouse pointer on it). FvwmIconMan supports this. Alex wanted this
and I promissed to do something here.

> Colorset 20: FvwmIdentColorset
> 
> Colorset 21: FvwmScrollColorset (do we need this colorset, colorset 32 is
>   ok? or Colorset 0?)

Or 10. :) Well, probably we don't need this, but what colorset to use?
Is it a good idea to suggest colorset 0 *or* 32 for FvwmScrollColorset?

> Colorset 22: FvwmConsole

Don't you like it to be the same color as a root term? :)

> Colorset 23: dynamic colorset (a colorset that can change during use
>   without affecting the whole look, e.g., for FvwmScript-ColorsetBrowser)

Ok, temporary colorset. But should it belong to module colorsets?

> Colorset 24 to 25: reserved for modules themes
> 
> Colorset 26 to 29: reserved for future use
> 
> * Applications colorsets (Form and Script are here!)
> 
> Colorset 30: default (text) colorset for terminal like application
>   (E.g., xterm in our menu)
> 
> Colorset 31: (text) colorset for remote shell/applications
> 
> Colorset 32: (text) root colorset

We need a special term colorset (current 22), we use it in a special xterm
viewer windows (top/less/tail -f), I worry about it more than about a root
term colorset. Root term is not even that some people have, maybe to call
it admin term colorset and include FvwmConsole term in it? :) Anyway in
the future FvwmConsole will be FvwmCommand in xterm.

I think it is ok to have a separate colorset for special viewers and text
editors. The following was supposed to be should be 33, I think.

> Colorset 31: default text colorset (the editors for xres, input text
>   zone of Form and Script , ...)

I don't use GUI text editors, so I don't worry too much whether they
should be like forms or not.

> Colorset 32: default colorset for the other part of the applications
>  (normal color of Form and Script, no text part of an app: menu buttons 
>  in emacs ...) 
> 
> Colorset 33: special applications colorset (for hilight)
> 
> Colorset 34 - 35: Reserved for future use.
> 
> Ok, so users colorsets can go from 36 to infinity ...

I.e. 38+ giving that we have two 31 and 32. Let say 40+ to be more sure.

> So, Do we have enought colorset? Do I forget something?
> Any suggestions?

Not for now. You should take here some decisions and implement it.

Regards,
Mikhael.

CVS and a question

[Olivier C. <oli...@fr...>]

CVS: Add some fvwm-themes-images backgrounds in multichoice 
     and replace xv + bggen when this is possible (ft-images + 
     xsetroot seem more fast :)
     Fix a random pattern bug

I think it will be good to change the default background.
Any idea?

Olivier

PS: adding files seems to work :)
PS: I think it is good idea to send a message when we commit.