fvwm-themes-devel — Developing FVWM Themes

*.cfg files question

[Riswick, J.G.A.v. <J.G...@tu...>]

Hi!

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?


best regards,

jos

Re: TODO 0.4

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

On 29 Sep 2000 23:05:14 +0200, Olivier Chapuis wrote:
> 
> TODO worte:
> > * colors@ components. Check if every things is ok with the new colors
> > files. migo: Maybe one colorset for swallowing is not enough?
> > I don't think xload's check-like can somehow be related to xclock
> > darts colors, probably a separate color would be ok, also hi, sh used
> > out of purpose. It is not very critical. Just a note.
> 
> I am agree, but this can be done after 0.4

Ok.

> > * 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.

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?

> Any way can be done after 0.4?

Ok, let leave settings@default as is for now.

> > * Think where belong all functions sitting in different components.
> >  Probably rename functions-appbind to functions-user. [migo]
> 
> > * Write some documentation about CCDS. [migo]
> 
> Yes, this will be great. We also need to update the README and the FAQ
> (check that it is up to date).

I think that README and FAQ are more or less up to date.

I started to write doc/creating-themes, which should explain all steps
from zero. I am not sure yet whether we need one big file for all users
or several ones with different levels of details. I need help to write it.

> > * Fix FvwmForm-ThemeSettings (session is obsolete).
> 
> Alex? Since now ThemesCenter can do that and since this form is
> not generic I am not really motivated.

Yes, the problem with non generic stuff is that it should be redone every
time the scheme is changed. :) But if Alex wants to maintain it - fine.

> > * Add luthien theme [migo; started]

I hope to finish initial modules@luthien soon.
Jos, are you working on modules@cde?

> > * 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.

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?

Regards,
Mikhael.

TODO 0.4

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

TODO worte:
> * colors@ components. Check if every things is ok with the new colors
> files. migo: Maybe one colorset for swallowing is not enough?
> I don't think xload's check-like can somehow be related to xclock
> darts colors, probably a separate color would be ok, also hi, sh used
> out of purpose. It is not very critical. Just a note.

I am agree, but this can be done after 0.4

> * 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.
Any way can be done after 0.4?

> * Think where belong all functions sitting in different components.
>  Probably rename functions-appbind to functions-user. [migo]

> * Write some documentation about CCDS. [migo]

Yes, this will be great. We also need to update the README and the FAQ
(check that it is up to date).


> * Fix FvwmForm-ThemeSettings (session is obsolete).

Alex? Since now ThemesCenter can do that and since this form is
not generic I am not really motivated.

> * Add luthien theme [migo; started]
>
> * 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 ...

Olivier

testing rpm's for fvwm and fvwm-themes

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

I have created initial rpm's for fvwm & fvwm-themes for your testing.

  ftp://fvwm-themes.sourceforge.net/pub/fvwm-themes/rpm/

Please read README, it probably answers many questions.

Both fvwm & fvwm-themes were build some hours ago from their current CVS,
this is reflected by 2.3.22-0.2000MMDD version-release numbers, the final
version rpm will have an integer release number, like 2.3.22-1.

fvwm was compilled without -g flag, so no debug info, this saves about 7M.
Both rpm's were created on RedHat Linux 6.2 by 'make rpm-dist' (I will
commit some changes soon). The prefix is /usr/local.

Please everyone who tried to install these rpm's write to me to say
whether it was a success/failure, specify your distribution and problems
if any. The more input I will get the more I can do to fix problems.

Regards,
Mikhael.

Re: cde-like themes and rpm's

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

Mikhael Goikhman wrote:
> 
> There are some open issues.
> 
> -- [ 1 ] --
> 
> I think we should finish our cde theme, at least modules.
> We probably can reuse module configs from this, there are screenshots:
>   ftp://projects.sourceforge.net/pub/fvwm-themes/samples/dragos/
> 
> Another theme to be finished is luthien: revising colors@ (add gradients)
> and adding modules@. Colors in this theme are similar to CDE ones,
> I didn't have time to check whether they are complitely different or
> not, but I know they are at least renamed now from ones shown at:
>   http://www.fvwm.org/screenshots/Dominik-desk2-1152x864.gif
> 

Yes it seems that the luthien colors are similar to cde colors.
However, it does not seem to me that this is a critical problems.
I've no time to look at this now, but maybe in the future ...

