fvwm-themes-devel — Developing FVWM Themes

Re: Error in last commit?

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

Alex Wallis wrote:
> 
> Since Olivier commit this
> 
> 2000-11-27  olicha  <oli...@fr...>
> 
>         * locale/{fr,en,ru}/FvwmScript-ThemeOption.msg:
>         * script/FvwmScript-ThemesOption:
>         Use the new locale methode for ThemesOption
> 
> I now get this compile time error.
> 
> make[2]: Entering directory `/home/awol/cvs/fvwm-themes/locale/en'
> make[2]: *** No rule to make target `FvwmScript-ThemeOption.msg', needed
> by `all-am'.  Stop.
> make[2]: Leaving directory `/home/awol/cvs/fvwm-themes/locale/en'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/awol/cvs/fvwm-themes/locale'
> make: *** [all-recursive] Error 1
> awol@as1-38:~/cvs/fvwm-themes >
> 

Ooops, hope this is fixed now.
Thanks, Olivier

Error in last commit?

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

Since Olivier commit this

2000-11-27  olicha  <oli...@fr...>
 
        * locale/{fr,en,ru}/FvwmScript-ThemeOption.msg:
        * script/FvwmScript-ThemesOption:
        Use the new locale methode for ThemesOption
 
I now get this compile time error.

make[2]: Entering directory `/home/awol/cvs/fvwm-themes/locale/en'
make[2]: *** No rule to make target `FvwmScript-ThemeOption.msg', needed
by `all-am'.  Stop.
make[2]: Leaving directory `/home/awol/cvs/fvwm-themes/locale/en'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/awol/cvs/fvwm-themes/locale'
make: *** [all-recursive] Error 1
awol@as1-38:~/cvs/fvwm-themes >   


Alex

Re: menus & icons styles

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

On 26 Nov 2000 22:34:40 +0100, Olivier Chapuis wrote:
> 
> Our menus and mini icons styles "files" need some work I think.
> 
> Here, a proposition:

[skipped]

> I will try to start this, so I need comments ...

I think this is a complex issue. I should think well before making any
comments. We probably can postpone this issue a bit.

BTW, rc files in wm-icons are generated from devel/conf/style-icons.cfg
(I have a more updated version locally) and using other files in devel/.

Regards,
Mikhael.

menus & icons styles

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

Hello,

Our menus and mini icons styles "files" need some work I
think.

Here, a proposition:

We create a new subdir in the tree called appdb/ (any other name
suggestion is welcome). In this directory we have files with
informations for all applications in the world o:) and also
some menus definitions. Our menus, especially the menus-programs
and (mini)icons styles are build and rebuild from this data
base using a new version of fvwm-themes-menuapp (any name
suggestion?).

More details, there are a file categories which defines the 
categories we consider for an application: it may look like this

[category]
id=programs
name.en=Programs
name.fr=Applications
name.ru= ...
wm_icon=utilities.xpm
kde_icon=packages.xpm
gnome_icon= ?
contains+=utilities
contains+=office
conatains+=internet
contains+=text
contains+=system
contains+=science
contains+=graphics
contains+=multimedias
contains+=games
contains+=toys
contains+=miscenallous

[category]
id=utilities
name.en=utilities
...
wm_icons=utilities.xpm
...
contains+=basic
contains+=resources
contains+=development


...etc

Definition of the categories may need some discussions sub categories.

Then for each main category we have a file with the applications
(I prefer that than one file for each app). An application
have an entries of the form

[item]
id=netscape_browser
exec=netscape
# may contains "undefined" category at the end ... 
category=internet::browser::netscape
wm_icons=netscape.xpm
class=Netscape
resource=Navigator
style+=any style needed by a special app
... any other things that we need
son+id=preferences
son.{wm_icons,resource,style, any other thing that we need}=
son+id=download
...

I will try to start this, so I need comments ...

Thanks, Olivier

In line Doc Format

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

ChangLog worte:

        * locale/en/FvwmScript-ThemesCenter.txt:
        finished rewording;
        I don't like very much that this format is neither txt nor sgml
        (sgml uses <para> and more), I want to convert this to subset of
