fvwm-themes-devel — Developing FVWM Themes

Re: fvwm-themes: patches to use fontsets instead of single fonts

[Mike F. <mf...@su...>]

Mikhael Goikhman <mi...@ho...> writes:

> On 21 May 2001 20:14:21 +0200, Mike Fabian wrote:
> > 
> > Mikhael Goikhman <mi...@ho...> writes:
> > > 
> > > Ok, I implemented an initial solution for a new "fonts" component.
> > > (I still didn't decide what to do about module fonts, there are many.)
> > > This will be available in the next fvwm-themes, probably 0.5.0.
> > > 
> > > If you want this to work out of the box for Japanese (although I don't
> > > understand this, does not fontsets only work on systems with only Japanese
> > > fonts installed and on other systems latin fonts are used not Japanese?),
> > 
> > As far as I undertand it, the patterns in a fontset should
> > be subsequently tried, i.e. in a command like
> > 
> >     Style * Font "-*-lucida-bold-r-*-*-12-*,-*-*-medium-r-*--14-*,*"
> > 
> > first "-*-lucida-bold-r-*-*-12-*", then "-*-*-medium-r-*--14-*", then
> > "*" should be tried, with the encoding as necessary for the compound
> > text to be displayed, i.e. for Japanese the encoding part of the XLFD
> > is "jisx0208.1983-0" (or "jisx0208.1990-0") and system should look for
> > "-*-lucida-bold-r-*-*-12-*-jisx0208.1983-0",
> > "-*-*-medium-r-*--14-*-jisx0208.1983-0" and finally
> > "*--jisx0208.1983-0". If the Fontset ends with "*", at least something
> > should be found if fonts for the requested language are installed at
> > all, although this something may be very ugly.
> > 
> > So this approach should work for latin as well. For example,
> > it does work for German *and* Japanese on my system (And for Chinese
> > and Korean and probably all other languages where I have fonts installed).
> 
> There should be some mechanism which, say, locks font charset, so for some
> systems the second patern is prefered. Otherwise I see no point in fontsets.
> I would like to learn more about this mechanism. Is prefered charset is set
> in some environment variable or given in some file?

I think the relevant environment variable is LC_CTYPE.

  ~$ LC_CTYPE=ja_JP startx

will give me a fvwm2 session which can display Japanese in the window
titles, menus, etc. ... (using the second pattern in the fontset,
because the first doesn't match anything with jisx0208 encoding). But
this fvwm2 session will neither display German nor Korean correctly.

  ~$ LC_CTYPE=de_DE startx

will give a fvwm2 session which displays German correctly and

  ~$ LC_CTYPE=ko_KR startx

one which works for Korean.

> > > you may patch a single file themes/default/fonts to use fontsets on SuSE,
> > > if its X Server (or xfs) supports fontsets.
> > 
> > Thank you, that would make it easier than it is currently,
> > 
> > > But, I think, there is a better solution to ensure that Japanese fonts are
> > > used even if latin fonts are the first in the fontpath. I included a
> > > component fonts@multichoice in several variants (several languages),
> > > so a user may choose "Japanese (jisx0208)" or "Cyrillic (koi8-r)".
> > 
> > I must check whether that works. Is it available already in
> > fvwm-themes?
> 
> Yes, in cvs it was available for some time. Here is a snapshot for ones
> without cvs who wants to check a new stuff:
> 
>   http://fvwm-themes.sourceforge.net/tmp/


> The latest fvwm from cvs is needed for snapshot to work without glitches,
> but it may work with any fvwm >= 2.3.30 if small glitches are ok. As usual
> "Restart fvwm-themes-start" or "Reset all to default" after instalation.
> 
> The fonts component is not finalized yet.

Thank you very much, I'll try to check that next week. 

-- 
Mike Fabian   <mf...@su...>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。

Re: nanoGUI colors-decor

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

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

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

Regards, Olivier

Re: nanoGUI colors-decor

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

On 31 May 2001 08:46:16 +0200, Olivier Chapuis wrote:
> 
> It seems that it is not possible to drop the nanoGUI colors-decor
> component. With buttons@olicha and colors@luthien when I try
> to drop colors-decor@nanogui I get an xmessage that say that
> "Dropping of this component is not supported".

Ok, fixed.

I would like this solution with colors-decor@ if not some small things.
It is probably ok when colorsets are defined twice, but it is not ok when
TitleStyle is defined twice, there is blinking. The solution would be to
divide colors@ to several parts, each defines its own function (for decor,
menu, modules), which are called from in StartColors function, so other
components like colors-decor would overwrite one of such functions.
Or maybe just add a function for TitleStyle commands. This also would
fix a current problem that image dir ~/.fvwm/themes/current/images/decor
should be linked as defined in colors@ and not in colors-decor@.

Do you think it is good to change colors@ as I described?
I would try not to add complexity if possible.

Regards,
Mikhael.

nanoGUI colors-decor

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

Hello,
It seems that it is not possible to drop the nanoGUI colors-decor
component. With buttons@olicha and colors@luthien when I try
to drop colors-decor@nanogui I get an xmessage that say that
"Dropping of this component is not supported".
Olivier

Re: fvwm-themes: patches to use fontsets instead of single fonts

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

On 21 May 2001 20:14:21 +0200, Mike Fabian wrote:
> 
> Mikhael Goikhman <mi...@ho...> writes:
> > 
> > Ok, I implemented an initial solution for a new "fonts" component.
> > (I still didn't decide what to do about module fonts, there are many.)
> > This will be available in the next fvwm-themes, probably 0.5.0.
> > 
> > If you want this to work out of the box for Japanese (although I don't
> > understand this, does not fontsets only work on systems with only Japanese
> > fonts installed and on other systems latin fonts are used not Japanese?),
> 
> As far as I undertand it, the patterns in a fontset should
> be subsequently tried, i.e. in a command like
> 
>     Style * Font "-*-lucida-bold-r-*-*-12-*,-*-*-medium-r-*--14-*,*"
> 
> first "-*-lucida-bold-r-*-*-12-*", then "-*-*-medium-r-*--14-*", then
> "*" should be tried, with the encoding as necessary for the compound
> text to be displayed, i.e. for Japanese the encoding part of the XLFD
> is "jisx0208.1983-0" (or "jisx0208.1990-0") and system should look for
> "-*-lucida-bold-r-*-*-12-*-jisx0208.1983-0",
> "-*-*-medium-r-*--14-*-jisx0208.1983-0" and finally
> "*--jisx0208.1983-0". If the Fontset ends with "*", at least something
> should be found if fonts for the requested language are installed at
> all, although this something may be very ugly.
> 
> So this approach should work for latin as well. For example,
> it does work for German *and* Japanese on my system (And for Chinese
> and Korean and probably all other languages where I have fonts installed).

There should be some mechanism which, say, locks font charset, so for some
systems the second patern is prefered. Otherwise I see no point in fontsets.
I would like to learn more about this mechanism. Is prefered charset is set
in some environment variable or given in some file?

> > you may patch a single file themes/default/fonts to use fontsets on SuSE,
> > if its X Server (or xfs) supports fontsets.
> 
> Thank you, that would make it easier than it is currently,
> 
> > But, I think, there is a better solution to ensure that Japanese fonts are
> > used even if latin fonts are the first in the fontpath. I included a
> > component fonts@multichoice in several variants (several languages),
> > so a user may choose "Japanese (jisx0208)" or "Cyrillic (koi8-r)".
> 
> I must check whether that works. Is it available already in
> fvwm-themes?

Yes, in cvs it was available for some time. Here is a snapshot for ones
without cvs who wants to check a new stuff:

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

The latest fvwm from cvs is needed for snapshot to work without glitches,
but it may work with any fvwm >= 2.3.30 if small glitches are ok. As usual
"Restart fvwm-themes-start" or "Reset all to default" after instalation.

The fonts component is not finalized yet.

Regards,
Mikhael.

make dist2 fails

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

While doing some testing I found that make dist2 and make dist4 fails
with the following errror...

bzip2: -c expects at least one filename.

I just checked and fvwm has the same error.

Alex

Re: Syntax error?

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

On Tuesday 22 May 2001 11:11, you wrote:
> With todays cvs I get this....
>
> awol@awol:~ > fvwm-themes-config --help
> Not enough arguments for mkdir at /opt/fvwm/bin/fvwm-themes-config line
> 2208, near ");"
> Execution of /opt/fvwm/bin/fvwm-themes-config aborted due to compilation
> errors.
>

I hope this is fixed now.
Olivier

Re: Is there going to be a new "stable" release of fvwm-themes?

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

On Tuesday 22 May 2001 03:03, you wrote:
> On 21 May 2001 21:59:42 +0200, Olivier Chapuis wrote:
>
> The small thing to decide is whether fvwm-themes package should actually
> mean fvwm-themes-base or fvwm-themes-full. It may be done any way.
>

I suggest to do not have any more a fvwm-themes package and
just have: fvwm-themes-{full,base,extra} and ft-name for each
theme name.

Olivier

Syntax error?

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

With todays cvs I get this....

awol@awol:~ > fvwm-themes-config --help
Not enough arguments for mkdir at /opt/fvwm/bin/fvwm-themes-config line
2208, near ");"
Execution of /opt/fvwm/bin/fvwm-themes-config aborted due to compilation
errors.


Alex

Re: Is there going to be a new "stable" release of fvwm-themes?

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

On 21 May 2001 21:59:42 +0200, Olivier Chapuis wrote:
> 
> > > "foo" which is not in the main dist  an additional tarball
> > >       fvwm-themes-foo-$VERSION.tar.gz
> > > which can be installed/uninstalled with fvwm-themes-config.
> >
> > Perhaps some themes will not change much? Should these themes be
> > re-packed for every release? The themes themselves will also require
> > versions too as they may conceivably change a lot over time.
> > Is it possible, or even desirable, to perhaps have with each release
> 
> It is not difficult to re-pack a themes I think. Again, at the present time,
> I think that a theme should be attached to a ft version. But one may
> imagine that fvwm.themes.org can provied more recent version
> of themes included in ft current version. In any case I think that
> a package should be named as follow:
> 
> prefix-nameof(aset)thetheme-ftversion_extraversion.tar.{bz2,gz}
> 
> e.g.: ft-awol-0.4.3_1.3.tar.gz
> 
> where "_extraversion" is optional (empty for "official" ft themes
> and assumed to be 1.0). This is not yet supported by the --install
> option of fvwm-themes-config but it will be if you and Mikhael are agree
> for this naming scheme.

Seems ok.

> > > 4 - Moreover, some themes can be "unofficial" (and downlodable
> > > from fvwm.themes.org) before its inclusion (or not) in the CVS tree.
> >
> > I think all the themes, including the themes in the main distribution,
> > should be always available for individual download.
> 
> make dist3 does not do this but you can easily do additional tarballs
> with the --create-themes ft-config option.

Ok.

The small thing to decide is whether fvwm-themes package should actually
mean fvwm-themes-base or fvwm-themes-full. It may be done any way.

Regards,
Mikhael.

Re: Is there going to be a new "stable" release of fvwm-themes?

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

Le Lundi 21 Mai 2001 02:27, vous avez écrit :
> Alex, a lot of ways to solve a problem is nice, but someone should just
> take a responsobility to choose the "best" and implement it. Feel free to.
>
> I am not against to have fvwm-themes package with 8 themes starting with
> C, D, L, M, O and R, and fvwm-themes-extra with all other themes from cvs
> and maybe not from cvs. And fvwm-themes-all package may include these two
> together if needed. Or any other solution if someone else does it.
>
> GUI for installing/uninstalling themes from tar.gz or directly from
> f.t.o in user or site place is something to think about (not urgent).
>
> Olivier, do you want to implement packaging as you see it, including rpm?
> If no, we should postpone this.
>

I've just committed the first step (take a look at the change log).
Some problems or remarks:
- The full distribution is still build with make dist{,2} do we have to rename
it fvwm-themes-full or something like that?
- I've do a more or less arbitrary cut between the main themes and
the extra themes. This can be changed easily by editing Makefile.am.
- make install in the cvs tree install all the themes.
Todo:
- build corresponding rpm (I am not sure that I will succeed).
- An --uninstall theme1 theme2 .. option to ft-config (not urgent
   in my own opinion, rm -rf work no so bad). 

Olivier

Re: Is there going to be a new "stable" release of fvwm-themes?

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

Le Lundi 21 Mai 2001 00:20, vous avez écrit :
> Olivier Chapuis wrote:
> > Le Dimanche 20 Mai 2001 18:53, vous avez écrit :
> > > On 21 May 2001 01:37:33 +0930, Alex Wallis wrote:
>
> > I repeat my suggestion here:
> > 1 - I think that all fvwm-themes themes should be in the same CVS tree.
>
> Without limits? The number of themes could quickly become cumbersome.
> Also each theme will increase the size of the project until it becomes
> substantial. It will only take a few themes with sounds included to
> swell the size of fvwm-themes to several megabytes!
>

At the present time we need that "all" ft themes to be in the CVS, because
sometime a change need a change in all themes. Of course "all" is a
bit arbitrary but we will see ... Moreover, this may be changed in the future.
Olivier

> > 2 - But when we  type make dist, this should build the main distribution
> > which say contains the 14 current themes (or less) plus for each theme
> > "foo" which is not in the main dist  an additional tarball
> >       fvwm-themes-foo-$VERSION.tar.gz
> > which can be installed/uninstalled with fvwm-themes-config.
>
> Perhaps some themes will not change much? Should these themes be
> re-packed for every release? The themes themselves will also require
> versions too as they may conceivably change a lot over time.
> Is it possible, or even desirable, to perhaps have with each release

It is not difficult to re-pack a themes I think. Again, at the present time,
I think that a theme should be attached to a ft version. But one may
imagine that fvwm.themes.org can provied more recent version
of themes included in ft current version. In any case I think that
a package should be named as follow:

prefix-nameof(aset)thetheme-ftversion_extraversion.tar.{bz2,gz}

e.g.: ft-awol-0.4.3_1.3.tar.gz

where "_extraversion" is optional (empty for "official" ft themes
and assumed to be 1.0). This is not yet supported by the --install
option of fvwm-themes-config but it will be if you and Mikhael are agree
for this naming scheme.

> > 3 - Maybe it will be good that some themes in the main dist can be
> > uninstalled too.
>
> I think an uninstall option is just as important as install. Say, if
> someone tries a theme they dislike intensely. The only exception of
> course should be the default theme.
>

Not difficult:
	rm -rf the_themes
but we have to check if some themes depend on others.

> > 4 - Moreover, some themes can be "unofficial" (and downlodable
> > from fvwm.themes.org) before its inclusion (or not) in the CVS tree.
>
> I think all the themes, including the themes in the main distribution,
> should be always available for individual download.
>

make dist3 does not do this but you can easily do additional tarballs
with the --create-themes ft-config option.

Olivier

Re: fvwm-themes: patches to use fontsets instead of single fonts

[Mike F. <mf...@su...>]

Mikhael Goikhman <mi...@ho...> writes:

> On 02 May 2001 14:51:17 +0200, Mike Fabian wrote:
> > 
> > Mikhael Goikhman <mi...@ho...> writes:
> > 
> > > On 26 Apr 2001 18:43:46 +0200, Mike Fabian wrote:
> > > > 
> > > > Attached are patches for fvwm-themes to use fontsets instead of single
> > > > fonts.
> > > 
> > > Thank you for contributing!
> > > 
> > > Which X Servers on different unices support fontsets?
> > 
> > I thought all of them do. Isn't the fontset mechanism something which
> > has always been available in X11? Am I mistaken?
> 
> I don't know. To be honest, I first hear about fontsets in your message.
> On my RedHad system with XFree86{,-xfs,-libs,*fonts...}-4.0.3-5 rpms
> the first command:
> 
>   Style * Font "-*-lucida-bold-r-*-*-12-*,-*-*-medium-r-*--14-*,*"
>   Style * Font "-*-lucida-bold-r-*-*-12-*"
> 
> produces this error:
> 
>   [GetFontOrFixed]: WARNING -- can't get font -*-lucida-bold-r-*-*-12-*,-*-*-medium-r-*--14-*,*, trying 'fixed'

Strange, for me the command

    Style * Font "-*-lucida-bold-r-*-*-12-*,-*-*-medium-r-*--14-*,*"

works fine on SuSE 7.2 and I am using the same version of XFree86:

    mfabian@gregory:~$ rpm -q xf86 xshared xdevel
    xf86-4.0.3-27
    xshared-4.0.3-27
    xdevel-4.0.3-27
    mfabian@gregory:~$ 

> Ok, I implemented an initial solution for a new "fonts" component.
> (I still didn't decide what to do about module fonts, there are many.)
> This will be available in the next fvwm-themes, probably 0.5.0.
> 
> If you want this to work out of the box for Japanese (although I don't
> understand this, does not fontsets only work on systems with only Japanese
> fonts installed and on other systems latin fonts are used not Japanese?),

As far as I undertand it, the patterns in a fontset should
be subsequently tried, i.e. in a command like

    Style * Font "-*-lucida-bold-r-*-*-12-*,-*-*-medium-r-*--14-*,*"

first "-*-lucida-bold-r-*-*-12-*", then "-*-*-medium-r-*--14-*", then
"*" should be tried, with the encoding as necessary for the compound
text to be displayed, i.e. for Japanese the encoding part of the XLFD
is "jisx0208.1983-0" (or "jisx0208.1990-0") and system should look for
"-*-lucida-bold-r-*-*-12-*-jisx0208.1983-0",
"-*-*-medium-r-*--14-*-jisx0208.1983-0" and finally
"*--jisx0208.1983-0". If the Fontset ends with "*", at least something
should be found if fonts for the requested language are installed at
all, although this something may be very ugly.

So this approach should work for latin as well. For example,
it does work for German *and* Japanese on my system (And for Chinese
and Korean and probably all other languages where I have fonts installed).

> you may patch a single file themes/default/fonts to use fontsets on SuSE,
> if its X Server (or xfs) supports fontsets.

Thank you, that would make it easier than it is currently,

> But, I think, there is a better solution to ensure that Japanese fonts are
> used even if latin fonts are the first in the fontpath. I included a
> component fonts@multichoice in several variants (several languages),
> so a user may choose "Japanese (jisx0208)" or "Cyrillic (koi8-r)".

I must check whether that works. Is it available already in
fvwm-themes?

-- 
Mike Fabian   <mf...@su...>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。

Re: Is there going to be a new "stable" release of fvwm-themes?

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

Le Lundi 21 Mai 2001 02:27, vous avez écrit :
> Alex, a lot of ways to solve a problem is nice, but someone should just
> take a responsobility to choose the "best" and implement it. Feel free to.
>
> I am not against to have fvwm-themes package with 8 themes starting with
> C, D, L, M, O and R, and fvwm-themes-extra with all other themes from cvs
> and maybe not from cvs. And fvwm-themes-all package may include these two
> together if needed. Or any other solution if someone else does it.
>
> GUI for installing/uninstalling themes from tar.gz or directly from
> f.t.o in user or site place is something to think about (not urgent).
>
> Olivier, do you want to implement packaging as you see it, including rpm?
> If no, we should postpone this.
>

Ok, I will try to do somthing now
Olivier

Making fonts and colors even more flexible

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

There is no much left to do for the next release accept for solving fonts
and colors problems, precisely be able from the one side to define all
fonts and colors in one place, and from the other side in the own places.
For example, sometimes it is good to define fonts and colors of modules in
the place of all other fonts and colors, and sometimes in the place of all
other modules configuration.

I though about 4 ways to solve fonts problems, and as usual no one is
perfect, I think the one which I implemented is good. Although it is
somewhat confusing to have fonts@ component, which by default does
_not_ change any fonts, but instead, the fonts from menustyle@,
windowlook@ and modules@ are used as usual. This fonts@ component probably
may be named fontfilters@.

I plan to add Japanese/Korean/Chinese variants to fonts@multichoice.
I am not sure whether it is a good way for i18n or not, seems to be ok.

I don't know what to do with module fonts, Maybe to have ModuleBig,
ModuleNormal, ModuleSmall and Balloon filters? Olivier, you should help.
Just be aware of a problem: the line "+ I *$0: $1" is not expanded
correctly in fvwm, I want to fix this.

Now about an ability to define only a part of a long colors@.
Here I may think about 5 possible not perfect solutions.
I probably will end up with creating colors-decor@ component similar
to colors-extra@, and implement "auto-drops" config key. This means that
loading of colors@ component would immediately drop colors-decor@, so
users would not need to drop it manually.

Olivier, do you prefer another solution for colors?

Regards,
Mikhael.

Re: Is there going to be a new "stable" release of fvwm-themes?

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

Alex, a lot of ways to solve a problem is nice, but someone should just
take a responsobility to choose the "best" and implement it. Feel free to.

I am not against to have fvwm-themes package with 8 themes starting with
C, D, L, M, O and R, and fvwm-themes-extra with all other themes from cvs
and maybe not from cvs. And fvwm-themes-all package may include these two
together if needed. Or any other solution if someone else does it.

GUI for installing/uninstalling themes from tar.gz or directly from
f.t.o in user or site place is something to think about (not urgent).

Olivier, do you want to implement packaging as you see it, including rpm?
If no, we should postpone this.

Regards,
Mikhael.

Re: Is there going to be a new "stable" release of fvwm-themes?

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

Olivier Chapuis wrote:
> =

> Le Dimanche 20 Mai 2001 18:53, vous avez =E9crit :
> > On 21 May 2001 01:37:33 +0930, Alex Wallis wrote:
> > > With the imminent release of fvwm 2.4, and the recent inclusion of =
new
> > > features in fvwm-themes, I was wondering if there would also be a n=
ew
> > > stable release of fvwm-themes?
> >
> > I hope there will be fvwm-themes-0.5.0 after fvwm-2.4.0.

Perhaps even a 0.6.0 and 0.7.0 as development gets more advanced.

> > I don't call it 1.0.0 because it contains some untested features and =
new
> > components, but mainly because the goal of 1.0.0 is to make the theme=

> > switching faster, it is not very fast now. This is not final though.
> >
> > I am working on fvwm and fvwm-themes a lot now, but I am alone.
> > Olivier, is FvwmNetHints more important? :)
> >
> =

> No and that is not really the problem. The point is that I work a lot o=
n
> fvwm-themes, then a lot on wm-icons and after that I start this fvwm-ew=
mh
> project which gave to me a lot of fun as on the other hand I lose some
> motivation for fvwm-themes. But, I really think that I will come back s=
oon
> on fvwm-themes with a lot of motivation.
> =

> Another point is that I would like that fvwm-ewmh will be beta as soon
> as possible as on the other hand fvwm-themes is really a good beta
> (and for my *own* use almost perfect). Moreover, I do not know if
> fvwm-ewmh will be a success or not, but I hope that this project
> will give to FVWM and FVWM Themes more users and maybe some
> new developers ...
> =

> About the release scheduling I think we have to release 0.4.3 or 0.5.0
> (the number is not really important for me) with or soon after fvwm-2.4=
=2E0.
> But Mikhael what we have to do now for this release?
> =

> > > If so, I would suggest that this would be an ideal time to separate=
 some
> > > themes from the project itself. That is of course, if that decision=
 has
> > > also been made.
> >
> > Any concrete suggestions? There are 14 themes in cvs:
> >
> > afterstep
> > awol
> > blackbox
> > brushedmetal
> > cde
> > default
> > luthien
> > migo
> > multichoice
> > nanogui
> > olicha
> > osx
> > redmond98
> > spruce
> >
> > And there are 2 more started themes on my disk.
> >

Not too mention some themes I and others have started.

I'd not be opposed to all but the default theme be separated, but in
order to be usuable a themes package requires some alternatives. However
I would still strongly suggest no more than 4 to 6 themes in all.

Of the themes currently in the project, IMHO the following themes
provide an adequate base set.

CDE, Default, Luthien, Migo, Olicha, and perhaps also Redmond98.

To better represent the true capabilities of fvwm-themes, multichoice
could possibly replace CDE.

> =

> I repeat my suggestion here:
> 1 - I think that all fvwm-themes themes should be in the same CVS tree.=


Without limits? The number of themes could quickly become cumbersome.
Also each theme will increase the size of the project until it becomes
substantial. It will only take a few themes with sounds included to
swell the size of fvwm-themes to several megabytes!

> 2 - But when we  type make dist, this should build the main distributio=
n
> which say contains the 14 current themes (or less) plus for each theme
> "foo" which is not in the main dist  an additional tarball
>       fvwm-themes-foo-$VERSION.tar.gz
> which can be installed/uninstalled with fvwm-themes-config.

Perhaps some themes will not change much? Should these themes be
re-packed for every release? The themes themselves will also require
versions too as they may conceivably change a lot over time.
Is it possible, or even desirable, to perhaps have with each release

fvwm-themes-all-$VERSION.tar.gz
fvwm-themes-basic-$VERSION.tar.gz

along with tarballs of the other themes? Then users have the maximum
possible choice. One package to download for the entire project, or
several downloads according to their preferences.

There is even another alternative here not previously considered.
It will however, require some careful perl wizardry to achieve.
Users could be encouraged to participate in cvs development by providing
them with a script to update their installations according to simple
parameters set in a ".fvwm-themes-cvsrc" file. Just put in this file the
themes they wish to keep updated. =


> 3 - Maybe it will be good that some themes in the main dist can be
> uninstalled too.

I think an uninstall option is just as important as install. Say, if
someone tries a theme they dislike intensely. The only exception of
course should be the default theme.

> 4 - Moreover, some themes can be "unofficial" (and downlodable
> from fvwm.themes.org) before its inclusion (or not) in the CVS tree.

I think all the themes, including the themes in the main distribution,
should be always available for individual download.

> =

> Any way I think that this problem should be handled after we release
> the fvwm-themes version for fvwm-2.4.0

I still think this should be decided now. After fvwm2.4's release we can
expect a lot of users to be upgrading/installing the "new stable
release" of fvwm. It follows that a lot of these will also checkout
fvwm-themes.
Changing to another format later may cause more problems and confusion
for users than necessary. =


Also, if major distributions like debian start packaging fvwm-themes,
they may not want to make too many changes to their own packaging to
accomodate our future plans.


Alex

Re: Is there going to be a new "stable" release of fvwm-themes?

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

Le Dimanche 20 Mai 2001 18:53, vous avez écrit :
> On 21 May 2001 01:37:33 +0930, Alex Wallis wrote:
> > With the imminent release of fvwm 2.4, and the recent inclusion of new
> > features in fvwm-themes, I was wondering if there would also be a new
> > stable release of fvwm-themes?
>
> I hope there will be fvwm-themes-0.5.0 after fvwm-2.4.0.
> I don't call it 1.0.0 because it contains some untested features and new
> components, but mainly because the goal of 1.0.0 is to make the theme
> switching faster, it is not very fast now. This is not final though.
>
> I am working on fvwm and fvwm-themes a lot now, but I am alone.
> Olivier, is FvwmNetHints more important? :)
>

No and that is not really the problem. The point is that I work a lot on
fvwm-themes, then a lot on wm-icons and after that I start this fvwm-ewmh
project which gave to me a lot of fun as on the other hand I lose some
motivation for fvwm-themes. But, I really think that I will come back soon
on fvwm-themes with a lot of motivation.

Another point is that I would like that fvwm-ewmh will be beta as soon
as possible as on the other hand fvwm-themes is really a good beta
(and for my *own* use almost perfect). Moreover, I do not know if
fvwm-ewmh will be a success or not, but I hope that this project
will give to FVWM and FVWM Themes more users and maybe some
new developers ...

About the release scheduling I think we have to release 0.4.3 or 0.5.0
(the number is not really important for me) with or soon after fvwm-2.4.0.
But Mikhael what we have to do now for this release?

> > If so, I would suggest that this would be an ideal time to separate some
> > themes from the project itself. That is of course, if that decision has
> > also been made.
>
> Any concrete suggestions? There are 14 themes in cvs:
>
> afterstep
> awol
> blackbox
> brushedmetal
> cde
> default
> luthien
> migo
> multichoice
> nanogui
> olicha
> osx
> redmond98
> spruce
>
> And there are 2 more started themes on my disk.
>

I repeat my suggestion here:
1 - I think that all fvwm-themes themes should be in the same CVS tree.
2 - But when we  type make dist, this should build the main distribution
which say contains the 14 current themes (or less) plus for each theme
"foo" which is not in the main dist  an additional tarball
      fvwm-themes-foo-$VERSION.tar.gz
which can be installed/uninstalled with fvwm-themes-config.
3 - Maybe it will be good that some themes in the main dist can be
uninstalled too.
4 - Moreover, some themes can be "unofficial" (and downlodable
from fvwm.themes.org) before its inclusion (or not) in the CVS tree.

Any way I think that this problem should be handled after we release
the fvwm-themes version for fvwm-2.4.0

Regards, Olivier

Re: Is there going to be a new "stable" release of fvwm-themes?

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

On 21 May 2001 01:37:33 +0930, Alex Wallis wrote:
> 
> With the imminent release of fvwm 2.4, and the recent inclusion of new
> features in fvwm-themes, I was wondering if there would also be a new
> stable release of fvwm-themes? 

I hope there will be fvwm-themes-0.5.0 after fvwm-2.4.0.
I don't call it 1.0.0 because it contains some untested features and new
components, but mainly because the goal of 1.0.0 is to make the theme
switching faster, it is not very fast now. This is not final though.

I am working on fvwm and fvwm-themes a lot now, but I am alone.
Olivier, is FvwmNetHints more important? :)

> If so, I would suggest that this would be an ideal time to separate some
> themes from the project itself. That is of course, if that decision has
> also been made.

Any concrete suggestions? There are 14 themes in cvs:

afterstep
awol
blackbox
brushedmetal
cde
default
luthien
migo
multichoice
nanogui
olicha
osx
redmond98
spruce

And there are 2 more started themes on my disk.

Regards,
Mikhael.

Is there going to be a new "stable" release of fvwm-themes?

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

With the imminent release of fvwm 2.4, and the recent inclusion of new
features in fvwm-themes, I was wondering if there would also be a new
stable release of fvwm-themes? 

If so, I would suggest that this would be an ideal time to separate some
themes from the project itself. That is of course, if that decision has
also been made.

Alex

fvwm.themes.org

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

Alex, are you happy with fvwm.themes.org? :) Was there a reason to open it
without making a nice web design and without updating it for months? :)

