fvwm-themes-devel — Developing FVWM Themes

start-stop and more

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

Hello,
I think that the start+stop ft cfg cmd is to general. I think
we should split this cfg option:

- start+stop
        as it is at the present time, but if there is a load/reload
        function the start function is not executed when the load/reload
        function should be executed and if there is an unload/prereload
	function the stop function is not executed when the unload/prereload
	function should be executed.
- load+unload=Name
	FuncFvwmLoadName is executed at startup and the functions 
	FuncFvwm(Un)LoadName are executed only if the state of the
	component change for a theme switching.
- reload+prereload=Name
        the functions FuncFvwm(Pre)ReLoadName are executed only if
        the state of the component does not change (already loaded).

These is useful if we have a component with variants, says A and B where
variant A should start an application (e.g., FvwmNetHints) which
must never stop as variant B should not used this application. At
a theme switching either:
 - the state of the component does not change: with variant A we
   should not restart the application, but we may have to execute
   some fvwm cmd (with ewmh support we should not restart FvwmNetHints
   but we have to override some bindings). The reload+prereload
   functions are executed.
 - Or the state of the component change: if we go from A to B we should
   stop the application (e.g., FvwmNetHints) and if we go from B to A
   we should start it. The load+unload functions are executed.  

Moreover, in the reload+prereloaed case we may want to change the
Read command and add 2 ft cfg option:
	read-reload=file # maybe empty to read nothing
	read-command-reload=cmd
if one of this cfg option is present and the state of the component
does not change the "normal" read(-command) is override by the
previous command.

Then we are not far to complete the ccds as that we have to define is
when the state of a component change using the dependencies rule.
But let us first implement/discus the above cmds with the simple
rule that the state of a component change if it is loaded for the
first time or if its appear in a fvwm-themes-config option (maybe
via a variant or an option). Of course in this case the previous
new cfg option will be useful only for a few component.

Ah, I am not sure that the previous names are ok. For example,
maybe restart/prerestart will be better than reload/prereload.

Regards, Olivier

Re: releasing 0.5.0

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

On Sun, Jul 29, 2001 at 07:00:48AM +0000, Mikhael Goikhman wrote:
> On 28 Jul 2001 06:26:12 +0200, Olivier Chapuis wrote:
> > 
> > On Sun, Jul 22, 2001 at 10:44:17PM +0000, Mikhael Goikhman wrote:
> > > I think everything is ready for 0.5.0.
> > 
> > What is your plan now?
> 
> Since I started to add globallook component, my plan is to finish it.
> 
> I also want to replace colors@default unless anyone objects, gray and gray
> seemed good some time ago, but now I think it could be more attractive;
> simple non-gradient color scheme, not too gray, not too colorish. I also
> don't like very much different violet colors used in the current default.
> Any suggestions for a new color scheme, like pointing to some screenshot?
> 

I've no objection for changes in the default colors
 
> > I've work on fvwm-themes-config and I do not want to commit the
> > change if we want to release a new release soon.
> > 
> > The second reason I do not commit it is that the change may
> > need discussion. What I want to do is a new .cfg config option
> > of the form
> > 
> > 	system-requires="test"
> > 
> > for component (and also maybe for individual variant).
> > This command will cause ft to hide the component if the "test"
> > has a negative answer. This will not slow down theme switching
> > as this commands will be take in account only in a "no cache
> > situation" (e.g., with "refresh with no cache").
> > This is useful for hiding some settings component as stroke if
> > the fvwm2 of the user does not support it. Also, we may use
> > this, for example, for multibyte support and to add support
> > for fvwm-ewmh. 
> 
> I don't know, if you can finalize it in several days, do it.
> A simplicity of the solution would be a plus.
> 
> I see some problems here. What happens if the default variant or option
> item is hidden. Or it's required that the default has no system-requires?

Yes no system-requires for the default variant.