> Olivier, we should divide the work. Do you want to implement some of the
> components above? If you have no time, I will do this, but not now.
>

Ok, so Jos can do the cde modules? On the other hands my current
project is to finish the "themes center GUI", but this can take
some time because I am really busy with my work.

> -- [ 2 ] --
> 
> Another issue, rpm's. My machine is somewhat unstandard, so if I will
> create rpm's there are no much peoples to be able to use them. :)
> I have another machine, almost stock RedHat 6.2, but it should yet to be
> converted to a developement machine before creating rpm's on it.
> 
> Creating rpm's which work for many peoples is not easy. Say, if the rpm
> has all features compiled-in, you should have stroke, GTK, GNOME libs etc.
> So, probably, I should compile without GTK/Imlib/GNOME, they are only
> used in FvwmGtk, and without rplay. Maybe also without stroke?
>

My machine is not standard too (RH 5.1 and a lot of hands modification).
I will upgrade to a RH 6.2, a Mandrake 7.x or to a debian 2.2 soon (If
I am able to choose one :). However, there are surley problems with
building a rpm package for fvwm, but I do not see big problems with
fvwm-themes (but the --enable-gnome-icons and the packages to be required).
Since, I know nothing on building rpm I cannot say more here, but I am
ready for making test!

Olivier

Re: cde-like themes and rpm's

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

On 17 Sep 2000 08:41:39 +0200, Jos van Riswick wrote:
> 
> I just returned from a long holiday, and started working on 
> the theme yesterday. As, in the meantime, the fvwm-themes 
> developers did a lot of work, and a lot changed, so I decided
> to completele start from scratch on the modules. So I copied
> the 'modules' directory from the default theme to the 'cde'
> directory. On running fvwm-themes-config --fresh however, the
> modules then do not start automatically, I have to start them 
> by hand from the root menu. Where in the theme are the modules
> initialized?

Copying modules directory is not enough, you should also copy modules.cfg.
Tell me if this solves your --fresh problem.

Jos, it would be nice if you understand this in depth, so not only me and
Olivier will be able to create and explain to other how to create modules.
Please use the 0.3.19 version, it is a bit cleaner regarding modules.

In modules/main you can see all Read's. Modules are started (when entering
this component) in FuncFvwmStartThemeModules and stopped (when leaving
this component) in FuncFvwmStopThemeModules. You can simply start
FvwmIconMan or similar modules in these functions or use options.

All current modules use options, they are defined in modules.cfg file.
You probably can procede without options at all. But to understand how
modules@ work you should take a look at all module options.
There are currently 2 or 3 solutions. In modules@default the options are
Read'd after the main and they have AddToFunc FuncFvwmStartThemeModules.
In other themes (migo, awol, blackbox, afterstep) the option files
are Read'd before the main and they AddToFunc FuncFvwmStartChosenOption.
As I said everything about options (names, order) defined in .cfg files.

Run the following command to see what configuration files are Read'd:
  fvwm-themes-config -e | grep /modules/ | grep Read

I hope this helps, or ask any futher questions.

Regards,
Mikhael.

fvwm-themes 0.3.19

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

A new release is out. It requires one of the latest fvwm snapshots or CVS.

Major changes include a new luthien theme (its colors@ and modules@ will
be finished in the next version) and an ability to lock a given component.

So if you like desktop@migo and colors@cde, you can lock these components,
and the next time you choose 'load all' from some theme, these components
will not be replaced until they are unlocked. A locked component, hoverer,
will be replaced if you explicitly choose *one* component, not all, say
colors@olicha.

Regards,
Mikhael.

RE: cde-like themes and rpm's

[Riswick, J.G.A.v. <J.G...@tu...>]

 

>I think we should finish our cde theme, at least modules.
>We probably can reuse module configs from this, there are screenshots:
>  ftp://projects.sourceforge.net/pub/fvwm-themes/samples/dragos/


HI!

I just returned from a long holiday, and started working on 
the theme yesterday. As, in the meantime, the fvwm-themes 
developers did a lot of work, and a lot changed, so I decided
to completele start from scratch on the modules. So I copied
the 'modules' directory from the default theme to the 'cde'
directory. On running fvwm-themes-config --fresh however, the
modules then do not start automatically, I have to start them 
by hand from the root menu. Where in the theme are the modules
initialized?

best regards,

Jos van Riswick