xhtml
        if there are no objections. xhtml is both html (so any browser
can
        view these files) and xml (so we may enhance it later if
needed).

Ok no problem, but fvwm-themes-script must understand the format
and also update the README :o)

Olivier

fvwm.t.o

[Charlie S. <ish...@th...>]

-

Alex contacted me about fvwm.themes.org, as I had expressed interest some months
ago in getting it started.  At the time, I believe there wasn't a great deal of
interest in getting it set up, as Fvwm was undergoing major changes, and the 
various theme formats were not yet complete.

I run as.themes.org, and would be willing to help set up fvwm.themes.org, but
since I don't have a huge amount of time on my hands anymore, and because I've
never used Fvwm, it would be much better for your own people to get it going.

Pop in #themes.org on irc.openprojects.net, or email fee...@th... or 
kf...@th... and see about getting it started.

fvwm.t.o will need (at a minimum) a Project Lead, and a Maintainer (although,
extra people are always welcome and needed).  I believe we still want to keep
all the graphics work internal (by artwiz), but the layout is up to the Project
Lead.

Anyways, apologies I took so long getting back to Alex and you about this, but as
I said, I don't have a huge amount of time for much of anything but school work 
lately.

Any other questions or whatever, please email me.

-- 
Charlie Schmidt - ish...@th...

Re: fvwm & fvwm-themes on dual-headed display

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

On 20 Nov 2000 18:46:13 +0200, Mikhael Goikhman wrote:
> 
> The problem of this method is that now there are 2 independent sets of
> sessions and user themes. If you ever want to share them, you can execute:
> 
>   ln -s ../.fvwm/themes $HOME/.fvwm:0.0/themes
>   ln -s ../.fvwm/themes $HOME/.fvwm:0.1/themes
>   ln -s ../.fvwm/current-one $HOME/.fvwm:0.0/current-one
>   ln -s ../.fvwm/current-one $HOME/.fvwm:0.1/current-one

My mistake, you will not want to share the whole themes/ dir. It should be:

  ln -s ../../.fvwm/themes/personal $HOME/.fvwm:0.0/themes/personal
  ln -s ../../.fvwm/themes/personal $HOME/.fvwm:0.1/themes/personal
  ln -s ../../.fvwm/themes/current-one $HOME/.fvwm:0.0/themes/current-one
  ln -s ../../.fvwm/themes/current-one $HOME/.fvwm:0.1/themes/current-one

Regards,
Mikhael.

Re: fvwm & fvwm-themes on dual-headed display

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

This is a long message, but it may help to understand the topic better.

On 19 Nov 2000 09:39:41 -0800, Eric West wrote:
> 
> Mikhael Goikhman wrote:
> 
> > On 18 Nov 2000 18:06:17 -0800, Eric West wrote:
> > >
> > > For your reference, here is how I used
> > > to run dual-headed fvwm (in .xinitrc):
> > >
> > > exec fvwm2 -f /home/eric/.fvwm2rc0 -s -d :0.0 &
> > > exec fvwm2 -f /home/eric/.fvwm2rc1 -s -d :0.1
> > >
> > > With fvwm-themes, I now run it like this:
> > >
> > > exec fvwm-themes-start -s one -- -s -d :0.0 &
> > > exec fvwm-themes-start -s two -- -s -d :0.1
> >
> > I will add this to FAQ.
> > 
> > Please solve my ignorance on this topic. What does it mean physically
> > dual-headed displays? 2 displays, 1 keyboard, 1 mother board?
> 
> I'm glad you asked this question because I think I found a problem with
> (or lack of a feature :) with fvwm-themes.  First, a dual-headed system
> is one with one PC and one keyboard, but two graphics cards and two
> monitors. Now you can even get one graphic card with two or even four
> VGA connectors on them.  The advantage of using one card with two
> connectors is that you can actually drag windows between the two
> displays (The two displays act as one big desktop).
> 
> > Does it make sence to run one fvwm or two fvwm's on such displays?
> 
> If I run one fvwm session I get the same theme on both displays.  It
> appears that I can change the themes on both displays independently, but
> whenever I start up the window manager I start out with the two displays
> showing the same theme.  Before I started using fvwm-themes, I solved
> the startup problem by running two separate fvwm sessions each with
> their own .fvwmrc file. The problem I'm having with fvwm-themes is that
> even though I give each fvwm-theme instance its own session name, they
> always start up with the same theme.  I'm still looking into it though,
> but any suggestions you have would be welcome.

