fvwm-themes-devel — Developing FVWM Themes

Re: Quitting? and cvs error!

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

Mikhael Goikhman wrote:
> 
> On 19 Oct 2000 13:10:17 +0930, Alex Wallis wrote:
> >
> > Hi, I'm back....
>

Hello!
 
> 
> > Also, on another point, whenever I change themes, or components, or even
> > just an option, I get a No Buttons Defined. Quitting. error and then X
> > just gives up. This is using the Dali&kLo Buttons of course. And I've
> > found that the choice of buttons is not always represented in the
> > Current/Modules/Button Bar menu correctly.
> 
> Do you mean there is a wrong current choice in this menu or something
> else? Everything seems correct in this menu.
> 
> "No Buttons Defined" error may be caused by old fvwm, but you say you use
> the latest version from CVS. If true, I need more info, I can't reproduce
> "No Buttons Defined. Quitting." error.
> 
> However, I can consistently  reproduce fvwm core dump in free_icon_boxes
> when loading modules@awol and refreshing the current theme twice. There is
> no core dump when doing the same with modules@ from other themes. I need
> that someone (Olivier?) reproduce this core dump too, so I would know it
> is not related to my system, before I report this or try to fix it myself.
> 

Yes, I've this problem too and I do not see the problem with awol
modules. Note that when I've got such a core dump then I've the message:
FvwmButtons-DaLo: No buttons defined. Quitting in my X log.

Also, I've the following problems
FvwmButtons-DaLo: Couldn't load font
-b&h-lucida-medium-r-normal-sans-8-0-72-72-p-45-iso8859-1

I think we have to use 
-b&h-lucida-medium-r-normal-sans-8-0-75-75-p-45-iso8859-1
I've commited that plus some minor fix:
We alawys have to specify a geometry or RandomPlacement style
to applications which are swallowed, because ActivePlacement will
force to ask the user to place the swallowed apps!

Olivier

Re: Quitting? and cvs error!

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

On 19 Oct 2000 13:10:17 +0930, Alex Wallis wrote:
> 
> Hi, I'm back....

Nice.

> I'm now running the latest cvs of fvwm2 again, and a recent cvs of
> fvwm-themes. However....
> 
> cvs [server aborted]: read lock failed - giving up
> 
> Anyone know what's going on?

Try again, it may be temporary problems with cvs server.

> Also, on another point, whenever I change themes, or components, or even
> just an option, I get a No Buttons Defined. Quitting. error and then X
> just gives up. This is using the Dali&kLo Buttons of course. And I've
> found that the choice of buttons is not always represented in the
> Current/Modules/Button Bar menu correctly.

Do you mean there is a wrong current choice in this menu or something
else? Everything seems correct in this menu.

"No Buttons Defined" error may be caused by old fvwm, but you say you use
the latest version from CVS. If true, I need more info, I can't reproduce
"No Buttons Defined. Quitting." error.

However, I can consistently  reproduce fvwm core dump in free_icon_boxes
when loading modules@awol and refreshing the current theme twice. There is
no core dump when doing the same with modules@ from other themes. I need
that someone (Olivier?) reproduce this core dump too, so I would know it
is not related to my system, before I report this or try to fix it myself.

Regards,
Mikhael.

Quitting? and cvs error!

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

Hi, I'm back....
My box crashed badly during an attempted upgrade, then I got a job.
Working 12 hr plus days doing ISP tech support stuff, 6 or 7 days a
week, didn't leave much time nor inclination to reinstall my machine.

Anyway, the work dried up, and I've totally reinstalled 6 Gig of SuSe6.2
Linux.
I'm now running the latest cvs of fvwm2 again, and a recent cvs of
fvwm-themes. However....

My latest attempt at the usual commands produced....
awol@awol:~/cvs/fvwm-themes > cvs update
cvs server: Updating .
cvs server: failed to create lock directory in repository
`/cvsroot/fvwm-themes/fvwm-themes': Permission denied
cvs server: failed to obtain dir lock in repository
`/cvsroot/fvwm-themes/fvwm-themes'
cvs [server aborted]: read lock failed - giving up

Anyone know what's going on?

Also, on another point, whenever I change themes, or components, or even
just an option, I get a No Buttons Defined. Quitting. error and then X
just gives up. This is using the Dali&kLo Buttons of course. And I've
found that the choice of buttons is not always represented in the
Current/Modules/Button Bar menu correctly.