cde-like themes and rpm's

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

There are some open issues.

-- [ 1 ] --

I think we should finish our cde theme, at least modules.
We probably can reuse module configs from this, there are screenshots:
  ftp://projects.sourceforge.net/pub/fvwm-themes/samples/dragos/

Another theme to be finished is luthien: revising colors@ (add gradients)
and adding modules@. Colors in this theme are similar to CDE ones,
I didn't have time to check whether they are complitely different or
not, but I know they are at least renamed now from ones shown at:
  http://www.fvwm.org/screenshots/Dominik-desk2-1152x864.gif

Olivier, we should divide the work. Do you want to implement some of the
components above? If you have no time, I will do this, but not now.

-- [ 2 ] --

Another issue, rpm's. My machine is somewhat unstandard, so if I will
create rpm's there are no much peoples to be able to use them. :)
I have another machine, almost stock RedHat 6.2, but it should yet to be
converted to a developement machine before creating rpm's on it.

Creating rpm's which work for many peoples is not easy. Say, if the rpm
has all features compiled-in, you should have stroke, GTK, GNOME libs etc.
So, probably, I should compile without GTK/Imlib/GNOME, they are only
used in FvwmGtk, and without rplay. Maybe also without stroke?

How many of you will be ready to test fvwm & fvwm-themes rpm's on RedHat
and non RedHat systems? So I would know whether to start it or not.

Regards,
Mikhael.

Re: palettes and themes

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

[This message is long]

On 08 Sep 2000 01:28:14 +0200, Dominik Vogt wrote:
> 
> I am very impressed!  You are really doing a very good job in themes

Thank you. Olivier did about a half of the work.

Here is a brief introduction to the fvwm-themes terminology (more in FAQ),
so it would be easier to communicate.

There are themes. Themes are just a set of their components. Component is
not something fixed, it can be just any meaningful part of the
configuration. There are standard components; it is easier if you stick to
the standard components, in this case you should not define component
dependancies, they are pre-defined, but it is possible to create new
components, for example, 'joystick', 'wheel-mouse', 'menus-auto' and so
on, but then there should be defined their dependances, for example,
'wheel-mouse' requires 'bindings', 'menus-auto' follows 'menus' etc.

Notation colors@cde means colors@ component in @cde theme.

For a user convention, there are user-definable versions of all standard
component, where he can extend this component. For example, a user can add
more bindings in bindings-extra@personal (he should create a bindings file
in ~/.fvwm/personal directory and it will be automatically reflected in
the menu); he can add more menus in menus-extra@personal and so on.

A component can come in several choices (reflected in menu) and can have
any number of options (also automatically reflected). Also a component can
be a complex one, i.e. include other components, like settings@default.

> development.  I have some enhancement requests:
> 
> a) Colour palette management independently of the theme.

Just choose only a colors@ component from your beloved theme.
Every component defines its own options/choices, so, for example
colors@afterstep comes without any, but colors@cde comes with 41 options.
Or you mean something different?

> b) Choosing backgrounds independently.

The same thing. You can even disable theme background completely (if you
use gnome background or define your own background in startup-extra@).

> c) If would be nice if fvwm did not restart after *each* configuration change.

But you, fvwm expert, should notice, fvwm is *not* restarted, you never
see windows without decorations, right? There are just many fvwm commands
which are executed. Probably a real restart would take a longer time.

> d) You don't have to restart fvwm because of background changes.  I think the
> only changes that cannot be applied at run time are changes of the module
> configurations.

There are no even one change, which can't be applied at run time!
You see, we never use Restart. :)

The problem of finding a minimal config, needed to be reloaded (and not
all config, like it is done now) is as old as fvwm-themes. We postpone the
solution to 0.4.0+ versions. We can't just hardcode that background are
somewhat special (how about cursors, which also are not requested by any
other component?). This should be done by defining exact dependances.

At least for now we only should worry about the right component order (a
very hard task by itself, since it is automatically determined using
dependancies) and should not worry about things like whether reload
modules@ on changes in menus@ or not.

> And some bugs/quirks I noticed:
> 
> 1) If I "make install" fvwm, fvwm-config is not installed executable and thus
> the ./configure of fvwm-theme throws an error.

I don't think so. On "make install" fvwm, the executable fvwm-config is
installed in $bindir, i.e. usually in $prefix/bin, say, /usr/local/bin.