I know the problem is an absence of enthusiasts. Ok, here are suggestions.

I think that fvwm.themes.org should look like all other *.themes.org
sites, i.e. it should have sections for themes, screenshots, users, news.

Alex, I don't see any reason to duplicate fvwm-themes.sf.net. Links to it
should be enough. If you want to update pages on fvwm-themes.sf.net,
you have all permissions to do this, just commit in fvwm-themes-web cvs.

What is needed for fvwm.themes.org to have the common engines?
I am sure, there are some people wanting to submit screenshots.
I am almost ready to submit a theme not included in cvs. :)

Regards,
Mikhael.

Re: fvwm-themes: patches to use fontsets instead of single fonts

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

On 02 May 2001 14:51:17 +0200, Mike Fabian wrote:
> 
> Mikhael Goikhman <mi...@ho...> writes:
> 
> > On 26 Apr 2001 18:43:46 +0200, Mike Fabian wrote:
> > > 
> > > Attached are patches for fvwm-themes to use fontsets instead of single
> > > fonts.
> > 
> > Thank you for contributing!
> > 
> > Which X Servers on different unices support fontsets?
> 
> I thought all of them do. Isn't the fontset mechanism something which
> has always been available in X11? Am I mistaken?

I don't know. To be honest, I first hear about fontsets in your message.
On my RedHad system with XFree86{,-xfs,-libs,*fonts...}-4.0.3-5 rpms
the first command:

  Style * Font "-*-lucida-bold-r-*-*-12-*,-*-*-medium-r-*--14-*,*"
  Style * Font "-*-lucida-bold-r-*-*-12-*"