BTW: domivogt theme is way kewl!  :-)

Regards,

Alex

Re: modules@cde

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

On 12 Oct 2000 10:45:02 +0200, jos wrote:
> 
> Mikhael Goikhman wrote:
> 
> > > changing to a different color-scheme, in cde, the colors
> > > of some pixmaps are changed to fit with the new color-scheme.
> > > Is it also possible to do this in fvwm-themes?
> > 
> > Can you give an example, what colors exactly are changed in icons?
> > If it is only background, you can make it transparent.
> > 
> > And modules@cde should work even without colors@cde, say with colors@migo.
> > Please decribe the problem better and we will try to solve it.
> 
> Have a look at this example:
> 
> http://www.xs4all.nl/~josvanr/eg.png
> 
> which shows part of the cde toolbar. The horizontal stripes at 
> the left side, change their color when the color of the panel changes.
> I now use a grey-scale pixmap for the stripes, but to really make 
> it look nice, one would have to 'colorize' the pixmap using 
> the background color of the toolbar (colorset 10 I think). 
> This could also work with colors@migo I think, if the colorizing
> script were to be called in the modules@cde files. Maybe this could
> also be used to optionally adapt the colors of button-pixmaps to 
> the current color scheme. 
> 
> Making it transparent isn't good enough (well..), because using 
> dark stripes would then look bad on a dark background, and using 
> light stripes would look bad on a light background. 

If transparent solution is not good (maybe Transparent colorset can help
here?), there is another solution. It is a bit hacky, but there is no
better one for now. In themes/cde/modules/main put the following:

  AddToFunc FuncFvwmStartThemeModules
  + I Exec mkdir $FVWM_USERDIR/themes/current/images/cde-panel; \
    converting-script $FT_DATADIR/themes/cde/images/panel \
      $FVWM_USERDIR/themes/current/images/cde-panel $[fg.cs10] $[bg.cs10]
  + I *FvwmButtons-Panel: ...
  + I *FvwmButtons-Panel: Icon cde-panel/image1.xpm
  + I *FvwmButtons-Panel: ...

  AddToFunc FuncFvwmStopThemeModules
  + I Exec rm -r $FVWM_USERDIR/themes/current/images/cde-panel

The converting-script (say, fvwm-themes-images with some switch) gets 4
parameters: the source directory, the destination directory, the fore and
back colors, and converts all pixmaps in the source dir appropriately.

The main problem is that this all is executed not only on theme switching,
but also on Startup/Restart. We can think about a more optimal solution,
but it is hard to find a good generic solution, which will also correctly
syncronize the configuration parts. Say FvwmButtons-Panel module should be
defined after the images are converted. And images can't be converted
before colors@ is read...

> > > Also, I think I have to change some of the text-colors in
> > > the schemes, as cde uses different colors sometimes. For
> > > instance, in the default scheme, cde uses a white foreground
> > > color, not a black one.
> > 
> > You know, text colors were generated automatically by fvwm-themes-images
> > (see "COLORS SCHEMES" in the man page). --text-colors could be tweaked.
> 
> Oh, probably there is a different algorithm then, to choose 
> between black and white...

Please someone give me an idea about the real CDE foreground colors.
Is foreground always white (i.e. a constant for a given color scheme),
or different for different backgrounds?

Regards,
Mikhael.

Re: DestroyStyle

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

On 16 Oct 2000 18:19:53 +0200, Olivier Chapuis wrote:
> 
> Olivier Chapuis wrote:
> > 
> > I have made some modifications in modules@{aftersetp,awol,
> > blackbox,olicha} which may cause new core dumps:
> > all modules styles are moved in a file main:styles and
> > these styles are destroyed in FuncFvwmStopThemeModules.
> 
> I plan to do that for all modules themes. Any objections?

No objections.

Regards,
Mikhael.

Re: DestroyStyle

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

Olivier Chapuis wrote:
> 
> Hello,
> I have made some modifications in modules@{aftersetp,awol,
> blackbox,olicha} which may cause new core dumps:
> all modules styles are moved in a file main:styles and
> these styles are destroyed in FuncFvwmStopThemeModules.

I plan to do that for all modules themes. Any objections?

Olivier

Re: desktop

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