By default, fvwm-themes installs itself to the same place as fvwm itself,
so it should find fvwm-config to query it.

One should always use "make install" when installing fvwm. And then put
the bin directory with fvwm2 in $PATH, so all fvwm-* scripts are found.
I will add this info to fvwm's README or ANNOUNCE later.

> 2) When I start FvwmButtons in the default theme, there is a beep, but the
> module still starts up (no error message on the console).

I don't know the answer. Maybe xbiff indicates you there is a new mail. :)

> 3) I get these error messages on startup in the console (default theme):
> 
> head: /home/luthien/.fvwm/themes-rc: No such file or directory
> head: /home/luthien/.fvwm/themes-rc: No such file or directory

Ah, ok, you should have this warning only the first time you ever run
fvwm-themes. Somehow redirection of head's stderr to /dev/null was lost.

> ...
> Unknown option: icon-item
> Try '/home/luthien/bin/fvwm2/fvwm-menu-xlock --help' for more information.
> (bot messages repeat once)
> ...

I bet you have old fvwm-menu-xlock in ~/bin/fvwm2. It is installed like
all fvwm-* scripts to the same directory as fvwm2 binary on 'make install'.

> [FVWM][scanForPixmap]: <<WARNING>> Couldn't find pixmap
> 
> 4) The 'Personal' submenu of the root menu does not work (default theme).
> When I click on that item, the item is unhilighted after a moment. This
> indicates that the dynamic menu generation did not generate anything.

This submenu is intentionally empty. It should be defined among other user
specific menus in the menus-extra@personal, like explained in FAQ.

> 5) The default theme should have less bright colours :-)

Do you mean yellow or violet? Just suggest better ones.

> 6) What is the "Opt/Cho/Sub" button supposed to do in the THemes Center?

It edits options or choices of the component, or its subcomponents if any.
But you don't use GUI, right? :) The menu inteface is just much better. :)

> 7) If I choose the "afterstep" theme, I get this error message on the console
> every few seconds:
> 
> sh: exec: aumix: not found
> 
> Whatever command is causing this should give up finally (FvwmButtons trying
> to respawn a window?).

No, it is FvwmApplet-Mixer (FvwmApplet is alias for FvwmScript) calls
every 5 seconds aumix to update itself if I understand Olivier's code.
We will fix it.

> 8) CDE theme does not work at all for me.

You didn't see something cool then. Ok, your palettes are very good too.

Is it too much to ask you whether you have the latest FvwmM4 installed?
Any errors?

You can run 'fvwm-themes-config -e | less' to get a full fvwmrc file,
it is huge.

> Well, and since you asked for it, I have attacked my complete
> configuration. Place the .fvwm directory in your home directory,
> edit the first line of .fvwm/.fvwm2rc and start it.

I will play a bit with it and then will put all your configs to

  ftp://ftp://projects.sourceforge.net/pub/fvwm-themes/samples/domivogt/

With a time we with Olivier will create domivogt (luthien?) theme.

Regards,
Mikhael.

fvwm-themes 0.3.18 is out

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

Hello, guys,

A new release is available from:
  https://sourceforge.net/projects/fvwm-themes/

There are many small fixes and no much interesting new features, except
that I have finally understood how pixmap cursors can be defined and have
added some pixmap sets in cursors@multichoice component.

Starting from this release the tarball is available in .tar.gz and
.tar.bz2 (Olivier, use: make dist2). Next time I hope to add rpms. :-)

Regards,
Mikhael.

Re: fvwm-themes 0.3.17 is out

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

On 30 Aug 2000 07:34:44 +0200, Olivier Chapuis wrote:
> 
> Mikhael Goikhman wrote:
> > 
> > On 29 Aug 2000 06:55:20 +0200, Olivier Chapuis wrote:
> > >
> > > Mikhael Goikhman wrote:
> > > >
> > > > I would like if somebody test this release and report results.
> > >
> > > With perl 5.004_05 I've got the following error when I make install:
> > >
> > > /usr/local/bin/fvwm-themes-config --site --reset
> > > /^(.*/|)+([^/]+)\.tar\.(gz|bz2)$/: regexp *+ operand could be empty at /usr/local/bin/fvwm-themes-config line 1508.

[...]