Ok, I should actually know myself what happens. Although I still don't
understand what are pluses of dual-headed displays, I know that when you
run fvwm on such displays without -s, it spawns itself on all screens.
This is not quite good, because it should better spawn fvwm-themes-start
with different parameters instead... But this is not possible for now.

> I thought I found a work-around for my problem, but it doesn't quite
> work.  In my .xinitrc file I tried this:
> 
> exec fvwm2 -f /home/eric/.fvwm/themes-rc1 -s -d :0.0 &
> exec fvwm2 -f /home/eric/.fvwm/themes-rc2 -s -d :0.1
> 
> With .fvwm/themes-rc1 reading from  'themes/current-one/themes-rc-2'
> and .fvwm/themes-rc2 reading from 'themes/current-two/themes-rc-2'
> Initially this worked, but when I change the theme in display two and
> then restart fvwm, I lose the new theme applied to display two.  Worse
> yet, if I quit fvwm and start back up again, the new theme I selected
> for display two shows up on display one.

After some thinking I have found a simple solution. You should run:

  env FVWM_USERDIR=$HOME/.fvwm:0.0 fvwm-themes-start -s one -- -s -d :0.0 &
  env FVWM_USERDIR=$HOME/.fvwm:0.1 fvwm-themes-start -s two -- -s -d :0.1

Then, both screens are independent, they use different user directories.
Because of this you don't really need to specify "-s one" and "-s two".
The problem of this method is that now there are 2 independent sets of
sessions and user themes. If you ever want to share them, you can execute:

  ln -s ../.fvwm/themes $HOME/.fvwm:0.0/themes
  ln -s ../.fvwm/themes $HOME/.fvwm:0.1/themes
  ln -s ../.fvwm/current-one $HOME/.fvwm:0.0/current-one
  ln -s ../.fvwm/current-one $HOME/.fvwm:0.1/current-one

The session part is tricky. Probably we should suggest not to use sessions
at all with multi-headed displays to avoid confusion. Also probably we can
later move all current-session directories into $FVWM_USERDIR/sessions/.

I hope, using FVWM_USERDIR and optionally symlinks one can have any setup.

Regards,
Mikhael.

Re: organizational issues

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

On 19 Nov 2000 15:21:32 +1030, Alex Wallis wrote:
> 
> Mikhael Goikhman wrote:
> > 
> > I have registered "users" list fvw...@li....
> 
> Okay I joined. Is this a list that users should be encouraged to write
> to for fvwm-themes questions and/or comments?

Yes, fvwm-themes specific questions and/or comments from users.

> > Do we need fvwm.themes.org? If yes, who wants to help to maintain it?
> 
> I got in touch with Charlie Schmidt from themes.org while on irc.
> He's going to write to here again soon I believe.

Good. He may just start and say what is absent in a new thread.
I know that graphic designers are absent...

> I think we need some sort of page on themes.org and quickly.
> I'll help where/if I can.

I would prefer to do it right (even it means more time) rather than having
"some sort of page quickly". Anyway, I leave this to ishamael to decide.

Regards,
Mikhael.

Re: organizational issues

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

Mikhael Goikhman wrote:
> 
> -= 1 =-
> 
> I have registered "users" list fvw...@li....
> I don't know whether we need this list right now, but we will need this
> at some point anyway. There are currently 2 subscribers, I and Olivier.
> Info: http://lists.sourceforge.net/mailman/listinfo/fvwm-themes-users

Okay I joined. Is this a list that users should be encouraged to write
to for fvwm-themes questions and/or comments?

> 
> -= 2 =-
> 
> Do we need fvwm.themes.org? If yes, who wants to help to maintain it?
> I personally can live without f.t.o, but it seems that users want this.
> I can help on this. Volunteers to spend a time on this, please reply.
> 
I got in touch with Charlie Schmidt from themes.org while on irc.
He's going to write to here again soon I believe.