On 15 Oct 2000 21:00:57 +0200, Olivier Chapuis wrote:
> 
> Mikhael Goikhman wrote:
> > 
> > On 09 Oct 2000 11:52:38 +0200, Olivier Chapuis wrote:
> > >
> > > ok, but XORValue which should be moved into background
> > > (with XorPixmap).
> > 
> > Usually 50% or more of my screen is applications, so these commands are
> > as well can be included in colors@. Or maybe just leave it as is?
> 
> Ok, but we know the color of the background, but we do not know
> the colors all the applications. Any way, any objection for
> moving this in @color?

Probably these commands need not be themable like background@ or colors@,
I would leave them as is, but I let you decide here.

> > > I suggest to rename it major-modes but there are surely
> > > a better name. Any ideas?
> > 
> > I don't think that major-modes name is better than desktop.
> > Maybe "globals"? Or "globalstyles"? Hmm, how about "feel"? :)
> > I think we need some time to finalize its name... "commonfeel"?
> 
> Here I need a name. What about global-feel ?

I would prefer globalfeel spelling (like windowlook, menustyles).

Regards,
Mikhael.

Re: desktop

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

Mikhael Goikhman wrote:
> 
> On 09 Oct 2000 11:52:38 +0200, Olivier Chapuis wrote:
> >
> > Here my opinion on desktop.
> > First of all I think that the contenants of this file is
> > ok, but XORValue which should be moved into background
> > (with XorPixmap).
> 
> Usually 50% or more of my screen is applications, so these commands are
> as well can be included in colors@. Or maybe just leave it as is?
>

Ok, but we know the color of the background, but we do not know
the colors all the applications. Any way, any objection for
moving this in @color?
 
> 
> > Secondly, the name of this file is surely not good. It
> > contains the "Major Operating Modes" configuration, so
> > I suggest to rename it major-modes but there are surely
> > a better name. Any ideas?
> 
> I don't think that major-modes name is better than desktop.
> Maybe "globals"? Or "globalstyles"? Hmm, how about "feel"? :)
> I think we need some time to finalize its name... "commonfeel"?
> 

Here I need a name. What about global-feel ?

Olivier

Re: modules@cde

[jos <jo...@xs...>]

Hi!

Mikhael Goikhman wrote:
> > changing to a different color-scheme, in cde, the colors
> > of some pixmaps are changed to fit with the new color-scheme.
> > Is it also possible to do this in fvwm-themes?
> Can you give an example, what colors exactly are changed in icons?
> If it is only background, you can make it transparent.
> 
> And modules@cde should work even without colors@cde, say with colors@migo.
> Please decribe the problem better and we will try to solve it.

Have a look at this example:

http://www.xs4all.nl/~josvanr/eg.png

which shows part of the cde toolbar. The horizontal stripes at 
the left side, change their color when the color of the panel changes.
I now use a grey-scale pixmap for the stripes, but to really make 
it look nice, one would have to 'colorize' the pixmap using 
the background color of the toolbar (colorset 10 I think). 
This could also work with colors@migo I think, if the colorizing
script were to be called in the modules@cde files. Maybe this could
also be used to optionally adapt the colors of button-pixmaps to 
the current color scheme. 

Making it transparent isn't good enough (well..), because using 
dark stripes would then look bad on a dark background, and using 
light stripes would look bad on a light background. 

> > Also, I think I have to change some of the text-colors in
> > the schemes, as cde uses different colors sometimes. For
> > instance, in the default scheme, cde uses a white foreground
> > color, not a black one.
> You know, text colors were generated automatically by fvwm-themes-images
> (see "COLORS SCHEMES" in the man page). --text-colors could be tweaked.

Oh, probably there is a different algorithm then, to choose 
between black and white...

Best regards,

jos

Re: CVS domivogt: * Memory leak fixes. Dan, please run purify again. I think I fixed all leaks

[Dan E. <da...@mk...>]

Mikhael Goikhman <mi...@co...> writes:
> On 09 Oct 2000 15:05:25 -0400, Dan Espen wrote:
> > 
> > Mikhael Goikhman <mi...@co...> writes:
> > > On 06 Oct 2000 17:57:54 -0400, Dan Espen wrote:
> > > > 
> > > >   The beta version of the themes package seems to
> > > > have stopped changing the appearance of my windows.  I made quite
> > > > a few tries.
> > > 
> > > Any chance you supply us more info, like `fvwm-themes-config --version`,
> > > better problem description and error messages? Thank you.
> > 
> > The version is 0.3.19.
> 
> The latest is 0.3.20, but 0.3.19 should work with the current fvwm too.
> 
> > Trying to get together a decent problem report led me to the problem.
> > I don't have the fvwm bin directory in my path.
> > I'll have to figure out a better way to do this.
> 
> I guess you started fvwm as fvwm2 -f themes-rc, otherwise I don't see
> how it is possible to use fvwm-themes, but not be able to change themes.
> 
> If you use /full/path/to/fvwm-themes-start to start your window manager,
> it should add fvwm bin directory if needed to $PATH before starting fvwm2.