> > > > There is one problem, which I had no time to investigate: NoteMessage (on
> > > > theme switching) is freezed until a mouse is moved or a button is pressed.
> > > > I can't say now whether it is an old or a new problem, but it should be
> > > > fixed (in fvwm I suppose) as soon as possible.
> > >
> > > As you say in the ChangeLog this happen with modules@migo (even with
> > > all the option to None). This freeze is caused by FuncFvwmStopThemeModules
> > > from themes/migo/modules/main (i.e., I've got the freeze when I execute
> > > this function from the Console). I do not think I saw this freeze before
> > > 0.3.17. I've no time to do more investigation now.
> > 
> > I got this freeze with other than modules@migo components too IIRC.
> 
> I try again all the modules and I've got the freeze only when I
> leave modules@migo.

So I did not remember correctly, sorry.

Both these problems are hopefully fixed in CVS.

Regards,
Mikhael.

Re: fvwm-themes 0.3.17 is out

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

Mikhael Goikhman wrote:
> 
> On 29 Aug 2000 06:55:20 +0200, Olivier Chapuis wrote:
> >
> > Mikhael Goikhman wrote:
> > >
> > > I would like if somebody test this release and report results.
> >
> > With perl 5.004_05 I've got the following error when I make install:
> >
> > /usr/local/bin/fvwm-themes-config --site --reset
> > /^(.*/|)+([^/]+)\.tar\.(gz|bz2)$/: regexp *+ operand could be empty at /usr/local/bin/fvwm-themes-config line 1508.
> >
> > This error does not occure with perl 5.6.0 (fortunately I've these
> > two versions of perl on my machine).
> 
> Uff, you should remove the first +, I guess.
> Is this a warning or error? I am not near my computer, I get a fatal error
> (different from what you specified) with perl 5.005.
> 

It is a fatal error.

> > > There is one problem, which I had no time to investigate: NoteMessage (on
> > > theme switching) is freezed until a mouse is moved or a button is pressed.
> > > I can't say now whether it is an old or a new problem, but it should be
> > > fixed (in fvwm I suppose) as soon as possible.
> >
> > As you say in the ChangeLog this happen with modules@migo (even with
> > all the option to None). This freeze is caused by FuncFvwmStopThemeModules
> > from themes/migo/modules/main (i.e., I've got the freeze when I execute
> > this function from the Console). I do not think I saw this freeze before
> > 0.3.17. I've no time to do more investigation now.
> 
> I got this freeze with other than modules@migo components too IIRC.
>

I try again all the modules and I've got the freeze only when I
leave modules@migo.

Olivier

Re: fvwm-themes 0.3.17 is out

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

On 29 Aug 2000 06:55:20 +0200, Olivier Chapuis wrote:
> 
> Mikhael Goikhman wrote:
> > 
> > I would like if somebody test this release and report results.
> 
> With perl 5.004_05 I've got the following error when I make install:
> 
> /usr/local/bin/fvwm-themes-config --site --reset
> /^(.*/|)+([^/]+)\.tar\.(gz|bz2)$/: regexp *+ operand could be empty at /usr/local/bin/fvwm-themes-config line 1508.
> 
> This error does not occure with perl 5.6.0 (fortunately I've these
> two versions of perl on my machine).

Uff, you should remove the first +, I guess.
Is this a warning or error? I am not near my computer, I get a fatal error
(different from what you specified) with perl 5.005.

> > There is one problem, which I had no time to investigate: NoteMessage (on
> > theme switching) is freezed until a mouse is moved or a button is pressed.
> > I can't say now whether it is an old or a new problem, but it should be
> > fixed (in fvwm I suppose) as soon as possible.
> 
> As you say in the ChangeLog this happen with modules@migo (even with
> all the option to None). This freeze is caused by FuncFvwmStopThemeModules
> from themes/migo/modules/main (i.e., I've got the freeze when I execute
> this function from the Console). I do not think I saw this freeze before
> 0.3.17. I've no time to do more investigation now.

I got this freeze with other than modules@migo components too IIRC.

> About swallowing two pagers: we must use different name for *all* the
> pager we use.

Yes, I think you are right. But there will be even more duplication...
Maybe to have one FvwmPager file with all pager configs or several files
are better? I have an idea (not new) how to fix a duplication for a future
fvwm versions. FvwmPager-Desker simply should read FvwmPager config first.

Regards,
Mikhael.

Re: fvwm-themes 0.3.17 is out

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