I think we need some sort of page on themes.org and quickly.
I'll help where/if I can.

Alex

Re: Nevermind

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

On 18 Nov 2000 11:39:29 -0800, Eric West wrote:
> 
> Please disregard my last Email about not getting fvwm-themes to work
> on two displays.  I got it to work, and it works well.

Oh, I should read all emails first before starting to reply...

> Fvwm-Themes is a great package!

Thanks. :)

Regards,
Mikhael.

fvwm & fvwm-themes on dual-headed display

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

On 18 Nov 2000 10:48:37 -0800, Eric West wrote:
> 
> I have successfully installed fvwm-themes for the first time. When
> I execute
>  fvwm-themes-start I get the following error message:
> 
> [FVWM-Themes]: Welcome to FVWM Themes 0.4.0!
> [FVWM-Themes]: Starting FVWM under the main fvwm-themes session
> [FVWM.0][SetupICCCM2]: <<ERROR>> another ICCCM 2.0 compliant WM is
> running, try -replace
> sky2:~ 2> [FVWM.1][SetupICCCM2]: <<ERROR>> another ICCCM 2.0 compliant WM
> is running, try -replace

fvwm-themes-start is just a shell wrapper to fvwm2. It seems that you run
this script while you already running another window manager (supposedly
fvwm). If this is the case, open FvwmConsole or FvwmTalk and execute:

  Restart fvwm-themes-start

To always start fvwm-themes, just start fvwm-themes-start instead of fvwm2
in your ~/.Xclients (or ~/.xinitrc or other method you use).

> I suspect this is because I am running a dual-headed display with separate
> 
> fvwm's running on each head.  Is this okay or do I somehow need to work
> around it?

I have never had an experience with dual-headed displays, but there were
successful reports of running fvwm on such displays.

Of course, if the problem is really related to the display, please
describe all your steps and we will try to debug the problem.

Regards,
Mikhael.

Nevermind

[Eric W. <eri...@as...>]

Hi -

Please disregard my last Email about not getting fvwm-themes to work
on two displays.  I got it to work, and it works well.  Fvwm-Themes is
a great package!

-Eric West

organizational issues

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

-= 1 =-

I have registered "users" list fvw...@li....
I don't know whether we need this list right now, but we will need this
at some point anyway. There are currently 2 subscribers, I and Olivier.
Info: http://lists.sourceforge.net/mailman/listinfo/fvwm-themes-users

-= 2 =-

Do we need fvwm.themes.org? If yes, who wants to help to maintain it?
I personally can live without f.t.o, but it seems that users want this.
I can help on this. Volunteers to spend a time on this, please reply.

Regards,
Mikhael.

Re: locale

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

On 16 Nov 2000 22:35:15 +0100, Olivier Chapuis wrote:
> 
> The format seems ok for me. The problem is how the Script will read
> the data. At the present time the Script make its internationalization
> at startup (Themes Center set somethings like 37 variables and changes 
> 30 Titles). I do not know exactly how to implement the communication
> (Script is not very good for "reading" multiline via com or cat). 

It would be fine if FvwmScript supported hashs (but I think only perl
handles such nice data type). At least FvwmScript supports array, right?
You can transfer an entire array of messages into array variable.

So, you can try to solve an indexing problem, i.e. how to convert from
symbolic hash ids to actual array indexes.

> Also Script name its widgets by number (boring!). All this imply
> a rigid strategy for reading the data. For avoiding confusion (widget
> Id, position in array and msg id) it is may be preferable to replace
> the id number N by an english string?

id may be anything, which helps to FvwmScript or to an other i18n client.
But I am against id to be english message. We are not english speakers,
so we will change English text sometimes, we don't really need to
change all LANG files in this case, just one file.

Also English has simplistic syntax. If we have English as id, our
translations may be poor; using something not bound to English solves
this. In a good data base, unique ids should have no meaning if possible.