Not really.  Your script does:

# check that /opt/public/src/fvwm/2.3.22 is in $PATH
if ! which fvwm2 >/dev/null; then
	PATH="/opt/public/src/fvwm/2.3.22:$PATH"
fi

I have fvwm2 in my path, but its not really fvwm2, its a wrapper.
The wrapper lets me do all kinds of things before starting fvwm2
(like fix up users config files, and run different versions).

The average user is none the wiser.

Still my fault.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: da...@mk...
Piscataway, NJ 08854                     Phone: (732) 699-5570

Re: CVS domivogt: * Memory leak fixes. Dan, please run purify again. I think I fixed all leaks

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

On 09 Oct 2000 15:05:25 -0400, Dan Espen wrote:
> 
> Mikhael Goikhman <mi...@co...> writes:
> > On 06 Oct 2000 17:57:54 -0400, Dan Espen wrote:
> > > 
> > >   The beta version of the themes package seems to
> > > have stopped changing the appearance of my windows.  I made quite
> > > a few tries.
> > 
> > Any chance you supply us more info, like `fvwm-themes-config --version`,
> > better problem description and error messages? Thank you.
> 
> The version is 0.3.19.

The latest is 0.3.20, but 0.3.19 should work with the current fvwm too.

> Trying to get together a decent problem report led me to the problem.
> I don't have the fvwm bin directory in my path.
> I'll have to figure out a better way to do this.

I guess you started fvwm as fvwm2 -f themes-rc, otherwise I don't see
how it is possible to use fvwm-themes, but not be able to change themes.

If you use /full/path/to/fvwm-themes-start to start your window manager,
it should add fvwm bin directory if needed to $PATH before starting fvwm2.

Regards,
Mikhael.

Re: CVS domivogt: * Memory leak fixes. Dan, please run purify again. I think I fixed all leaks

[Dan E. <da...@mk...>]

Mikhael Goikhman <mi...@co...> writes:
> On 06 Oct 2000 17:57:54 -0400, Dan Espen wrote:
> > 
> >   The beta version of the themes package seems to
> > have stopped changing the appearance of my windows.  I made quite
> > a few tries.
> 
> Any chance you supply us more info, like `fvwm-themes-config --version`,
> better problem description and error messages? Thank you.

The version is 0.3.19.

Trying to get together a decent problem report led me to the problem.
I don't have the fvwm bin directory in my path.
I'll have to figure out a better way to do this.

My fault.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: da...@mk...
Piscataway, NJ 08854                     Phone: (732) 699-5570

Re: CVS domivogt: * Memory leak fixes. Dan, please run purify again. I think I fixed all leaks

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

On 06 Oct 2000 17:57:54 -0400, Dan Espen wrote:
> 
>   The beta version of the themes package seems to
> have stopped changing the appearance of my windows.  I made quite
> a few tries.

Any chance you supply us more info, like `fvwm-themes-config --version`,
better problem description and error messages? Thank you.

Regards,
Mikhael.

Re: desktop

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

On 09 Oct 2000 11:52:38 +0200, Olivier Chapuis wrote:
> 
> Here my opinion on desktop.
> First of all I think that the contenants of this file is
> ok, but XORValue which should be moved into background
> (with XorPixmap).

Usually 50% or more of my screen is applications, so these commands are
as well can be included in colors@. Or maybe just leave it as is?

> Also, some additional things may be put in this file (as
> some BugOpts, some BusyCursor options, ColorLimit, 
> ModuleTimeout and BackingStore and SaveUnder styles, 
> may be I forget styles which can be reasonably applied 
> to all windows).

Ok, we can update this list later.

> Secondly, the name of this file is surely not good. It
> contains the "Major Operating Modes" configuration, so 
> I suggest to rename it major-modes but there are surely
> a better name. Any ideas?

I don't think that major-modes name is better than desktop.
Maybe "globals"? Or "globalstyles"? Hmm, how about "feel"? :)
I think we need some time to finalize its name... "commonfeel"?