Mikhael Goikhman wrote:
> 
> I would like if somebody test this release and report results.
> 

With perl 5.004_05 I've got the following error when I make install:

/usr/local/bin/fvwm-themes-config --site --reset
/^(.*/|)+([^/]+)\.tar\.(gz|bz2)$/: regexp *+ operand could be empty at /usr/local/bin/fvwm-themes-config line 1508.

This error does not occure with perl 5.6.0 (fortunately I've these
two versions of perl on my machine).

> There is one problem, which I had no time to investigate: NoteMessage (on
> theme switching) is freezed until a mouse is moved or a button is pressed.
> I can't say now whether it is an old or a new problem, but it should be
> fixed (in fvwm I suppose) as soon as possible.

As you say in the ChangeLog this happen with modules@migo (even with
all the option to None). This freeze is caused by FuncFvwmStopThemeModules
from themes/migo/modules/main (i.e., I've got the freeze when I execute
this function from the Console). I do not think I saw this freeze before
0.3.17. I've no time to do more investigation now.

About swallowing two pagers: we must use different name for *all* the
pager we use.

Olivier

fvwm-themes 0.3.17 is out

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

I will be out of my computer for three days, so I release a new version.
Some of the changes include: a new default background, --install parameter
to fvwm-themes-config for installing new theme tarballs into the user or
the site directory, a check for the correct fvwm version, revised FAQ,
more options for modules@migo, more menu entries for Amusements and Games.

You should already know that actual menus only show the applications you
have installed on your system. Anyone is free to submit own menu entries
for inclusion even for exotic applications.

There is one problem, which I had no time to investigate: NoteMessage (on
theme switching) is freezed until a mouse is moved or a button is pressed.
I can't say now whether it is an old or a new problem, but it should be
fixed (in fvwm I suppose) as soon as possible.

I would like if somebody test this release and report results.

Regards,
Mikhael.

Re: Default Background

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

On 19 Aug 2000 23:25:42 +0200, Olivier Chapuis wrote:
> 
> I do not like very much the default background
> what about a more fun:
> 	xsetroot -solid "#999900"
> Or
> 	xpmroot yellow-stone1.xpm
> yellow-stone1.xpm is attached to this message and
> came from the fvwm-web black-stone1.xpm (via ft-images :).
> I do not think using an XPM as default background is a bad
> idea. Who now days want a config with themes and do not have
> the xpm lib?

If we can support guys without libxpm or without xv, why not?

I see you like yellow, no problem. I think we can have a
background@default with 2 choices, solid and pixmap, see above.

BTW, the question to one of your questions: cvs diff -D now >diff.txt

Regards,
Mikhael.

Default Background

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

Hello,
I do not like very much the default background
what about a more fun:
	xsetroot -solid "#999900"
Or
	xpmroot yellow-stone1.xpm
yellow-stone1.xpm is attached to this message and
came from the fvwm-web black-stone1.xpm (via ft-images :).
I do not think using an XPM as default background is a bad
idea. Who now days want a config with themes and do not have
the xpm lib?
Olivier

Holidays and work

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

Hello,

I will be far from any computers for 7 days and after
I will have a lot of work. So, I will be able to do
only minor work on fvwm-themes for a certain period
(until the middle of September).

About, the 0.4 release, Mikhael, you can release it when
you want. The only "big" problems for me are the core dump and
crash. I think that these must be fixed in fvwm and that
it will be fine if someone can run profile with fvwm-themes.

I will try to release 0.3.16 before leaving (if no release
appear before 16 hours then I did not "succeed").

Good Luck!
Olivier

Re: Session Support

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

On 17 Aug 2000 21:08:05 +0200, Olivier Chapuis wrote:
> 
> Mikhael Goikhman wrote:
> > 
> > We can say that gnome support is special. In this case having a global
> > function like your old NosmOrGnomeOrGeneric should solve all problems, no?
> > For which other situations would you like to define their own defaults?
> 
> But we do not like this solution!

If you speak about a static function a-la MouseXX, it is ok by me.
The session manager support is a such fundamental feature that we can have
a global (not really global, but similar) function for it if needed.

> So now (soon) we have a new component settings/session-manager
> with 3 choices none, gnome, generic. By default, none is loaded.
> Here we have two solution:
>   1. ask the users to load by hands the good component
>   2. fvwm-themes-config can load the good component automatically
>   (and more: for GNOME we can disabled the background for example).