What about using FvwmScript widget numbers as part of id? :)
Say all global messages start with '-', all messages belonging to widget 1
start with '1-' and so on. Anything else as a separator is good too.

So, the problem is to translate from 12-3 to its place in the array.
Or maybe any script sample just will have an exec-function, which gets id
12-3 (third message for 12-th widget) and returns the translated string
via com (the LANG and domain are passed at the very beginning).

Of course, I may be wrong. You choose.

> You mean:
> 
> id[TAB]begin of a sentence %s end of the sentence
> 
> where %s have to be replaced by somethings? 

Only if this helps.

Regards,
Mikhael.

Re: locale

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

Mikhael Goikhman wrote:
> 
> > For the internal of the GUI: locale/LANG/foo.msg
> 
> Ok. I think we can have the following format of this file:
> 
> N[Tab]message
> 
> where N is a msg id number, needed if we want to add/remove some messages
> without totally breaking existing *.msg files. This id also makes it
> easier to manage this file. Some perl script (fvwm-themes-script or
> fvwm-themes-config) may provide a service (via com) - get a message
> by a domain (foo) and a message id (N). Files foo.msg are processed,
> converted to a hash and cached in memory.
>

The format seems ok for me. The problem is how the Script will read
the data. At the present time the Script make its internationalization
at startup (Themes Center set somethings like 37 variables and changes 
30 Titles). I do not know exactly how to implement the communication
(Script is not very good for "reading" multiline via com or cat). 
Also Script name its widgets by number (boring!). All this imply
a rigid strategy for reading the data. For avoiding confusion (widget
Id, position in array and msg id) it is may be preferable to replace
the id number N by an english string?
I will try to think more on these by making some real tests with the
Themes Center.
  
> I am not sure whether 'message' can be a multi-line string, if yes,
> it may end-up with backslash. Maybe we can use modifiers %s, %n, I am
> not sure yet.
>

You mean:

id[TAB]begin of a sentence %s end of the sentence

where %s have to be replaced by somethings? 
About multiline I do not think we need it for Scripts.

> We can also have other info in this file, like font used: FONT[Tab]font.
>

Yes.

Olivier

Re: rpm packages for SuSE linux

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

On 15 Nov 2000 13:17:53 +1030, Alex Wallis wrote:
> 
> All points noted and mostly valid. However I can't see any logic in
> producing rpm's for SuSE that are essentially the same as redhat rpm's,
> and don't even try to comply with SuSE system organisation. Setting
> $PATH & $MANPATH is simply a matter of adding a couple of lines to
> /etc/profile.
> So why is adding /opt/fvwm/bin into all users $PATH unacceptable?

The logic is simple, if we use prefix /usr, everything works out of box,
if we use prefix /opt/fvwm nothing works out of box. Currently we have a
common distribution-independent logic in producing rpm's, it is good.

If you really want to comply with SuSE structure, get its fvwm2-2.2.2
package and install to these directories. I.e. executables should be in
the place, which is in all SuSE users $PATH, like /usr/X11R6/bin, the same
about man pages and so on. But if you do this, users will not be able to
install your fvwm package, since its /usr/X11R6/bin/fvwm2 will conflict
with the same file from fvwm2 package. With /usr prefix there are no
conflicts; users can have both fvwm 2.2 and 2.3 versions on their systems.

Regards,
Mikhael.

Re: rpm packages for SuSE linux

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

Mikhael Goikhman wrote:
> 
> On 15 Nov 2000 03:25:09 +1030, Alex Wallis wrote:
> >
> 
> Sorry to disappoint you, but until they (SuSE or others) decide to include
> anything to their distribution, these rpm's does not change anything.
> They are rebuilding all their rpm's themselves anyway. :)

I know, but at least they're available now.

> 
> I myself use /opt/fvwm prefix for manually compiled fvwm, but this is not
> a good location for general use, since it requires adding /opt/fvwm/bin
> into all users $PATH (unacceptable), and adding /opt/fvwm/man to $MANPATH.
> 
> At least, /usr/bin and /usr/man are guaranteed to be in $PATH and $MANPATH.
> 