> Finally, I think this config file look likes more than
> bindings or function-appbind(user), i.e., it is not
> really a themable component. So, I suggest that there
> are only one "desktop" file in default together with
> a FvwmScript that can edit this file (such a change
> must be done together).

Any theme can have bindings@, menus@ or any other we-suggest-not-to-have
component if it really wants. Say AnotherLevel[Up] simulations.

I think that having several different desktop@ components is good as to
show different possible "feel"s, which are actually used by some peoples.

Regards,
Mikhael.

desktop

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

Hello,
Here my opinion on desktop.
First of all I think that the contenants of this file is
ok, but XORValue which should be moved into background
(with XorPixmap).
Also, some additional things may be put in this file (as
some BugOpts, some BusyCursor options, ColorLimit, 
ModuleTimeout and BackingStore and SaveUnder styles, 
may be I forget styles which can be reasonably applied 
to all windows).
Secondly, the name of this file is surely not good. It
contains the "Major Operating Modes" configuration, so 
I suggest to rename it major-modes but there are surely
a better name. Any ideas?
Finally, I think this config file look likes more than
bindings or function-appbind(user), i.e., it is not
really a themable component. So, I suggest that there
are only one "desktop" file in default together with
a FvwmScript that can edit this file (such a change
must be done together).
Olivier

DestroyStyle

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

Hello,
I have made some modifications in modules@{aftersetp,awol,
blackbox,olicha} which may cause new core dumps:
all modules styles are moved in a file main:styles and
these styles are destroyed in FuncFvwmStopThemeModules.
Moving the theme modules styles in a separated file is
a good idea IMHO: change and optimizations for such styles
will be more easy. I think that destroying the styles
may save some memories. The reason that I doing this now
is that I think that DestroyStyle can cause core dump
(no core dump with my machine) and that this may help
with debugging FVWM. I will do all the others modules
themes if this does not cause problems and remove this
change if not fixable core dump arise ...
Olivier

Ô¤²â

[liu <li...@ne...>]

Ò»¸öÈËÒ»ÉúµÄÃüÔ˵½µ×ÊÇÓÉʲôÀ´¾ö¶¨µÄ£¿´ð°¸²»ÊÇΨһµÄ£¬Ò»¸öÈ˵ÄÃû×Ö¡¢Éú»î¡¢¹¤×÷»·¾³µÈ¶ÔÒ»¸öÈ˵ÄÃüÔ˶¼ÓÐÖ±½ÓµÄÓ°Ï죬ͬÑù·¿×Ó£¬²»Í¬µÄÖ÷È˾Óס£¬·¿×Ó¶ÔÖ÷È˵ÄÓ°ÏìÊDz»Í¬µÄ£¬ÕâÒª¿´Õâ¸öÈ˵ij¡ÊÇÔõÑùµÄ£¿Ò»¸ö»·¾³ÓÐËû×Ô¼ºµÄ³¡£¬ÄÇôÁ½¸ö³¡ÈçºÎ²ÅÄÜÏàÅäÄØ£¿Õâ²»ÊÇÆÕͨµÄÈË¿ÉÒÔÖªµÀµÄ£¬ÖÜÒ×µÈһЩԤ²âѧ½²¾¿µÄÊǼÆË㣬¶øÓÐһЩÈË£¬ËûÃÇÓÐÌìÉúµÄÌØÒ칦ÄÜ£¬ÄÜ¿´µ½³£ÈË¿´²»µ½ 
µÄ¶«Î÷£¬ËûÃǶԳ£È˵ÄÖ¸µã£¬ÍùÍù·Ç³£ÓÐÓã¬ÔںܶàÄêÒÔÇ°£¬ÔÚÎÒ¹úµÄºÓ±±Ê¡£¬ÓиöСÄк¢£¬Í»È»ÓÐÒ»ÌìµÃÁËÒ»³¡Öز¡£¬²¡ºÃÖ®ºó£¬ÈËÃǾ­³£»áÌýµ½Ð¡Äк¢µÄ¶Ç×ÓÀïÓÐÈËÔÚ˵»°£¬´Ó´Ë£¬ÈËÃÇÖªµÀÕâ¸öСÄк¢µÄ¶Ç×Ó»á˵»°£¬µ«ÊǺóÀ´£¬ÈËÃÇÓÖ·¢ÏÖ£¬Õâ¸öСÄк¢¾ßÓÐÄÜ¿´µ½±ðÈË¿´²»µ½µÄ¶«Î÷µÄÌØÒ칦ÄÜ£¬»¹ÄÜ°ïÈËÖβ¡£¬½ñÌ죬Õâ¸öСÄк¢ÒѾ­³¤´óÁË£¬ÏÖÔÚÔڹ㶫£¬ËûÏÖÔÚΪÈËÃÇÌṩ¹«Ë¾»ò¸öÈËÆðÃû×Ö¡¢·çË®¡¢¹ÉƱ¡¢É̱ꡢ¼²²¡µÈµÄÔ¤²â¡£Õ⼸Ä꣬ËûΪºÜ¶àÈË×ö¹ýÔ¤²â£¬×¼È·Âʷdz£µÄ¸ß£¬ËûûÓÐÄÄÃÅÄÄÅÉ£¬ÍêÈ«¿¿×Ô¼ºµÄÌØÒ칦ÄÜ¡£Èç¹ûÄúÏë׼ȷͶ×Ê¡¢¸ÄÉƲ»ÀûÐÎÊƵȣ¬ÇëÓëÎÒÃÇÁªÏµ£¬ÎÒÃǽ«ÎªÄúÌṩ×î׼ȷµÄÒâ¼û¡£