About a background, I would not change a default here. GNOME background
is optional (at least in my version), and IMHO fvwm-themes have better
background components in several (if not all) themes.

> The two solutions are ok for me, but I prefer the second and the
> only reasonable solution I see is to introduce this famous
> defulat-situation cfg command (situations is defined via the current
> destination dir).

As you said yourself situation is not equal to session. Think about it,
should session "xsm-1" imply situation "sm" or nothing; session "gnome-1"
- situation "gnome" or "sm"? Who defines this, user? What other situations
for all defaults do you want to have?

> So let go for the first?

Yes, I would like not to complicate things with multiple defaults
unless we really can't do without them. It seems we can.

Regards,
Mikhael.

Re: Warning and Gnome problems

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

On 17 Aug 2000 20:01:18 +0200, Olivier Chapuis wrote:
> 
> Ok, I've made some test (gnome and xsm; is there another sm??). 

Probably some non-free ones,

> Here a solution:
> Add a -no-start option to fvwm-themes-start (any better idea
> for the name of this option?). This option will just run
> ft-start as usual but will just *not* start fvwm2.
> Then, for starting gnome (or any other session manager?),
> we just have to add at the end of the .xinitrc/.xsession file
> 
> fvwm-themes-start [ --session gnome ] --no-start
> gnome-session
> 
> and then play with the control center and ask for the
> wm command fvwm2 -f themes-rc.
> 
> This work as well with xsm (putting fvwm2 -f themes-rc
> in .xsmstartup).
> 
> In fact putting fvwm-themes-start [ --session gnome/xsm ]
> in the control center or in .xsmstartup change nothing
> because this command is simply ignored but the first time,
> after the sm has "saved its state" only fvwm2 -f themes-rc ...
> is executed.

If so, we probably can tell users to configure fvwm-themes-start as
a window manager (and tell them about a more clear anternative).

> So I am ready to commit this changes :o)

Ok.

Regards,
Mikhael.

Re: Session Support

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

Mikhael Goikhman wrote:
> 
> On 15 Aug 2000 22:01:00 +0200, Olivier Chapuis wrote:
> >
> > Mikhael Goikhman wrote:
> > >
> > > On 14 Aug 2000 08:50:59 +0200, Olivier Chapuis wrote:
> > > >
> > > > Mikhael Goikhman wrote:
> > > > >
> 
> I don't like this solution, because having several defaults does not look
> clean to me (when we use what, what default will show editors, all?). You
> can try to improve the solution or convince me that it is not that bad.
>

Maybe I can try in french? In english I will fail again I think.

> > But now we need to have a special gnome-session support.
> >       1 - special key binding for gnome menu
> >       2 - special Quit fvwm menu
> > (I think that the components under the gnome setting  component
> > are independent with "gnome-session"). So we need at least a component
> >
> > settings/session-manager/
> >
> > with choices: none, gnome, generic and may be other in the future
> 
> Instead of settings/session? Ok.

Will be commited soon.

> 
> > Again I think that the good component have to be load (by default)
> > automatically. I suggest that if a user start fvwm-themes-themes
> > as
> >       fvwm-themes-start --session gnome*
> > then the gnome component is load automatically (by default again!).
> > We do not need to add an option to fvwm-themes-config we
> > just have to look the name of the directory that is symlinked
> > to themes/current .... and have a default-situation ft cfg cmd.
> > Damn!
> 
> We can say that gnome support is special. In this case having a global
> function like your old NosmOrGnomeOrGeneric should solve all problems, no?
> For which other situations would you like to define their own defaults?
>

But we do not like this solution!
So now (soon) we have a new component settings/session-manager
with 3 choices none, gnome, generic. By default, none is loaded.
Here we have two solution:
  1. ask the users to load by hands the good component
  2. fvwm-themes-config can load the good component automatically
  (and more: for GNOME we can disabled the background for example).
The two solutions are ok for me, but I prefer the second and the
only reasonable solution I see is to introduce this famous
defulat-situation cfg command (situations is defined via the current
destination dir).
So let go for the first?

Olivier

Re: Warning and Gnome problems

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