All points noted and mostly valid. However I can't see any logic in
producing rpm's for SuSE that are essentially the same as redhat rpm's,
and don't even try to comply with SuSE system organisation. Setting
$PATH & $MANPATH is simply a matter of adding a couple of lines to
/etc/profile.
So why is adding /opt/fvwm/bin into all users $PATH unacceptable?

Alex

Re: rpm packages for SuSE linux

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

On 15 Nov 2000 03:25:09 +1030, Alex Wallis wrote:
> 
> For the past 5 or 6 years I've been happy to compile all versions of
> fvwm with default paths, usualy --prefix=/usr/local.
> 
> However when I switched to SuSE linux I noticed that fvwm was the only
> package to use such a prefix. All other window manager packages use
> either the traditional /usr/X11R6/lib/X11/name path or the newer
> /opt/name. Happy in my ignorance, I still used the default paths.

fvwm or fvwm-themes are not different from any other autoconf-based
package. It is only distributions specifying different paths.

For example, some distribution may configure fvwm with:

  ./configure --bindir=/usr/X11R6/bin --libexecdir=/usr/X11R6/lib/X11 \
    --mandir=/usr/X11R6/man --sysconfdir=/etc --datadir=/usr/X11R6/share

You can specify configure parameters in cparams when building our rpms.
But I would leave these path games to the distributions and stick with
--prefix=/usr for our rpm's. Not that there are no reasons for changing
these directories. There are a lot of reasons to justify any choice.
So, it is more clever for us just to choose the working default prefix.

> This also complies completely with standard SuSE installations. Perhaps
> we can now get fvwm-themes included in SuSE distributions. I've built
> all rpm's this way, and all configs, executables etc, are in the
> /opt/fvwm path.

Sorry to disappoint you, but until they (SuSE or others) decide to include
anything to their distribution, these rpm's does not change anything.
They are rebuilding all their rpm's themselves anyway. :)

I myself use /opt/fvwm prefix for manually compiled fvwm, but this is not
a good location for general use, since it requires adding /opt/fvwm/bin
into all users $PATH (unacceptable), and adding /opt/fvwm/man to $MANPATH.

At least, /usr/bin and /usr/man are guaranteed to be in $PATH and $MANPATH.

Regards,
Mikhael.

rpm packages for SuSE linux

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

For the past 5 or 6 years I've been happy to compile all versions of
fvwm with default paths, usualy --prefix=/usr/local.

However when I switched to SuSE linux I noticed that fvwm was the only
package to use such a prefix. All other window manager packages use
either the traditional /usr/X11R6/lib/X11/name path or the newer
/opt/name. Happy in my ignorance, I still used the default paths.

Now we are releasing rpm's, and I do have an SuSE system, I thought I'd
better start doing things properly.

With the introduction of fvwm-themes, I believe fvwm is sufficiently
sophisticated to break with tradition and complex enough to deserve to
share the /opt directory tree alongside such packages as gnome and kde,
netscape etc.

This also complies completely with standard SuSE installations. Perhaps
we can now get fvwm-themes included in SuSE distributions. I've built
all rpm's this way, and all configs, executables etc, are in the
/opt/fvwm path.

There's possibly still some tweaking of the packages, I'll do some
testing and keep packages updated and fresh when I can.

When I figure out the ssh1 stuff, I'll try to upload them to
sourceforge. :)

Regards,
Alex

Re: locale

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

On 14 Nov 2000 07:54:40 +0100, Olivier Chapuis wrote:
> 
> Does someone have an idea about the locale/LANG naming
> convention?

You can guess yourself by taking a look at /usr/share/locale/ or so.
But this is a standard C convention, we may use our own, I think.
Also 'info gettext' may help.

> Here a simple proposition for a GUI named foo:
> 
> For the inline doc: locale/LANG/foo.doc

foo.txt

> For the internal of the GUI: locale/LANG/foo.msg

Ok. I think we can have the following format of this file:

N[Tab]message

where N is a msg id number, needed if we want to add/remove some messages
without totally breaking existing *.msg files. This id also makes it
easier to manage this file. Some perl script (fvwm-themes-script or
fvwm-themes-config) may provide a service (via com) - get a message
by a domain (foo) and a message id (N). Files foo.msg are processed,
converted to a hash and cached in memory.