ÁªÏµµç»°£º0757-2252618   

ÁªÏµÈË£ºÁõС½ã »ò Áé¸ë
ÁªÏµÇëÓõ绰£¬²»ÒªÊ¹Óõç×ÓÓʼþ

Re: Name for modules config file

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

On 04 Oct 2000 18:29:27 +0200, Olivier Chapuis wrote:
> 
> I like a lot the new theme luthien.
> However there is a problem with the name
> of the modules config file:
> The Button is configured in a file named
> FvwmButtons. Some editors give as icon name the
> name of the file that it edit (xemacs default).
> This cause bad interaction with some fvwm
> configuration command. So, it seems that we
> have to use an other convention for naming
> modules config files. I've no better suggestion 
> that main:Name ... 

It is easier to rename to main:Fvwm* (although it is less readable).
But I think the problem is in xemacs (and gless), they should add a
"program - " prefix to title name (icon name is unimportant) and in fvwm.
After 2.4 there should be for sure a way to specify Name, Resource, Class
in: Style (Resource FvwmButtons). It is bad we don't have this now.

Feel free to rename this if this fixes your problem.

Regards,
Mikhael.

Name for modules config file

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

Hello,
I like a lot the new theme luthien.
However there is a problem with the name
of the modules config file:
The Button is configured in a file named
FvwmButtons. Some editors give as icon name the
name of the file that it edit (xemacs default).
This cause bad interaction with some fvwm
configuration command. So, it seems that we
have to use an other convention for naming
modules config files. I've no better suggestion 
that main:Name ... 
Olivier

fvwm-themes 0.3.20

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

Hi, all. A new version is out.
Available in 3 formats from http://fvwm-themes.sourceforge.net/

New things:

  * Much improved Themes Center GUI; it now can automatically switch to
    french or russian. Dominik, if you feel like about adding "de",
    you can go to scripts/FvwmScript-ThemesCenter, line 256, and add it.

  * A new modules@luthien component together with improved colors@luthien.
    The colors look nice with other themes too, but probably some more
    transparency can be added to other theme modules too. Not urgent.
    I know, the button bar is a little different from the original, but I
    tried to do it as general as possible. Dominik, any critique welcome.

  * Like already was said, fixed a freeze in XFree-4.0.1 with FvwmScript.
    It is now possible to use Restart when switching themes, this may
    solve (and indeed solves on one system) most of potential core dumps,
    but with Restart it looks much less nicer.

  * Default background color changed. I hope it is ok, maybe a bit gray.

We are close to 0.4.0, but at least one or two more releases are needed.
Olivier, you may release a next version if you wish.

Regards,
Mikhael.

Re: TODO 0.4

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

> The second box is of my wife, RH 6.2, glibc-2.1.3. There are always core
> dumps in malloc.c when switching themes. No core dumps otherwise. This is
> very hard to spot, since the stack does not help (it is different for
> every core). Something wrong with a memory, bug in fvwm or in glibc.
> She will install RH 7.0 in a day or two, so I will probably not be able
> to work on this problem if the newer glibc it better.