Mikhael Goikhman wrote:
> 
> On 16 Aug 2000 23:15:21 +0200, Olivier Chapuis wrote:
> >
> > Unfortunately, it seems that fvwm-themes-start does not
> > work with gnome-session (at least with my "old" version of
> > GNOME:gnome-core-1.0.4-13rh) because GNOME is intelligent or
> > stupid I do not know but it retains only the windows manager
> > start command ...
> > The only solution I saw is to add an option to ft-start,
> > says --dummy which does not start fvwm2 and ask the user to
> > start fvwm as:
> >
> > fvwm-themes-start -s gnome -d
> > gnome-session
> >
> > and to use fvwm-themes-start -s gnome as wm command in the
> > GNOME control center.
> 
> I don't know whether this will work or not.
> 
> fvwm 2.3 is (hopefully) a XSMP compliant window manager, fvwm-themes-start
> is not of course. fvwm started by fvwm-themes-start being a XSMP compliant
> client will require to restart it as any other client. Now the question is
> whether fvwm-themes-start will be restarted too (probably yes, since it is
> a non XSMP compliant wm), so you may end up with 2 fvwm's started - the
> second one should fail with an error. I can't say without testing.
> 
> I think the wm command should be: 'fvwm2 -f themes-rc' when using a
> session manager. I don't know yet how fvwm-themes-start should be used.
> Note the actual command line will be 'fvwm2 -f themes-rc -clientId id
> -restore .fs-dGaRsg'; fvwm itself defines this command line.
> 
> Regards,
> Mikhael.

Ok, I've made some test (gnome and xsm; is there another sm??). 
Here a solution:
Add a -no-start option to fvwm-themes-start (any better idea
for the name of this option?). This option will just run
ft-start as usual but will just *not* start fvwm2.
Then, for starting gnome (or any other session manager?),
we just have to add at the end of the .xinitrc/.xsession file

fvwm-themes-start [ --session gnome ] --no-start
gnome-session

and then play with the control center and ask for the
wm command fvwm2 -f themes-rc.

This work as well with xsm (putting fvwm2 -f themes-rc
in .xsmstartup).

In fact putting fvwm-themes-start [ --session gnome/xsm ]
in the control center or in .xsmstartup change nothing
because this command is simply ignored but the first time,
after the sm has "saved its state" only fvwm2 -f themes-rc ...
is executed.

So I am ready to commit this changes :o)

Olivier

Re: Warning and Gnome problems

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

On 17 Aug 2000 00:11:59 +0200, Olivier Chapuis wrote:
> 
> Strange, I do cvs diff ChangeLog > diff and do not see your changes
> so I send the above mail and go to commit but then the commit fail.

This command only shows differences done by you, since it compares to the
last revision you updated to, not to the last existing revision.
You could always do 'update' before 'commit' (probably first with -n).

> Because the shell is too difficult for me. What about using perl?

I did it in shell, because ideally perl should not be required to be able
to use fvwm-themes. It is needed for installing and configuring it though.
I.e. once it is installed, even if you remove /usr/bin/perl you should
still be able to start fvwm, since all configs are static files.

Regards,
Mikhael.

Re: Warning and Gnome problems

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

On 16 Aug 2000 23:15:21 +0200, Olivier Chapuis wrote:
> 
> Unfortunately, it seems that fvwm-themes-start does not
> work with gnome-session (at least with my "old" version of
> GNOME:gnome-core-1.0.4-13rh) because GNOME is intelligent or
> stupid I do not know but it retains only the windows manager
> start command ...
> The only solution I saw is to add an option to ft-start,
> says --dummy which does not start fvwm2 and ask the user to
> start fvwm as:
> 
> fvwm-themes-start -s gnome -d
> gnome-session
> 
> and to use fvwm-themes-start -s gnome as wm command in the
> GNOME control center.

I don't know whether this will work or not.

fvwm 2.3 is (hopefully) a XSMP compliant window manager, fvwm-themes-start
is not of course. fvwm started by fvwm-themes-start being a XSMP compliant
client will require to restart it as any other client. Now the question is
whether fvwm-themes-start will be restarted too (probably yes, since it is
a non XSMP compliant wm), so you may end up with 2 fvwm's started - the
second one should fail with an error. I can't say without testing.

I think the wm command should be: 'fvwm2 -f themes-rc' when using a
session manager. I don't know yet how fvwm-themes-start should be used.
Note the actual command line will be 'fvwm2 -f themes-rc -clientId id
-restore .fs-dGaRsg'; fvwm itself defines this command line.

Regards,
Mikhael.