> Can the default itself be conditional? This returns us to the old
> discussion whether to add gnome-session support or KDE menus automatically
> when something is detected (I think no). Or maybe even to use "external
> wm-icons" instead of "internal wm-icons" if `wm-icons-config --version |
> perl -pe '/([\d.]+)/ && $1 gt "0.3" && exit 0 || exit 1'` returns 0.
> 

No I do not do things like this, default are default and system-requires
do not change it. But we may have an other point of view in the future ...

Regards, Olivier

Re: releasing 0.5.0

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

On 28 Jul 2001 06:26:12 +0200, Olivier Chapuis wrote:
> 
> On Sun, Jul 22, 2001 at 10:44:17PM +0000, Mikhael Goikhman wrote:
> > I think everything is ready for 0.5.0.
> 
> What is your plan now?

Since I started to add globallook component, my plan is to finish it.

I also want to replace colors@default unless anyone objects, gray and gray
seemed good some time ago, but now I think it could be more attractive;
simple non-gradient color scheme, not too gray, not too colorish. I also
don't like very much different violet colors used in the current default.
Any suggestions for a new color scheme, like pointing to some screenshot?

> I've work on fvwm-themes-config and I do not want to commit the
> change if we want to release a new release soon.
> 
> The second reason I do not commit it is that the change may
> need discussion. What I want to do is a new .cfg config option
> of the form
> 
> 	system-requires="test"
> 
> for component (and also maybe for individual variant).
> This command will cause ft to hide the component if the "test"
> has a negative answer. This will not slow down theme switching
> as this commands will be take in account only in a "no cache
> situation" (e.g., with "refresh with no cache").
> This is useful for hiding some settings component as stroke if
> the fvwm2 of the user does not support it. Also, we may use
> this, for example, for multibyte support and to add support
> for fvwm-ewmh. 

I don't know, if you can finalize it in several days, do it.
A simplicity of the solution would be a plus.

I see some problems here. What happens if the default variant or option
item is hidden. Or it's required that the default has no system-requires?
Can the default itself be conditional? This returns us to the old
discussion whether to add gnome-session support or KDE menus automatically
when something is detected (I think no). Or maybe even to use "external
wm-icons" instead of "internal wm-icons" if `wm-icons-config --version |
perl -pe '/([\d.]+)/ && $1 gt "0.3" && exit 0 || exit 1'` returns 0.

I see almost no cases when defaults should be conditional. Maybe use stroke
support if `fvwm-config --supports-stroke`, but even this is questionable.
Saying all this, I am not against to try something new.

Regards,
Mikhael.

Re: releasing 0.5.0

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

On Sun, Jul 22, 2001 at 10:44:17PM +0000, Mikhael Goikhman wrote:
> I think everything is ready for 0.5.0.

What is your plan now?

I've work on fvwm-themes-config and I do not want to commit the
change if we want to release a new release soon.

The second reason I do not commit it is that the change may
need discussion. What I want to do is a new .cfg config option
of the form

	system-requires="test"

for component (and also maybe for individual variant).
This command will cause ft to hide the component if the "test"
has a negative answer. This will not slow down theme switching
as this commands will be take in account only in a "no cache
situation" (e.g., with "refresh with no cache").
This is useful for hiding some settings component as stroke if
the fvwm2 of the user does not support it. Also, we may use
this, for example, for multibyte support and to add support
for fvwm-ewmh. 

Olivier

wm-icons categories

[Paul D. S. <pau...@no...>]

It seems some useful categories are still missing from wm-icons:

  calendar
  spreadsheet
  dictionary

And maybe, spell-checker?

Sorry, I'm lame and I don't have any samples :(

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <ps...@ba...>    HASMAT--HA Software Methods & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

Re: Missing file?

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

Mikhael Goikhman wrote:
> 
> On 23 Jul 2001 22:53:27 +0930, Alex Wallis wrote:
> >
</snip>
> If you still have this (empty) directory multichoice/colors execute:
> "cvs update -P", and add "update -d -P" line into ~/.cvsrc.
> 
Hmmm... I had 2 lines with update -d -P in my .cvsrc
Probably explains the problems I've been having.
Working now. Thanks.

Alex

Re: Missing file?

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

On 23 Jul 2001 22:53:27 +0930, Alex Wallis wrote:
> 
> I just noticed that the multichoice/colors/main file appears to be
> absent from the current cvs. An oversight perhaps?

The colors@multichoice component was removed, It was only to demonstate
the functionality of variants, there are now more functional multichoice
components to demonstate this functionality.

If you still have this (empty) directory multichoice/colors execute:
"cvs update -P", and add "update -d -P" line into ~/.cvsrc.

Regards,
Mikhael.

Missing file?

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

I just noticed that the multichoice/colors/main file appears to be
absent from the current cvs. An oversight perhaps?

Alex

Re: releasing 0.5.0

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

On Sun, Jul 22, 2001 at 10:44:17PM +0000, Mikhael Goikhman wrote:
> I think everything is ready for 0.5.0.
> There are small things like completing doc/colorsets, tests of new stuff.
> 
> There is the today's snapshot of fvwm-themes-0.5.0 from cvs at:
> 
>   http://fvwm-themes.sourceforge.net/tmp/
> 
> A smooth colors-decor@ integration was not done, but it is not critical.
> I though about adding a new component globallook@, which may contain
> the static parts of colors@; in this component we may call a function
> FuncFvwmTitleStyle which is defined in colors@ and colors-decor@.
> It is a good time to add new a component, since we already added 2,
> but this requires some thoughs. Olivier?
> 

I am not against to delay a bit 0.5.0 to get the "smooth colors-decor@
integration" because we may hope that if it is done, then we do not
need to change the ft component logic for some times.

> -==-
> 
> Mike, you said 1.5 months ago you will reply in a week after testing new
> fonts@ stuff. Most of fonts@multichoice variants, i.e. Korean, Japanese
> and Chenese, are untested. You should have in mind that fonts@ component
> does not solve internationalization problems (we may have i18n@ component
> in the future for this), it only solves fonts problem.
>

About internationalization I've started to work with Mike ColorSelector
patch recently. I've modified a bit the patch and this leads me to
a FvwmScript core dump that I've fixed in fvwm-2.4.1-beta1. I will
merge Mike patch when fvwm-2.4.1 will be released. The main problem
with ja is the size of the characters, which for example gives to
long line with the ColorSelector in-line doc. Mike are lines of 30
ja characters is ok for a Japanese user?

>
> -==-
> 
> About dividing the package into 2 tarballs/rpms - fvwm-themes-base
> and fvwm-themes-extra. Since fvwm.themes.org is off, such division may
> be done later; for now I would probably stay with one tarball as usual.
> Any objections?
> 
> Olivier, do you want to do a release with package division as you see it?
>

Again I think that if we release 0.5.0 as we change the major number
we "should" use the new packaging division. It will be strange to change
the packaging division with 0.5.1.

Any way, Mikhael, if you want to release 0.5.0 as it is described in
your mail I've no serious objection. The objections above are just
of cosmetic nature. An other possibility is to release 0.4.2.
   
Regards, Olivier

PS: I am in holidays for the next 30 days :o). My internet access is
limited but ok (I read my mail every day around 5:00 GTM). I've
planned to work on fvwm-themes during this period.

releasing 0.5.0

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

I think everything is ready for 0.5.0.
There are small things like completing doc/colorsets, tests of new stuff.

There is the today's snapshot of fvwm-themes-0.5.0 from cvs at:

  http://fvwm-themes.sourceforge.net/tmp/

A smooth colors-decor@ integration was not done, but it is not critical.
I though about adding a new component globallook@, which may contain
the static parts of colors@; in this component we may call a function
FuncFvwmTitleStyle which is defined in colors@ and colors-decor@.
It is a good time to add new a component, since we already added 2,
but this requires some thoughs. Olivier?

-==-

Mike, you said 1.5 months ago you will reply in a week after testing new
fonts@ stuff. Most of fonts@multichoice variants, i.e. Korean, Japanese
and Chenese, are untested. You should have in mind that fonts@ component
does not solve internationalization problems (we may have i18n@ component
in the future for this), it only solves fonts problem.

-==-

About dividing the package into 2 tarballs/rpms - fvwm-themes-base
and fvwm-themes-extra. Since fvwm.themes.org is off, such division may
be done later; for now I would probably stay with one tarball as usual.
Any objections?

Olivier, do you want to do a release with package division as you see it?

Regards,
Mikhael.

Re: Multichoice buttons errors

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

On 16 Jul 2001 04:06:39 +0930, Alex Wallis wrote:
> 
> I think the "fix" is, but it's not pretty, to completely rm -rf the
> auto-button/ directory at each change.

This would be on any start/restart/load/reload not only on the change.
I though about using "tar d" for checking that the current images are
exactly as in tarball and untar only if not matched. The problem is that
the current images are never exact - file's user and group are different.
Even worse, "tar d" is not portable, Solaris does not have this option...

> > And why tar does not override symlinks, it should.
> 
> >   % tar --version
> 
> awol@awol:~/.fvwm/themes > tar --version
> tar (GNU tar) 1.12

Seems like this tar version is broken. It does not override existing
symlinks and there is no option to force this. tar 1.13.17 is ok.

If you want to ensure this version is broken (don't need to reply), run:

  % cd ~/.fvwm/themes/current/images/auto-button
  % tar xzf /PATH/themes/multichoice/buttons/images/FACE.tar.gz
  % .. repeat tar with other face tarballs

I will think more about an acceptable solution.

Regards,
Mikhael.

Re: Multichoice buttons errors

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

Mikhael Goikhman wrote:
> 
> On 12 Jul 2001 21:02:12 +0930, Alex Wallis wrote:
> >
<snip> 
> It is strange. Please investigate it.

Okay! Took some time to figure it out, but...

It seems I get inconsistant directory listings when I change multichoice
buttons.
After each switch, I rm -rf auto-button/ and did a refresh (no cache)
and then ls -al and most times there were differences. Sometimes, but
not often, it would create the symlink loops. Some of the buttons have a
different number of corresponding xpm's it seems. Some more, some less,
some with more symlinks, some with just a few.

I think the "fix" is, but it's not pretty, to completely rm -rf the
auto-button/ directory at each change.

OR

To spend time refining the component so that each choice has _exactly_
the same number of xpm's and filenames and ensuring that at a change
they are all replaced with the new choice.

> How session manager (gnome-session?) is related to this.

Not entirely sure here, but I think it was because I was using a session
with the bad directory whereas a normally started X didn't. (Yes, I was
using gnome-session, it works great too! :)

> And why tar does not override symlinks, it should.

I don't think the symlinks were all being replaced at once. Sometimes
the component choices only changed most of the xpm's but not all. When
there was circular symlinking tar would try to follow the links but got
lost going around in circles. (see example below) Removing the directory
obviously fixes this.

> 
> > Let me know if you need more info, or want me to try some commands.
> 
> Try to remove auto-button/* and then Restart or Reload.

I did that... a lot!

> Try to reproduce the problem (load Mac & ShinyMetal). Send me output of:
> 
>   % tar --version

awol@awol:~/.fvwm/themes > tar --version
tar (GNU tar)
1.12                                                                                        

>   % fvwm-themes-config --component buttons --show-info

awol@awol:~/.fvwm/themes > fvwm-themes-config --component buttons
--show-info
Theme:      multichoice (5 components)
Component:  buttons
Properties: 3 options (12 * 19 * 2 choices)
Current:    Titlebar Button Face: Mac (Olicha); Titlebar Button Order:
Options, Stick   [ new ] Iconify, Maximize, Close; Options Button:
Application mini icon
Read File: 
/opt/fvwm/themes/multichoice/buttons/main                                 

The above is when I actually have no buttons showing at all except the
application mini-icon.

The directory listing of auto-button shows...
awol@awol:~/.fvwm/themes > ls -al current-main/images/auto-button/
total 12
drwxr-xr-x   2 awol     users        1024 Jul 16 02:20 .
drwxr-xr-x   3 awol     users        1024 Jul 16 00:40 ..
-rw-r--r--   1 awol     users         611 Jul  8 23:53
close-activedown.xpm
lrwxrwxrwx   1 awol     users          18 Jul 16 01:44
close-activeup.xpm -> close-inactive.xpm
lrwxrwxrwx   1 awol     users          18 Jul 16 02:20
close-inactive.xpm -> close-activeup.xpm
-rw-r--r--   1 awol     users         625 May 26 21:27
iconify-activedown.xpm
lrwxrwxrwx   1 awol     users          20 Jul 16 01:44
iconify-activeup.xpm -> iconify-inactive.xpm
lrwxrwxrwx   1 awol     users          20 Jul 16 02:20
iconify-inactive.xpm -> iconify-activeup.xpm
-rw-r--r--   1 awol     users         626 May 26 21:28
maximize-activedown.xpm
lrwxrwxrwx   1 awol     users          21 Jul 16 01:44
maximize-activeup.xpm -> maximize-inactive.xpm
lrwxrwxrwx   1 awol     users          21 Jul 16 02:20
maximize-inactive.xpm -> maximize-activeup.xpm
-rw-r--r--   1 awol     users         610 Jul  8 23:50
options-activedown.xpm
lrwxrwxrwx   1 awol     users          20 Jul 16 01:44
options-activeup.xpm -> options-inactive.xpm
lrwxrwxrwx   1 awol     users          20 Jul 16 02:20
options-inactive.xpm -> options-activeup.xpm
-rw-r--r--   1 awol     users         610 Jul  8 23:50
shade-activedown.xpm
lrwxrwxrwx   1 awol     users          18 Jul 16 01:44
shade-activeup.xpm -> shade-inactive.xpm
lrwxrwxrwx   1 awol     users          18 Jul 16 02:20
shade-inactive.xpm -> shade-activeup.xpm
-rw-r--r--   1 awol     users         623 Jul  6 05:44
stick-activedown.xpm
lrwxrwxrwx   1 awol     users          18 Jul 16 01:44
stick-activeup.xpm -> stick-inactive.xpm
lrwxrwxrwx   1 awol     users          18 Jul 16 02:20
stick-inactive.xpm -> stick-activeup.xpm
lrwxrwxrwx   1 awol     users          22 Jul 16 01:43
titleleft-activedown.xpm -> titleleft-activeup.xpm
-rw-r--r--   1 awol     users         744 Apr 30 11:24
titleleft-activeup.xpm
-rw-r--r--   1 awol     users         729 Apr 30 11:24
titleleft-inactive.xpm
lrwxrwxrwx   1 awol     users          23 Jul 16 01:43
titleright-activedown.xpm -> titleright-activeup.xpm
-rw-r--r--   1 awol     users         729 Apr 30 11:24
titleright-activeup.xpm
-rw-r--r--   1 awol     users         714 Apr 30 11:24
titleright-inactive.xpm 

So does this help you? Hope so.

Many thanks

Alex

Re: Multichoice buttons errors

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

On 12 Jul 2001 21:02:12 +0930, Alex Wallis wrote:
> 
> I get a heap of lines like this in my X error log...
> 
> tar: close-activeup.xpm: Could not create file: Too many levels of
> symbolic links                        
>  
> followed by a heap of lines like...
> 
> [FVWM][ReadDecorFace]: <<ERROR>> couldn't load pixmap
> auto-button/options-activeup.xpm
> 
> Looking into $HOME/.fvwm/themes/current-main/images/auto-button/ I find
> the symlinks go round in circles like....
> 
> lrwxrwxrwx   1 awol     users          18 Jul 12 12:45
> close-activeup.xpm -> close-inactive.xpm
> lrwxrwxrwx   1 awol     users          18 Jul 12 19:35
> close-inactive.xpm -> close-activeup.xpm 
> 
> Now if I don't use a session manager, and just restart X normally, the
> Multichoice buttons usually works as intended, but I haven't fully
> investigated this. I will if you want me to, but I'm hoping that the
> problem I'm having is obvious and easily resolved.

It is strange. Please investigate it.
How session manager (gnome-session?) is related to this.
And why tar does not override symlinks, it should.

> Let me know if you need more info, or want me to try some commands.

Try to remove auto-button/* and then Restart or Reload.
Try to reproduce the problem (load Mac & ShinyMetal). Send me output of:

  % tar --version
  % fvwm-themes-config --component buttons --show-info

Regards,
Mikhael.

Multichoice buttons errors

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

I've been meaning to point this out for awhile now, but I waited to see
if anyone noticed this and fixed it first.

I get a heap of lines like this in my X error log...

tar: close-activeup.xpm: Could not create file: Too many levels of
symbolic links                        
 
followed by a heap of lines like...

[FVWM][ReadDecorFace]: <<ERROR>> couldn't load pixmap
auto-button/options-activeup.xpm

Looking into $HOME/.fvwm/themes/current-main/images/auto-button/ I find
the symlinks go round in circles like....

lrwxrwxrwx   1 awol     users          18 Jul 12 12:45
close-activeup.xpm -> close-inactive.xpm
lrwxrwxrwx   1 awol     users          18 Jul 12 19:35
close-inactive.xpm -> close-activeup.xpm 

Now if I don't use a session manager, and just restart X normally, the
Multichoice buttons usually works as intended, but I haven't fully
investigated this. I will if you want me to, but I'm hoping that the
problem I'm having is obvious and easily resolved.

Let me know if you need more info, or want me to try some commands.

Alex

TE INFORMAMOS

[COFOR<co...@wa...>]

Jacarilla 8.7.2001.Publicidad/Enseñanza a Distancia 
 

      Hola que tal:
 
      El motivo de la presente carta es informarte de la posibilidad de poder 
realizar algún curso a distancia de tu interés, cursos relacionados con tu 
trabajo inquietudes  y ocio.ect.El conocimiento es el mayor patrimonio de 
que podemos disponer.
 
      Nos dedicamos desde 1996.a impartir cursos a distancia disponemos 
de una amplia variedad de cursos sencillos  para poder seguirlos 
comodamente desde cualquier parte del mundo y a unos precios muy 
competitivos.
      
 
NET
------------
Comercio Electrónico
Redes y Sistemas
Sistemas Servers
Diseño Web
Direccion Empresa Net
Management  Business
 
BUSSINES
------------
Gestor Comercial y Marketing
Marketing Mix 
Relaciones Publicas
Dirección Planificación de Empresa
Recursos Humanos
Comercio Exterior
Direccion Comercial
Gestión Medio Ambiental
Control de Calidad
 Management  Bussines
Dirección de Restaurantes
----------------------------------
 
SALUD SUPERACION PERSONAL
-------------------------------------
Superación de Estrés
Psicoterapia
Dietética y Nutrición
Dieta Mediterránea 
Nutrí terapia y Salud
Nutrición y Deporte
Cocina Sana
Monitor Aeróbic-Fittnes
Monitor Yoga Tai-Chi
Hipnoterapia
Quiromasaje y Reflexoterapia
Aromaterapia
Cosmética Natural
Hierbas Medicinales
Balnoterapia y Salud
--------------------------------------
Los cursos  son de 200.horas lectivas el precio standar por curso es de 
35.000.pts.España a plazos.Iberoamerica 150.usa dolar aplazados.
El Diploma:
 "Técnico Especialista"
 El tiempo aproximado por curso dependiendo de los conocimientos en 
areas similares de que se disponga,es entre 2-6.meses.aprox.
 
Si desean que les ampliemos información pueden enviar un e-mail les 
contestaremos con la mayor brevedad y les indicaremos nuestro espacio 
web que se encuentra en reformas.
 
Envie e-mail:
      co...@wa...
     CO...@te... 
 
Sin otra que rogarte me envies un e-mail si estas interesado/a
Te enviamos un saludo.
 Merce Sanchez 
Gestión Integral 1.S.L
 C/ Virgen de Belén, 30
 03310 Jacarilla  (Alicante)ESPAÑA
 
Si desea no recibir mas  e-mail. MA...@te...
                                                                                                                    
                                     

 
 
 
 
 
 
 
      

FYI What is happening at fvwm.themes.org

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

FYI...


I'm doing ok now and so is my cat. 
For about a month we both had to sleep on lounge room floors at friends.
I've moved into a nice clean single bedroom place, where no-one can tell
me what to do and when to do it. Except Bob(my cat) of course.

Of even greater distress is the current state of themes.org which is
just a hastily resurrected backup.
I've been told that no new anything will be accepted until the new
server is made operational in about a months time. That means from now
until then, no mention of fvwm will be available on themes.org! I find
this unacceptable but there is nothing that can be done about it.  :(

Since last xmas I have been quite vocal in my desire to have everything
ready for the fvwm2.4 release. As Olivier might say.... "C'est la vie!"
I hope the FBI can get that hacker that caused these hassles.

When the new t.o server becomes operational all WM's will be treated
equally with no sub-sites as such. I will let you know more when I find
out. There's a dev.themes.org server for testing so I'll give you a URL
to check when it's ready.



Alex

Re: package builds fail

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

On 17 Jun 2001 01:14:25 +0930, Alex Wallis wrote:
> 
> I'm currently homeless and so have difficulty getting online or working
> on my computer, but....

I hope it is not as sad as it sounds...

> I've found since the changes Mikhael committed to configure.in recently
> package builds fail.

You are right, I didn't test it fully. Fixed.

Regards,
Mikhael.

Re: [OT] fvwm.org disappeared?

[Andre G. <abg...@uw...>]

On Mon, Jun 18, 2001 at 06:19:02AM +0200, Olivier Chapuis wrote:
> On Sun, Jun 17, 2001 at 06:52:13PM +0200, Andre Goeree wrote:
> > Hello fvwm-themes-devel,
> > 
> > For several days now, i'm trying to update my fvwm source tree.
> > Somehow the host cvs.fvwm.org (in fact all of fvwm.org) is not found. 
> > 
> > This could well be a problem with a DNS server underway, i can reach
> > one of fvwm.org's nameservers, but my idea is that the whole site is
> > off the web. Am i correct? And if, what happened? (has the site moved).
> > 
> > Any comments would be appreciated, please send/CC replies off-list
> > (I'm not on this list).
> > 
> > I'm sending this message to fvwm-themes-devel because the fvwm-workers
> > list seems to be unreachable too.
> >
> 
> Yes, it seems that fvwm.org is completely down. I do not know
> the reason. Mikhael has the flowing info:
> 
>   "My info is, the problems with fvwm.org is due to hurricane in Texas,
>    they in the university work to fix all electricity and water problems."
> 
> I hope that fvwm.org will be up again soon ...
> 
> You can find 2.3.32 fvwm i386 rpm via the fvwm-themes site and
> you can also find 2.3.32 tarball in some !fvwm.org site as:
> 
>  http://ftp.lip6.fr/ftp/pub/X11/fvwm/
> 
> Regards, Olivier
> 

Thanks for the information.

Regards,
--Andre. 

Re: [OT] fvwm.org disappeared?

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

On Sun, Jun 17, 2001 at 06:52:13PM +0200, Andre Goeree wrote:
> Hello fvwm-themes-devel,
> 
> For several days now, i'm trying to update my fvwm source tree.
> Somehow the host cvs.fvwm.org (in fact all of fvwm.org) is not found. 
> 
> This could well be a problem with a DNS server underway, i can reach
> one of fvwm.org's nameservers, but my idea is that the whole site is
> off the web. Am i correct? And if, what happened? (has the site moved).
> 
> Any comments would be appreciated, please send/CC replies off-list
> (I'm not on this list).
> 
> I'm sending this message to fvwm-themes-devel because the fvwm-workers
> list seems to be unreachable too.
>

Yes, it seems that fvwm.org is completely down. I do not know
the reason. Mikhael has the flowing info:

  "My info is, the problems with fvwm.org is due to hurricane in Texas,
   they in the university work to fix all electricity and water problems."

I hope that fvwm.org will be up again soon ...

You can find 2.3.32 fvwm i386 rpm via the fvwm-themes site and
you can also find 2.3.32 tarball in some !fvwm.org site as:

 http://ftp.lip6.fr/ftp/pub/X11/fvwm/

Regards, Olivier

Re: nanoGUI colors-decor

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

On Thu, Jun 14, 2001 at 10:56:16PM +0000, Mikhael Goikhman wrote:
> On 31 May 2001 13:42:30 +0200, Olivier Chapuis wrote:
> > 
> > On Thursday 31 May 2001 11:59, you wrote:
> > >
> > > I would like this solution with colors-decor@ if not some small things.
> > > It is probably ok when colorsets are defined twice, but it is not ok when
> > > TitleStyle is defined twice, there is blinking. The solution would be to
> > > divide colors@ to several parts, each defines its own function (for decor,
> > > menu, modules), which are called from in StartColors function, so other
> > > components like colors-decor would overwrite one of such functions.
> > > Or maybe just add a function for TitleStyle commands. This also would
> > > fix a current problem that image dir ~/.fvwm/themes/current/images/decor
> > > should be linked as defined in colors@ and not in colors-decor@.
> > >
> > > Do you think it is good to change colors@ as I described?
> > 
> > Yes I think this is ok, say a function for TitleStyle.
> 
> Now, the question is when this function will be called. It should be
> called after colors@ and before buttons@. The simplest solution is to call
> this function in buttons@ component, but this solution seems strange.
> Another solution is to define a new component property "start" or similar,
> to start the specified function(s) immediately after all components which
> define this function (in our case, colors and colors-decor) are read.
> Can this feature be useful in other places, like settings?
>

Do what you think is the best solution :o)
 
> > Brushedmetal and nanoGUI are a bit problematic in some points
> > (as blackbox was at the begining). I do not know if we can do
> > the buttons of these themes more compatible with the other
> > themes. I would like to think about this, but probably not
> > now because I leave my house for a new one in the next
> > few days. Any way it seems to me that adding a function for
> > the titlestyle can only help.
> 
> We already have Mech, so there are 3 themes of this type, and I hope
> this is not the last theme of Kristian, so we should support this type.
>

Yes, but what about an automatic loading/unloading of colors-decor@foo
and windowlook@foo when loading/changing such special buttons@foo
component.
  
> -==-
> 
> Another topic. What do we do with fonts for modules? Olivier, do you want
> to work on this?

Yes, I will take a look to this topic.

> 
> -==-
> 
> P.S. My info is, the problems with fvwm.org is due to hurricane in Texas,
> they in the univercity work to fix all electricity and water problems.
>

The problem is when fvwm.org will be up again.

Regards, Olivier 

[OT] fvwm.org disappeared?

[Andre G. <abg...@uw...>]

Hello fvwm-themes-devel,

For several days now, i'm trying to update my fvwm source tree.
Somehow the host cvs.fvwm.org (in fact all of fvwm.org) is not found. 

This could well be a problem with a DNS server underway, i can reach
one of fvwm.org's nameservers, but my idea is that the whole site is
off the web. Am i correct? And if, what happened? (has the site moved).

Any comments would be appreciated, please send/CC replies off-list
(I'm not on this list).

I'm sending this message to fvwm-themes-devel because the fvwm-workers
list seems to be unreachable too.

Regards,
-- Andre.

package builds fail

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

I'm currently homeless and so have difficulty getting online or working
on my computer, but....

I've found since the changes Mikhael committed to configure.in recently
package builds fail.
I end up with a fvwm-themes-base-0.4.3-pre-release.tar.gz which contains
ALL the themes and no themes in the extras package and the individual
themes do not get made at all.
This happens with all forms of make dist like dist2, dist3 etc...
It looks like some kind of typo as i get lines in the build like...

creating ft-@EXTRA_THEMES@-0.4.3.tar.gz

However changing the Makefile to read...

EXTRA_THEMES = awol blackbox brushedmetal mech nanogui osx spruce unsafe

I get the tarballs of the "extra" themes. I haven't worked out how to
fix the ft-*.rpm's yet.

Was this intentional? Perhaps a note is needed somewhere about this?


Alex

Re: nanoGUI colors-decor

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

On 31 May 2001 13:42:30 +0200, Olivier Chapuis wrote:
> 
> On Thursday 31 May 2001 11:59, you wrote:
> >
> > I would like this solution with colors-decor@ if not some small things.
> > It is probably ok when colorsets are defined twice, but it is not ok when
> > TitleStyle is defined twice, there is blinking. The solution would be to
> > divide colors@ to several parts, each defines its own function (for decor,
> > menu, modules), which are called from in StartColors function, so other
> > components like colors-decor would overwrite one of such functions.
> > Or maybe just add a function for TitleStyle commands. This also would
> > fix a current problem that image dir ~/.fvwm/themes/current/images/decor
> > should be linked as defined in colors@ and not in colors-decor@.
> >
> > Do you think it is good to change colors@ as I described?
> 
> Yes I think this is ok, say a function for TitleStyle.

Now, the question is when this function will be called. It should be
called after colors@ and before buttons@. The simplest solution is to call
this function in buttons@ component, but this solution seems strange.
Another solution is to define a new component property "start" or similar,
to start the specified function(s) immediately after all components which
define this function (in our case, colors and colors-decor) are read.
Can this feature be useful in other places, like settings?

> Brushedmetal and nanoGUI are a bit problematic in some points
> (as blackbox was at the begining). I do not know if we can do
> the buttons of these themes more compatible with the other
> themes. I would like to think about this, but probably not
> now because I leave my house for a new one in the next
> few days. Any way it seems to me that adding a function for
> the titlestyle can only help.

We already have Mech, so there are 3 themes of this type, and I hope
this is not the last theme of Kristian, so we should support this type.

-==-

Another topic. What do we do with fonts for modules? Olivier, do you want
to work on this?

-==-

P.S. My info is, the problems with fvwm.org is due to hurricane in Texas,
they in the univercity work to fix all electricity and water problems.

Regards,
Mikhael.

Re: RPM request

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

On 14 Jun 2001 18:37:28 -0230, Neil Zanella wrote:
> 
> I get the following error on RHL 7.1:
> 
> rpm -i --test fvwm-*.rpm
> error: failed dependencies:
> 	libstroke.so.0 is needed by fvwm-2.3.32-1rh7
> 
> It would be nice if there was a libstroke RPM available at your site
> as well. AFAIK as I know libstroke development is dead. If this is the
> case then we might as well offer the RPM at the fvwm-themes site.
> If you like I can make the spec file unless one is already available
> of course. All feeback is appreciated.

There is a link on our RPM page to this support directory:

  http://fvwm-themes.sourceforge.net/rpm/support/

Also if you enter libstroke in rpmfind.org search, you may find rpms too.
Mandrake's one is good for RedHat. I use it (and libstroke-devel too).

Regards,
Mikhael.

RPM request

[Neil Z. <nza...@cs...>]

Hello,

I get the following error on RHL 7.1:

rpm -i --test fvwm-*.rpm
error: failed dependencies:
	libstroke.so.0 is needed by fvwm-2.3.32-1rh7

It would be nice if there was a libstroke RPM available at your site
as well. AFAIK as I know libstroke development is dead. If this is the
case then we might as well offer the RPM at the fvwm-themes site.
If you like I can make the spec file unless one is already available
of course. All feeback is appreciated.

Thanks,

Neil