I am not sure whether 'message' can be a multi-line string, if yes,
it may end-up with backslash. Maybe we can use modifiers %s, %n, I am
not sure yet.

We can also have other info in this file, like font used: FONT[Tab]font.

> Also it seems that we have to do internationalization
> of some of the perl script. What are the usual way
> to do it?

ftp://uiarchive.cso.uiuc.edu/pub/lang/perl/CPAN/modules/by-module/Locale/gettext-1.01.readme

There are also other resources in this and parent directory.

But I would not use any CPAN modules. We may reimplement this gettext API,
it is not hard. But probably our own getmessage(id[, domain]) API is not
any worser for our purposes. Let start with i18n for FvwmScript first.

Regards,
Mikhael.

locale

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

Hello,
Does someone have an idea about the locale/LANG naming
convention?
Here a simple proposition for a GUI named foo:

For the inline doc: locale/LANG/foo.doc
For the internal of the GUI: locale/LANG/foo.msg

Also it seems that we have to do internationalization
of some of the perl script. What are the usual way
to do it?

Olivier

Re: Happy User of FVWM themes

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

Thanks, John, for the very positive feedback.

On 13 Nov 2000 08:01:21 -0500, John Califf wrote:
> 
> In summary, I feel that you should release fvwm themes along with a
> compatible version of fvwm2 beta as FVWM 3.  It is long overdue. Why? 
> Because it meets a real need, and in my opinion the fvwm organization is
> too conservative to make the needed move to fvwm 3.

Hmm, why should we take over fvwm and release FVWM 3.0? :)
I don't see how this will be better than it is now, except for biz-buzz.

Developing a window manager is a very hard work. There is no much sence
to fork a good window manager. Although, we with Olivier are also fvwm
developers, currently we mostly concentrate our energy on fvwm-themes,
and want to use the existing fvwm, not to reinvent it.

About fvwm releases. Yes, they are a bit slow to come, mostly because of
amount of work, and because we want to have fvwm 2.4 with as less bugs as
possible. We know, there are problems (although they may seem not
important for less demanding users). The plans are to release FVWM 2.4
soon as a much improved, but still mostly compatible to 2.2 version.
Then there are plans (this may take much time) to go to a new FVWM 3.0,
which may be even incompatible with 2.2/2.4.

> ... Therefore fvwm has been regarded by most people new to Linux and
> free unix as "unsexy" and undesirable.  Further, the lack of graphical
> configuration utilities has not helped.

This may be true for most of new to unix people. But FVWM was and still is
mostly for unix people, it does not have a task to absorb windows users,
something, that KDE and GNOME have. And although we try to popularize
fvwm, our main point at fvwm-themes is to serve free unix people, not to
take over the world. :)

> All this has changed with fvwm themes.

If you are right that fvwm is a more real alternative now, it is nice.

> I can make a committment to submit a theme - a "Kde 2" theme that looks
> and acts in most ways like the Kde 2 window manager, along with a
> modified version of the FvwmTaskbar module (C code), possibly, that
> looks and acts in most ways like Kde's Kicker panel.  At least the theme
> itself I can do.

This would be really good. Can I suggest to use FvwmButtons instead of
FvwmTaskBar as a more configurable fvwm module? Anyway, if you patch
FvwmTaskBar or FvwmButtons, please post your modifications here to
fvw...@fv....

> You also need a script to insert Kde 2 menu items into the fvwm menu.
> NOT the old kde 1.x menus.  The directory structure of where the
> applinks, now called .desktop files as in Gnome, and icons are stored is
> different. This should probably be written in perl, and I can try to
> write that or perhaps one is already out there.

I think changes to fvwm-menu-desktop are fairly simple. When I or Olivier
figure out what is changed, we may patch it to support kde2 automatically
when kde menus are requested, or using a separate kde2 option.

> I am already on too many mailing lists, but will try to remember to send
> you the Kde 2 theme when it is done and tested.

Yes, please don't forget it. :) We may help you to test or improve it.