produces this error:

  [GetFontOrFixed]: WARNING -- can't get font -*-lucida-bold-r-*-*-12-*,-*-*-medium-r-*--14-*,*, trying 'fixed'

> > I thought about having component "fonts" for similar and other purposes.
> > So if fontsets is not a portable option, support for Japanese (or Korean,
> > Chinese, Russian whatever) would be possible by adding one file.

Ok, I implemented an initial solution for a new "fonts" component.
(I still didn't decide what to do about module fonts, there are many.)
This will be available in the next fvwm-themes, probably 0.5.0.

If you want this to work out of the box for Japanese (although I don't
understand this, does not fontsets only work on systems with only Japanese
fonts installed and on other systems latin fonts are used not Japanese?),
you may patch a single file themes/default/fonts to use fontsets on SuSE,
if its X Server (or xfs) supports fontsets.

But, I think, there is a better solution to ensure that Japanese fonts are
used even if latin fonts are the first in the fontpath. I included a
component fonts@multichoice in several variants (several languages),
so a user may choose "Japanese (jisx0208)" or "Cyrillic (koi8-r)".

> > If Japanese is left-to-right (I know, it is up-to-down), you may try to
> > translate some of the locale/* to Japanese.
> 
> I'll try to do that if possible.
> 
> I'm doing the Japanese translations of the SuSE installation program
> YaST2, but as Japanese is not my native language I send my
> translations to a Japanese friend to correct my errors.

Well, if your friend is not fluent in FVWM, he will not be able to
translate some of the technical texts. :) I myself had difficulties to
translate to my native language, I needed to invent some new terminology.
But non technical texts (Yes/No) should not be hard to translate.

Regards,
Mikhael.

Re: fvwm-themes: patches to use fontsets instead of single fonts

[Mike F. <mf...@su...>]

The translations are not yet checked by a native speaker.  The
translation of FvwmScript-ColorSelector.msg should nevertheles be OK,
there is not much room left for errors, these are only a few simple
words.  But The translation of FvwmScript-ColorSelector.html is
certainly full of errors. It is probably understandable though and
certainly good enough for testing purposes.

Patch for FvwmScript-ColorSelector to use fontsets:

Re: fvwm-themes: patches to use fontsets instead of single fonts

[Mike F. <mf...@su...>]

Mikhael Goikhman <mi...@ho...> writes:

> On 26 Apr 2001 18:43:46 +0200, Mike Fabian wrote:
> > 
> > Attached are patches for fvwm-themes to use fontsets instead of single
> > fonts.
> 
> Thank you for contributing!
> 
> Which X Servers on different unices support fontsets?

I thought all of them do. Isn't the fontset mechanism something which
has always been available in X11? Am I mistaken?

> I thought about having component "fonts" for similar and other purposes.
> So if fontsets is not a portable option, support for Japanese (or Korean,
> Chinese, Russian whatever) would be possible by adding one file.
> 
> > For European languages, nothing should be changed by these patches.
> > 
> > Here is a screenshot showing Japanese in the window titles, the icon
> > manager and the window list:
> > 
> > http://www.suse.de/~mfabian/fvwm-themes-japanese.png
> 
> Very nice. We will support Japanese (with your help) in one of the
> upcoming versions once we decide with Olivier which method to use.
> 
> If Japanese is left-to-right (I know, it is up-to-down), you may try to
> translate some of the locale/* to Japanese.

I'll try to do that if possible.

I'm doing the Japanese translations of the SuSE installation program
YaST2, but as Japanese is not my native language I send my
translations to a Japanese friend to correct my errors. This is a very
slow and tedious procedure. I'll try to do it for fvwm-themes as well,
but it will probably take a long time.

-- 
Mike Fabian   <mf...@su...>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。

Re: [FVWM-Themes] Theme names and packaging

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

Le Samedi 28 Avril 2001 02:16, vous avez écrit :
> I would like to know an opinion of everyone here about these 2 questions
> regarding fvwm-themes.
>
> 1) Which names to use for themes, lower-cased as it is now or mix-cased?
> I am very compfortable with lower-cased ones (cde, afterstep), just
> like with lower-cased components (background, colors) and I think we
> should use this as theme id for consistency, but it is not very hard to
> display mix-cased names (CDE, AfterStep).
>

I am agree with Thomas and Alex: lower case for theme name as id,
Mixed Case for theme name as displayed for the user (E,g., theme management
menu), and lower case for theme components.

> 2) Currently we have one package for the core and all themes. Do you think
> it makes sence to divide it to several ones. If yes, which packages to
> have, fvwm-themes-base, fvwm-themes-extra? Or maybe only the base package,
> and distribute all other themes using .tar.gz from themes.org?
>
> In other words, which method do you prefer, to install one fvwm-themes
> tarball (or rpm), which is getting bigger (since it includes more themes),
> or you are not interesting in more themes to be included and prefer to
> find other themes on internet yourself?
>
> The current packaging method seems to me easier for developers and users,
> but I am not sure about users, this is why I am asking.
>

At present time the fvwm-themes tarbal is 992159 bytes and take
3,859,116 bytes of disk space (thanks to rpm).
My opinion is that we should not add more themes to the main distribution
and that it will be maybe a good thing to have the possibility to "uninstall"
after installation any theme but the default theme. On the other hand, for
developing propose, I think that all fvwm-themes themes should be
in the same CVS tree. Ideally, when we type make dist, this should
build the main distribution plus for each theme "foo" which is not in
the main dist  an additional tar ball ft-foo-$VERSION.tar.gz which
can be installed/uninstalled with fvwm-themes-config.
Mikhael do you think this is technically possible?

Olivier