Can you try to remove "+ I FuncFvwmRemoveBindings" from
FuncFvwmThemesConfigAndUpdate and see if you have 
still some core dumps? In fact, with my patch
(that you apply) on AddBindings, this function is no
more needed (but if we want to completely unload 
the bindings). It seems that the AddBindings code is bugy ...
Olivier

Re: TODO 0.4

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

Mikhael Goikhman wrote:
> 
> On 30 Sep 2000 23:55:18 +0200, Olivier Chapuis wrote:
> >
> > What about a support for extra-stroke? or may be if one cp
> > settings/stroke/* in its $userDir/themes/default/ dir then
> > this one is read in the place of the site files but the others
> > settings (and default component) are read from the site dir?
> > Maybe this logic can be applied to all files.
> 
> Dividing a theme may become a bit complicated and confusing. I always
> prefered copying a whole theme to a user space to avoid problems.

In theory I am agree, but in pratice I am not. I think it will
be a courant thing that a user just want to modify one file
in a theme (e.g., applets in a modules theme). Moreover, this
technic can save disk space and will be easy to implement:
just Read with a relative path.

Olivier

Re: TODO 0.4

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

On 30 Sep 2000 23:55:18 +0200, Olivier Chapuis wrote:
> 
> What about a support for extra-stroke? or may be if one cp 
> settings/stroke/* in its $userDir/themes/default/ dir then 
> this one is read in the place of the site files but the others 
> settings (and default component) are read from the site dir? 
> Maybe this logic can be applied to all files.

Dividing a theme may become a bit complicated and confusing. I always
prefered copying a whole theme to a user space to avoid problems.
Probably stroke-extra is a good solution, but not before 0.4 anyway.

> Do you sent a bug report to XFree?

Not this one, I can't tell them, just get the latest fvwm, use this
config and see a freeze. I should narrow it and I have no time for this.
I sent however a font size bug seen in xmessage. I didn't get an answer.

Ok, anyway, seems like a lucky day today. :-)

> I've modified FvwmApplet-Mixer so that now there are no widgets 
> out of the window. So now I think that there are no scripts with 
> widgets out of the window (DigitalClock has its widget of the same
> size of the window).

Very good. I can now finally load modules@{afterstep,awol,olicha}.
I think FvwmApplet-Mixer now looks even better (except for colorset 13).

I will test all other FvwmScript samples (including ones in fvwm, which we
should BTW rename to our new scheme) when I will be ready to be frozen. :)

> A point is that ItemDraw does not support "clic", if it was so I
> think that we will be able to do very good applets. I think this
> will be very easy to implement, but fvwm is feature locked.
> Maybe you can send a bug report on this (ItemDraw does not support
> "clic") and I will do the implementation  :o)

If you implement this, we will include it. New small features in fvwm
modules is not the same as in the fvwm core.

> > The second box is of my wife, RH 6.2, glibc-2.1.3. There are always core
> > dumps in malloc.c when switching themes. No core dumps otherwise. This is
> > very hard to spot, since the stack does not help (it is different for
> > every core). Something wrong with a memory, bug in fvwm or in glibc.
> > She will install RH 7.0 in a day or two, so I will probably not be able
> > to work on this problem if the newer glibc it better.

Although the better fixes are in fvwm (and I hope we will have them soon),
I have fixed this problem by a workaround. Now, if one defines
$FT_USE_RESTART environment var, Restart will be used on theme switching.
I think it is ok to use variable in this case and not an option.

So there are no core dumps and freezes for both my boxes. A good progress.

Regards,
Mikhael.

Re: *.cfg files question

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

On 30 Sep 2000 13:39:29 +0200, Jos van Riswick wrote:
> 
> Im currently working on the cde theme, but I have some trouble
> understanding what to do with the .cfg files. I don't really understand
> the contents of the cfg files. And which of the files does the 
> theme-designer have to provide? In the man page for fvwm-theme-config
> it says, that fvwm-themes-config --fresh generates 'theme.cfg', but
> if I run that one, no file is produced. What files should I provide, 
> and what should be their contents?

--fresh only generates theme.cfg in the user's current theme, it does not
write any .cfg files in @cde or other themes, which are always read-only.
Only 'current' theme is writable, it is auto-generated with help of
theme.cfg files of all currently used themes (those components are used).
~/.fvwm/themes/current/theme.cfg should not be very interesting to you,
this is a composition of all used theme.cfg's. The more interesting files
for you are ~/.fvwm/themes-rc (and ~/.fvwm/themes-rc-2), this is .fvwm2rc.

Sorry, but you should try to understand the format of .cfg files yourself
until I write some readable doc (I may partially use this message). It is
not hard if you undersand what are options & choices of a given component.
Technically, component options are rc files, which are Read'd before or
after the component's rc, the details are configurable in <component>.cfg.

Every theme has its theme.cfg (if no, the default/theme.cfg is used).
You should not really deal with theme.cfg, the one that is already in
cde theme is good, just leave it as is.

theme.cfg usually includes other .cfg files like colors.cfg, modules.cfg,
you should only suply these files if you want to define properties of your
component, like options, choices, their names, commands etc. You don't
need colors.cfg if your colors@ component is simple and has no options.

I suggest you to get some modules@ component in any theme as an example.
See modules.cfg and modules/* rc files. Also after choosing this modules@
component, go to menu "Theme Management"/current/modules. You will see
options. These options are defined in an appropriate modules.cfg.

Again, if you don't need options in modules@cde, remove cde/modules.cfg
and supply only modules/main, which can "Read" other files in cde/modules/.


If you prefer an online talk (like irc), write to me about a day and hour.
But without some homework, it will not be fully clear anyway.

Regards,
Mikhael.

Re: TODO 0.4

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

Mikhael Goikhman wrote:
> 
> On 29 Sep 2000 23:05:14 +0200, Olivier Chapuis wrote:
> >
> > TODO worte:
> 
> > > * settings@default: think which subcomponents to remove/move.
> > >  Move settings/stroke@ to bindings@ option.
> >
> > Maybe, but why do you want to move stroke. Now I see stroke
> > as a general config option since it an half external to FVWM.
> 
> One of the reasons is that currently it is impossible to add stroke
> bindings and redefining of existing ones is half-fixed.
>

What about a support for extra-stroke? or may be if one cp 
settings/stroke/* in its $userDir/themes/default/ dir then 
this one is read in the place of the site files but the others 
settings (and default component) are read from the site dir? 
Maybe this logic can be applied to all files.

> With an option this would be possible. But then probably we first need to
> rethink the option/choice/subcomponent concepts to make it possible for
> components to reuse existing properties of other components.
> 
> BTW, I want to rename 'choice' to 'variant' as less confusing, and use
> choice as a general name for options and variants. Better naming?
>

for me it is ok.

> > > * Fix all crashes.
> >
> > This is the most important point. I will try to work on this.
> > In fact it will be great if Dominik works on this ...
> 
> This is the main reason there is no 0.4.0 yet.
> There are two serious problems on my computers.
> 
> The first box is a mixed system with glibc-2.1.91 & XFree-4.0.1. There are
> no core dumps on this computer except for known ones, like core of IconMan
> in blackbox theme). But there is total X freeze when using some FvwmScript
> modules with widgets outside of the window. Maybe we can fix the scripts
> of these modules? This is a bug in XFree, but for us it is a feature.
>

Do you sent a bug report to XFree?
I've modified FvwmApplet-Mixer so that now there are no widgets 
out of the window. So now I think that there are no scripts with 
widgets out of the window (DigitalClock has its widget of the same
size of the window).
A point is that ItemDraw does not support "clic", if it was so I
think that we will be able to do very good applets. I think this
will be very easy to implement, but fvwm is feature locked.
Maybe you can send a bug report on this (ItemDraw does not support
"clic") and I will do the implementation  :o)

> The second box is of my wife, RH 6.2, glibc-2.1.3. There are always core
> dumps in malloc.c when switching themes. No core dumps otherwise. This is
> very hard to spot, since the stack does not help (it is different for
> every core). Something wrong with a memory, bug in fvwm or in glibc.
> She will install RH 7.0 in a day or two, so I will probably not be able
> to work on this problem if the newer glibc it better.
>
> Any other problems? Do you have core dumps?

I have recently upgrade from a custom RH 5.1 to a Mandrake 7.1.
The glibc is glibc-2.1.3-5mdk and I use gcc version 2.95.3 19991030
... and I cannot succeed to get a core dump! And I try and try again :o)
Before, with the RH, I used the glibc 2.0.7 and gcc 2.7.2.3 and I had
a few core dumps with inconsistent core file as on your wife box
(migo -> any).
All these are very strange ....

Olivier