> Please, release fvwm 3 SOON and make a lot of noise about it with press
> releases.  The moment is ripe, and it may not come again.  Fvwm Themes
> should be an official part of fvwm 3, not something people have to
> locate and download separately.

It is not so hard to install two packages (from sources or rpms) instead
of one. We can set up an easy to install suite, but forking from fvwm
is not an option, we want to use existing FVWM, not to lead a new WM! :)

> John Califf

Regards,
Mikhael.

Re: Happy User of FVWM themes

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

Hello John,

Many thanks for your message. About making FVWM 3 Mikhael can give
a better answer (my english is so bad). But, FVWM 3 is a "technical
project" which will be released after fvwm-2.4. But I'm agree that 
fvwm-2.4 plus fvwm-themes-1.0.0 will be a FVWM revolution :o)

I understand that you have no time to help us. However, the
message you send to the mailing list help us. We are very
interested by feedack and bugs reports. So, sending such
a message some times will help ...

About the config center it was broken in 0.3.x but I hope it works
in 0.4.0. If it does not work can you send a bug report (removing
.fvwm/ may help but I think this is also fixed)

Regards, Olivier

Happy User of FVWM themes

[John C. <jc...@co...>]

I have been meaning to write you for some time, and the recent notice
about the 4.0 release has finally prompted me to write.

In summary, I feel that you should release fvwm themes along with a
compatible version of fvwm2 beta as FVWM 3.  It is long overdue. Why? 
Because it meets a real need, and in my opinion the fvwm organization is
too conservative to make the needed move to fvwm 3.

Fvwm has many plusses as a window manager - it's one of the few window
managers that takes full advantage of multiple desktops and workspaces,
and its pager, also used by Afterstep, is the standard.  It has an open,
spacious feel and great configurability.  However, releases of fvwm that
have come with Linux distros have been just plain UGLY due to a lack of
artistic taste in choosing default icons and styles.  Therefore fvwm has
been regarded by most people new to Linux and free unix as "unsexy" and
undesirable.  Further, the lack of graphical configuration utilities has
not helped.

All this has changed with fvwm themes.  I'm using it right now. Colors
and menu styles from the Luthien them, modules from olicha, background
from the default theme (plain gray).  What a pleasing visual
environment, easily modified with menus.  No editing of configuration
files is required, although I also enjoy doing that sometimes.  Even the
menus themselves can be modified with the menu editor.

There have been a few bugs, but most of these are now fixed.  I consider
fvwm snapshots with fvwm themes to be rock solid overall, and the few
bugs I've encountered can be worked around just by disabling certain
menu items.  Right now the only bug I know about is that the
"configuration center" crashes on loading so I commented that item out,
but the individual config items can be accessed from the menu. But, you
probably alredy have that fixed.

Again, congratulations on a job well done.  No, I can't work on the
coding. I despise perl but admit you have used it well in this utility.
Actually, I'm a kde developer.  Kde 2 apps work well with fvwm 2 betas.

I can make a committment to submit a theme - a "Kde 2" theme that looks
and acts in most ways like the Kde 2 window manager, along with a
modified version of the FvwmTaskbar module (C code), possibly, that
looks and acts in most ways like Kde's Kicker panel.  At least the theme
itself I can do. Your Afterstep and Blackbox themes are good enough to
fool anyone but a long time user of Afterstep or Blackbox, while also
offering the many advantages of fvwm to those who like the look and feel
of other environments.  Note:  You also need a script to insert Kde 2
menu items into the fvwm menu.  NOT the old kde 1.x menus.  The
directory structure of where the applinks, now called .desktop files as
in Gnome, and icons are stored is different. This should probably be
written in perl, and I can try to write that or perhaps one is already
out there.  While I don't much like perl, perl is designed for such text
processing.  But a shell script would also work fine.

I am already on too many mailing lists, but will try to remember to send
you the Kde 2 theme when it is done and tested.

Please, release fvwm 3 SOON and make a lot of noise about it with press
releases.  The moment is ripe, and it may not come again.  Fvwm Themes
should be an official part of fvwm 3, not something people have to
locate and download separately.

John Califf