fvwm-themes-devel — Developing FVWM Themes

Re: Some quirky things with xinerama.

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

On Thu, Sep 20, 2001 at 10:34:11PM +0930, Alex Wallis wrote:
> 
> I thought I'd bring this thread into the appropriate forum.
> 
> Olivier Chapuis wrote:
> > 
> > >
> > 
> > fvwm-themes is not Xinerama compliant. This will be on the TODO
> > list. Adding a line of the form:
> > 

I think that now fvwm-themes (cvs) is Xinerama compliant.
You should read question 3.1.3 of the FAQ. WindowList is
still buggy but I hope that this will be fixed in fvwm
2.4.3 (if not we will found a workaround).

Alex can you make some tests (specialy blackbox, cde and
osx modules with primary screen 0 and 1).

Olivier

: : : Festival de Marne 2001 : : :

[info <in...@wa...>]

Venez jeter un coup d'oeil sur le programme du 15e Festival de marne...
Des centaines de concerts Rock, rap, Reggae...
et ce dans tout le Val-de-Marne.
(Têtes Raides, Faudel, Yann Tiersen, Arthur H...)
Les nouveautés sont en écoute....

Alors, merci d'avance pour votre visite...

http://www.festivaldemarne.org

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

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

On Thu, May 03, 2001 at 01:59:40AM +0200, Mike Fabian wrote:

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

I've incorporate FvwmScript-ColorSelector.msg in fvwm-themes (cvs,
not yet released version 0.5.1). I've used the font:
	-misc-fixed-*-*-*-*-14-*-*-*-*-*-jisx0208.1983-*
and I've got a similar FvwmScript-ColorSelector as your screenshot.
I've not incorporated FvwmScript-ColorSelector.html because it seems
that the encoding is different from FvwmScript-ColorSelector.msg
and I do not succeed to found the good font. Any tips? 

More ja *.msg and *.html welcome :o)

Regards, Olivier

Re: Some quirky things with xinerama.

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

Olivier Chapuis wrote:
> 
> On Thu, Sep 20, 2001 at 10:34:11PM +0930, Alex Wallis wrote:
> >
> > I thought I'd bring this thread into the appropriate forum.
> >
> > Olivier Chapuis wrote:
> > >
> > > >
> > >
> > > fvwm-themes is not Xinerama compliant. This will be on the TODO
> > > list. Adding a line of the form:
> > >
> > > PipeRead 'echo "*FvwmButtons-Panel: Geometry 860x77+"`expr "(" $[vp.width] - 860 ")" / 2`"-0@0"'
> > >            ^^
> > > to your modules-extra should fix the cde buttons geometry.
> > > BTW, maybe it will be good to have some Xinerama support in
> > > "COMMAND EXPANSION" (e.g., new variables) and FvwmM4.
> > > About the menus popup by the cde button the problems come
> > > from cfg lines of the form:
> >
> > Is an xinerama option and/or variants possible to be added to
> > themes/multichoice?
> > I may do some investigating.
> >
> 
> I think that we may add an Xinerama option under settings. Then, we
> should check all the geometries in fvwm-themes and try to do
> so that the geometries work with any Xinerama settings (in particular
> with a single screen with Xinerama off). If this not possible we
> can try to add some functions in the settings/xinerama/{enabled,disabled,...}
> files that do the job.
> Then, we may add some options in some modules themes (as get two
> TaskBar/Pager, one on each screen)
> My problem is that I have no xinerama hardware at all :o(

I'd come to much the same conclusions as you. I think adding a new
FuncThemesXineramaOn might allow some extra lines like your Piperead
suggestion. Perhaps some xinerama geometry could also be added.

> 
> > >
> > > *FvwmButtons-Panel: (3x2+33+0, Frame 1, Icon module/large/panel-arrow.xpm, \
> > > Padding 1 1, Colorset 11, \
> > > Action 'Menu MenuFvwmSystem rectangle $widthx$height+$left+$top o+50 -100m')
> > >
> > > *Maybe* this is a FvwmButtons/fvwm2/Xinerama bugs or miss feature.
> > > I do not know.
> > >
> >
> > Actually Dominik's suggestion "XineramaPrimaryScreen 1" fixed the cde
> 
> I do not think that it will fix the problem for any Xinerama
> configuration.
> 
> > button bar menus, but not the windowlist.
> >
> >
> 
> The WindowList problem seems to be a fvwm2 problem. Do you
> mean that when you right click on screen0 the menu appear
> on screen1 as this does not happen with left and central
> click. 

Yes!

> Do you use the switch button 2<->3 fvwm-themes
> bindings option?

Yes! again....

Plus the reset to default doesn't stop all modules first time and a
couple of other irritations.


Alex.

PS. I'll try making a list....

Re: Some quirky things with xinerama.

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

On Thu, Sep 20, 2001 at 10:34:11PM +0930, Alex Wallis wrote:
> 
> I thought I'd bring this thread into the appropriate forum.
> 
> Olivier Chapuis wrote:
> > 
> > >
> > 
> > fvwm-themes is not Xinerama compliant. This will be on the TODO
> > list. Adding a line of the form:
> > 
> > PipeRead 'echo "*FvwmButtons-Panel: Geometry 860x77+"`expr "(" $[vp.width] - 860 ")" / 2`"-0@0"'
> >            ^^
> > to your modules-extra should fix the cde buttons geometry.
> > BTW, maybe it will be good to have some Xinerama support in
> > "COMMAND EXPANSION" (e.g., new variables) and FvwmM4.
> > About the menus popup by the cde button the problems come
> > from cfg lines of the form:
> 
> Is an xinerama option and/or variants possible to be added to
> themes/multichoice?
> I may do some investigating.
>

I think that we may add an Xinerama option under settings. Then, we
should check all the geometries in fvwm-themes and try to do
so that the geometries work with any Xinerama settings (in particular
with a single screen with Xinerama off). If this not possible we
can try to add some functions in the settings/xinerama/{enabled,disabled,...}
files that do the job.
Then, we may add some options in some modules themes (as get two
TaskBar/Pager, one on each screen)
My problem is that I have no xinerama hardware at all :o(

> > 
> > *FvwmButtons-Panel: (3x2+33+0, Frame 1, Icon module/large/panel-arrow.xpm, \
> > Padding 1 1, Colorset 11, \
> > Action 'Menu MenuFvwmSystem rectangle $widthx$height+$left+$top o+50 -100m')
> > 
> > *Maybe* this is a FvwmButtons/fvwm2/Xinerama bugs or miss feature.
> > I do not know.
> > 
> 
> Actually Dominik's suggestion "XineramaPrimaryScreen 1" fixed the cde

I do not think that it will fix the problem for any Xinerama
configuration.

> button bar menus, but not the windowlist.
> 
>

The WindowList problem seems to be a fvwm2 problem. Do you
mean that when you right click on screen0 the menu appear
on screen1 as this does not happen with left and central
click. Do you use the switch button 2<->3 fvwm-themes
bindings option?

Olivier

Re: Some quirky things with xinerama.

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

I thought I'd bring this thread into the appropriate forum.

Olivier Chapuis wrote:
> 
> >
> 
> fvwm-themes is not Xinerama compliant. This will be on the TODO
> list. Adding a line of the form:
> 
> PipeRead 'echo "*FvwmButtons-Panel: Geometry 860x77+"`expr "(" $[vp.width] - 860 ")" / 2`"-0@0"'
>            ^^
> to your modules-extra should fix the cde buttons geometry.
> BTW, maybe it will be good to have some Xinerama support in
> "COMMAND EXPANSION" (e.g., new variables) and FvwmM4.
> About the menus popup by the cde button the problems come
> from cfg lines of the form:

Is an xinerama option and/or variants possible to be added to
themes/multichoice?
I may do some investigating.

> 
> *FvwmButtons-Panel: (3x2+33+0, Frame 1, Icon module/large/panel-arrow.xpm, \
> Padding 1 1, Colorset 11, \
> Action 'Menu MenuFvwmSystem rectangle $widthx$height+$left+$top o+50 -100m')
> 
> *Maybe* this is a FvwmButtons/fvwm2/Xinerama bugs or miss feature.
> I do not know.
> 
> Olivier

Actually Dominik's suggestion "XineramaPrimaryScreen 1" fixed the cde
button bar menus, but not the windowlist.


Alex

fvwm-themes-0.5.1 release plan

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

Hello,

I will be happy if we can release fvwm-themes-0.5.1 in
the beginning of October. Only at the beginning of October
because Mikhael is in holidays and there are a few remaining
important issues to closed before 0.5.1. If we can close it
before I will release 0.5.1 sooner. 

Here these few issues (I forget some perhaps)

1. The theme switching logic has changed in the current cvs.
So, any report on problems at theme switching is really
welcome.

2. I think that it will be good that the "experimental
reloading" be the default (vs full reloading). So, I
suggest cvs users to use it now (TM -> refresh and reload
-> use experimental reloading) and report any problems
(there are a few problems for sure). Switching with this
method is really faster.

3. Technical issue with "experimental reloading":

 a. At theme switching, if the modules theme does not change
 only the modules which contain (swallowed) applications
 are restarted. This is needed because FvwmTheme cannot
 ask these apps to change its colors. Two functions are
 used FuncFvwm{Load,Reload}ColorsModule. The problem is
 that restarting of these modules happen to often (e.g.,
 this happen if buttons or windowlook is changed as the
 module themes should be reloaded in this case).
 We can hardcode something in ft-config to do so that
 these modules are restarted only when really needed
 (the colors change and the modules themes does not
 need a full restart). I may do the change in a few days
 but we may decide to revert this change as hardcoding
 is in general not a good idea.
 Note: Of course this type of problems arise with a lot
 of others components (as we do not choose to use a fine
 CCDS), but in the case of the modules themes this is
 visually disturbing.

 b. Good names for the *depends/affects-* dependence rule
 must be choosen (see my last message under CCDS Again).


4. From the ChangeLog:

 "Override colors title decor (not the border decor) with
  brushedmetal colors-decor.
  Note: this is experimental, but *I* think this is a good idea. We
  may do the same thing with nanogui and mech"

That is: do we have to override the title colors with these special
buttons components which use buttons to build the non buttons part
of the Title decor?

Regards, Olivier
 
 

Re: CCDS Again

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

On Mon, Aug 20, 2001 at 09:15:12PM +0000, Mikhael Goikhman wrote:
> I can't reply fully now, because I didn't have yet time to take a look at
> all recent changes.
> 

It is just the begining of "a lot of change" ...

> I think that fvwm-themes-config may be rewritten one day to be more
> modular, components may be real objects with methods and data.
>

Yes, I think that a programs always have to be at least rewritten one
time so that we be very happy with it. However, I found that 
fvwm-themes-config is really not so bad :o)
  
> But currently I don't have a time for this, so you should decide yourself.
> I can only suggest general things for any changes. Try to make it clear,
> for example several booleans may be preferable over one state integer.

Maybe, however I will use the 'used' integer from now and when the
stuff will be finished (and more clear in my head) we may change
to sevral booleans.

> If there is repeating code it may mean problems with design.
>

For me repeating code is not really a problem (especially during
development). Some times compacting repeating code leads to very
complicate procedure. I prefere to understand the code ...

> I think "prereload" may be renamed simply to "unreload".

Ok

> The component cfg dependence names may be:
> 
>   affects-load+=   component that should be unloaded and loaded again
>   affects-reload+= component that should be unreloaded and reloaded again
>

Yes "(strongly)depends" is not very good (and we also need a weaklydepends
and maybe one day a stronglyweaklydepends). Moreover the relation should
not be symetric. What about:

[component]
file=A

   affects-load-if-loaded+=B
     component A should be (un)loaded again if component B is (un)loaded again
     (what I call stronglyweaklydepends)
   affects-reload-if-loaded+=B   (*)
     component A should be (un)reloaded if component B is (un)loaded again
     (what I called weaklydepends)
   affects-reload-if-reloaded+=B
     component A should be (un)reloaded if component B is (un)reloaded
   affects-reload+=B   (*)
     short cut for  affects-reload-if-loaded+=B && affects-reload-if-reloaded+=B
     (what I called depends)
   affects-reload-load+=B   (*)
     short cut for affects-reload-if-reloaded+=B && affects-load-if-loaded+=B
     (what I call stronglydepends)

At present time it seems that only those with an (*) are needed.
Maybe these 3 will be ok?
(I may commit change with "depends"; it will be easy to replace these
depends with some "affects-*).

> I think this is good to have, but I will go to vacation in September,
> so I can't help much in this period.
>

This is not a problem I (will) do all this. But of course testing and
remarks are welcome.

> Regards,
> Mikhael.
> 
> -- 
> FVWM-Themes-devel mailing list, fvw...@li...
> http://lists.sourceforge.net/lists/listinfo/fvwm-themes-devel
> 

Re: CCDS Again

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

I can't reply fully now, because I didn't have yet time to take a look at
all recent changes.

I think that fvwm-themes-config may be rewritten one day to be more
modular, components may be real objects with methods and data.

But currently I don't have a time for this, so you should decide yourself.
I can only suggest general things for any changes. Try to make it clear,
for example several booleans may be preferable over one state integer.
If there is repeating code it may mean problems with design.

I think "prereload" may be renamed simply to "unreload".
The component cfg dependence names may be:

  affects-load+=   component that should be unloaded and loaded again
  affects-reload+= component that should be unreloaded and reloaded again

I think this is good to have, but I will go to vacation in September,
so I can't help much in this period.

Regards,
Mikhael.

Re: [ fvwm-themes-Bugs-450720 ] more solaris install problems

[Dorothy R. <mo...@tw...>]

I got the snapshot and it installed flawlessly on my Solaris system this 
time (I had already installed xmessage).

Dorothy

> Can you please get a cvs snapshot and see which problems are not fixed:
> 
>   http://fvwm-themes.sf.net/tmp/fvwm-themes-base-0.5.1-0.20010814.tar.gz

CCDS Again

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

Hello,

Theme switching work a bit differently now:

The first point is that themes-rc-3 is always used for theme
switching. It is a necessity because we cannot predict which
"stop" function we will need to use at the next theme switching
(also the "stop" functions are put in "memory" in the _core
component to be able to drop). Moreover, themes-rc-3 allows to
do some optimization(as we do with minimal switching).

But, the main point is that a component have a "state" at theme
switching. The 'used' value is used to define the state of
a component. We have 3 state:

  1: the component is used but nothing have to be done about this
     component during theme switching.
  2: the component must be reloaded but not (re)started, the
     reload-read-command and the reload-prereload "start stop"
     function are executed.
  3: the component must be (re)started, the read-command and the
     start-stop or the load-unload "start stop" function are executed.

At the present time if !isMinimalReload() the 'used' value is at least
set to 2 (1 is never used and so all component are at least reloaded).
Moreover, if there are no reload-read-command or reload-prereload
"start stop" function the 2 and 3 state are equivalent. I've used the
reload-read-command and reload-prereload only for ewmh and
modules@olicha. You may want to try modules@olicha: only the "applet"
FvwmButtons is restarted (because of a Buttons core dump or because it
contains swallowed app) and I found a colors switching better (the
appmanager and the Button Pager are not restarted and we see FvwmThemes
in work!)

The first question is do we have to continue this reload work?
I really think that the answer is yes.

The second question is how to improve the dependency ft cfg rule to get
a good computation of the state.
If isMinimalReload() the computation is hard coded: all component state
are set to 1 but the "new" component have state 3 then
setComponentsToReload set the used value of certain components to 2
accordingly to some hardcoded dependency). I would like to unhard code
it.
Moreover, in some case if a component have state 3, then an other one
must also have state 3 (not only 2). This is already implemented
for *-extra component by using the "complement" ft cfg rule.
It is no easy to use the current dependency rule to do so. I suggest
to use new ft cfg rule. Something like:

  [component]
  file=A
  ...
 
  depends+=B
	if B has state 3 or 2, the state of A should be set to 2
  stronglydepends+=B
	if B has state 3 (respectively 2), the sate of A should be set
        to 3 (respectively 2). (Implied by complement).


These rule are not fine as the rule I suggest in an old message
(subject: CCDS, date: 2000-12-29). But maybe together the reload-*
cmd we can get a faster and clean theme switching.

Any objection?

Regards, Olivier

Re: Some more problems with latest cvs

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

Mikhael Goikhman wrote:
> 
> I don't know. It works well with rpm-3.0.4-0.48 and rpm-4.x.
> Try to remove "=" in fvwm-themes-base.spec to see whether this helps.
> If this does not help upgrade rpm to rpm-3.0.4.
> 

I don't begin to uderstand why, but removing the "=" fixes it.
Incidently I have rpm-3.0.3-4 and I'm just trying to test the package
creation and installation to another machine.

Thanks for the info.

Alex

Re: Some more problems with latest cvs

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

On 17 Aug 2001 03:40:28 +0930, Alex Wallis wrote:
> 
> But I still can't get the fvwm-themes-base-0.5.1.noarch.rpm to build.
> 
> ==== Creating rpm from /tmp/fvwm-themes-base-0.5.1.tar.gz, release
> 0.20010817 ====
> 
> Building target platforms: noarch-fvwm-linux
> Building for target noarch-fvwm-linux
> line 25: Version not permitted: Provides:  fvwm-themes = 0.5.1
> make[1]: Leaving directory `/home/awol/cvs/fvwm-themes/rpm'

I don't know. It works well with rpm-3.0.4-0.48 and rpm-4.x.
Try to remove "=" in fvwm-themes-base.spec to see whether this helps.
If this does not help upgrade rpm to rpm-3.0.4.

Regards,
Mikhael.

Some more problems with latest cvs

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

Okay the fvwm2.4.2_beta1 seems to allow fvwm.rpm's now np's.

But I still can't get the fvwm-themes-base-0.5.1.noarch.rpm to build.

==== Creating rpm from /tmp/fvwm-themes-base-0.5.1.tar.gz, release
0.20010817 ====

Building target platforms: noarch-fvwm-linux
Building for target noarch-fvwm-linux
line 25: Version not permitted: Provides:  fvwm-themes = 0.5.1
make[1]: Leaving directory `/home/awol/cvs/fvwm-themes/rpm'

Additionally I now get the following ./configure error...

checking for xmessadge... no
configure: warning: 
        xmessage is not found; you will have some problems; please
install it.
        You may find the binary at http://sunfreeware.com/ .

Which appears to be a typo in configure.in.

I found the changes to FuncFvwmStopAllHooks and FuncFvwmLoadAllHooks a
little confusing but no doubt I'll sort it out eventually.


Alex

Re: fvwm-dorothy setup

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

On Tue, Aug 14, 2001 at 11:00:51AM +0000, Mikhael Goikhman wrote:
> If you didn't tried yet the setup of Dorothy, you should do this now. Get
> the tarball from http://fvwm-themes.sourceforge.net/data/samples/dorothyr/
> unpack it to the home directory and execute in FvwmConsole:
> 
>   Restart fvwm2 -f ~/fvwm-dorothy/rc.fvwm
> 
> Then decors may be changed using the mouse button 3.
> To return to your original config: "Restart fvwm-themes-start" or similar.
> 
> What do you all think? How many themes should we add, all?
> I would start with several monolithic ones to learn more about problems.
> Who wants to work on which theme, so we don't work on the same thing? :)
>

I've tried it. I like the decors but I just found the title height to
big (maybe because I've a 800x600 screen).
I've no time to work on the themes because I am, at the present time,
more concerned about fvwm-themes general design (e.g., fvwm-themes-config).
But what about incorporate fvwm-dorothy in one theme (Dorothy) with
option for each needed component?
 
Regards, Olivier

RPM build problems

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

When trying to do make rpm-dist3 i get the following error...

==== Creating rpm from /tmp/fvwm-themes-base-0.5.1.tar.gz, release
0.20010815 ====

Building target platforms: noarch-fvwm-linux
Building for target noarch-fvwm-linux
line 25: Version not permitted: Provides:  fvwm-themes = 0.5.1
make[1]: Leaving directory `/home/awol/cvs/fvwm-themes/rpm'

Which explains why the fvwm-themes-base-0.5.1.noarch.rpm never gets
built on my system.

I was wondering if this was related to the fvwm version conflict of...

==== Creating rpm from /tmp/fvwm-2.4.1-beta1.tar.gz, release 0.20010815
====

line 15: Illegal char '-' in version: Version:   2.4.1-beta1
make[1]: Leaving directory `/home/awol/cvs/fvwm/rpm'

And whether or not would changing it to fvwm-2.4.1_beta1 might not only
be possible, but also solve both problems?

Alex

Re: [ fvwm-themes-Bugs-450720 ] more solaris install problems

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

On 14 Aug 2001 00:05:28 -0700, no...@so... wrote:
> 
> Bugs item #450720, was opened at 2001-08-14 00:05
> 
> I encountered these further problems when installing on Solaris:
> 
> $(INSTALL) didn't get set right in the Makefiles.  I got things like this:
> INSTALL = ../'/usr/local/bin/install -c'
> That's wrong on several counts:
> 1.  ..//usr/local/bin doesn't exist
> 2.  The single quotes cause the shell to think the whole string is a
>     command, so it says "install -c: command not found"
> 3.  /usr/local/bin/install doesn't have a -c flag.  On Suns you have to
>     use /usr/ucb/install.  Most configure scripts say "looking for a
>     ucb-compatible install" and handle it.

Can you give an example of such other programs?
I can only see support for BSD-compatible install in my autoconf-2.13.
You can search configure script for the word "ucb" to read why
/usr/ucb/install is avoided by autoconf. The same in autoconf-2.50.
I don't see how such INSTALL string is possible, but this is autoconf bug.
Anyway, I added small check for the strange "../'/usr/..." case you wrote.

> I don't have anything called gtar.  I have gnu's tar, but I called it
> gnutar when I installed it.  Many people install it as
> /usr/local/bin/tar.  In any case I don't think it's safe to assume a
> person has gtar.

We don't assume this, it is automake that sets TAR to gtar by default.
Ok, I added gtar/gnutar/tar detection.

It seems that you should have exactly the same problems with $INSTALL and
$TAR (actually $TAR is only used for developers) in fvwm itself.
To solve these problems one should execute:

  env TAR=gnutar INSTALL="/usr/ucb/install -c" ./configure

> Anyway make install didn't throw an error and quit when it couldn't find
> gtar, so I didn't know right away that I was missing everything in
> /usr/local/share/fvwm.

I tried to fix this problem too.

> Solaris doesn't ship with xmessage.  That's easily remedied, but it's
> another faulty assumption.

This is bad, we use xmessage for different purposes. What Solaris has?

> But I did finally get it installed.  Sorry to be such a nit-picker.

Thank you. Please be a nit-picker, so we fix more bugs. :)

Can you please get a cvs snapshot and see which problems are not fixed:

  http://fvwm-themes.sf.net/tmp/fvwm-themes-base-0.5.1-0.20010814.tar.gz

Regards,
Mikhael.

Re: [ fvwm-themes-Bugs-450703 ] configure fails on solaris

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

On 13 Aug 2001 22:39:19 -0700, no...@so... wrote:
> 
> Bugs item #450703, was opened at 2001-08-13 22:39
> 
> the /bin/sh that comes with Solaris doesn't like this line in "configure":
> ALL_THEMES=`ls -d ./themes/*/ | grep -v CVS/ | cut -d/ -f3`
> If you use "ls -d ./themes/*" leaving off the final "/" it works.
> 
> also the awk that comes with solaris doesn't like the command on line
> 2142,   awk -v l1="${list1}" -v l2="${list2} ...
> nawk will execute it though.  nawk is supplied with my Solaris  8,
> but I don't know which Solaris version it first appeared in. 

Seems that fvwm-themes-0.5.0 is broken on Solaris again...
I replaced the glob and added gawk/nawk/mawk/awk detection in cvs.

Regards,
Mikhael.

Re: fvwm-dorothy setup

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

If you didn't tried yet the setup of Dorothy, you should do this now. Get
the tarball from http://fvwm-themes.sourceforge.net/data/samples/dorothyr/
unpack it to the home directory and execute in FvwmConsole:

  Restart fvwm2 -f ~/fvwm-dorothy/rc.fvwm

Then decors may be changed using the mouse button 3.
To return to your original config: "Restart fvwm-themes-start" or similar.

On 13 Aug 2001 21:24:38 -0700, Dorothy Robinson wrote:
> 
> Thanks for the fixes!  You're right, I didn't like the glitches at all.
> 
> > Can you please confirm that this is your original work and you allow
> > us to use it for fvwm-themes project? I would be very happy.
> 
> At worst, bits of the artwork are lifted from clip-art sites.  The 
> exception is the "starry" theme, in which the titlebar is made from a
> screen-grab of the "Dreamworks" E-theme.  There's a comment to that
> effect in the decor file, and anyway the E people borrow from each
> other's themes all the time.  You're certainly welcome to use the stuff
> for fvwm-themes.

Fine. Borrowing bits from screenshots on the web seems like a fair use.

> I once considered making my themes conform to the fvwm-theme structure, 
> but it seemed like a lot of work so, being lazy, I didn't do it.  Would 
> they have to be remodeled much to fit?

Yes, some rearrangements should be done and colorsets used.

fvwm-themes is a bit ambitious in regard of flexibility. For example,
there are the following problems to try to solve:

  * What if a user don't have or don't like some font, is this changeable?
  * What if a user likes other order of window buttons, possible?
  * Are other buttons (like "stick" and "shade") of these sets available?
  * Is it possible to use only window buttons or only border from decors?
  .. and so on

Some of your decors may be easily divided to colors (or colors-decor),
windowlook and buttons components. But some more interesting decors are
pretty monolithic. So we probably need to add an aditional support for
monolithic decors (i.e. allow these buttons only with these colors or/and
windowlook from the same theme).

Also we didn't yet used a pixmap border, it probably belongs to colors@.

What do you all think? How many themes should we add, all?
I would start with several monolithic ones to learn more about problems.
Who wants to work on which theme, so we don't work on the same thing? :)

Regards,
Mikhael.

[ fvwm-themes-Bugs-450720 ] more solaris install problems

[<no...@so...>]

Bugs item #450720, was opened at 2001-08-14 00:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=101738&aid=450720&group_id=1738

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dorothy Robinson (dorothyr)
Assigned to: Nobody/Anonymous (nobody)
Summary: more solaris install problems

Initial Comment:
I encountered these further problems when installing on
Solaris:

$(INSTALL) didn't get set right in the Makefiles.  I
got things like this:
INSTALL = ../'/usr/local/bin/install -c'
That's wrong on several counts:
1.  ..//usr/local/bin doesn't exist
2.  The single quotes cause the shell to think the
whole string is a command,
    so it says "install -c: command not found"
3.  /usr/local/bin/install doesn't have a -c flag.  On
Suns you have to use
   /usr/ucb/install.  Most configure scripts say
"looking for a ucb-compatible
  install" and handle it.

I don't have anything called gtar.  I have gnu's tar,
but I called it gnutar
  when I installed it.  Many people install it as
/usr/local/bin/tar.  In any case I   
 don't think it's safe to assume a person has gtar. 
Anyway make install
didn't throw an error and quit when it couldn't find
gtar, so I didn't know right away that I was missing
everything in /usr/local/share/fvwm.

Solaris doesn't ship with xmessage.  That's easily
remedied, but it's another
faulty assumption.


But I did finally get it installed.  Sorry to be such a
nit-picker.  And all
because you asked if you could use my themes and got me
interested :-)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=101738&aid=450720&group_id=1738

[ fvwm-themes-Bugs-450703 ] configure fails on solaris

[<no...@so...>]

Bugs item #450703, was opened at 2001-08-13 22:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=101738&aid=450703&group_id=1738

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dorothy Robinson (dorothyr)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure fails on solaris

Initial Comment:
the /bin/sh that comes with Solaris doesn't like this
line in "configure":
ALL_THEMES=`ls -d ./themes/*/ | grep -v CVS/ | cut -d/
-f3`
If you use "ls -d ./themes/*" leaving off the final "/"
it works.

also the awk that comes with solaris doesn't like the
command on line
2142,   awk -v l1="${list1}" -v l2="${list2} ...
nawk will execute it though.  nawk is supplied with my
Solaris  8,
but I don't know which Solaris version it first
appeared in. 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=101738&aid=450703&group_id=1738

(no subject)

[<dg...@we...>]

Hello,

Just to let you know www.webcamgo.com is open Now !
Make around Trip Live Around the World with all the Webcams.

It's fun ! http://www.webcamgo.com

Thanks and have a nice visite on www.webcamgo.com


we apologize for any email you may have inadvertently received.
Please send back this email.

Re: releasing 0.5.0

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

On 05 Aug 2001 21:32:57 +0200, Olivier Chapuis wrote:
> 
> > A start-stop stuff you wrote about in another thread may wait for 0.5.1.
> > I started to do Metal (java-like) theme, but it probably should wait too.
> 
> I've implemented the start-stop stuff. I think that it is safe and
> it fix also some "stop" problems with minimal switching. Moreover,
> I cannot add ewmh support without this new feature. So, I would
> like to add it as soon as possible. Also, I think that it will be
> good to solve the buttons@ vs colors-decor@ problems before 0.5.0.
> So, I will prefer to wait the 19th to go into feature freeze (I also
> want to add debian menu system support and maybe improve "minimal"
> switching) and release 0.5.0 after some testings.
> 
> But any way, if you want to release 0.5.0 soon go head.

Yes, I will release it this week. I will try to get a time to update
screenshots on the home page.

All things mentioned above may be a plan for 0.5.1 that you will release.

> > Now, let test that everything works before releasing 0.5.0.
> > I get "Can't load font" in ThemesCenter (12 times).
> 
> Can you give more info ($LANG, $LC_CTYPE, fvwm version,
> fvwm-config --supports-multibyte)?

Nothing is defined, the latest fvwm version without multibyte.
I get this problem with --lang en, but not with --lang fr or --lang ru.
Everything seems to work well becide of these 12 warnings.

Regards,
Mikhael.

Re: releasing 0.5.0

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

On Sat, Aug 04, 2001 at 08:35:33PM +0000, Mikhael Goikhman wrote:
> On 01 Aug 2001 06:48:55 +0200, Olivier Chapuis wrote:
> > 
> > On Sun, Jul 29, 2001 at 07:00:48AM +0000, Mikhael Goikhman wrote:
> > > On 28 Jul 2001 06:26:12 +0200, Olivier Chapuis wrote:
> > > > 
> > > > On Sun, Jul 22, 2001 at 10:44:17PM +0000, Mikhael Goikhman wrote:
> > > > > I think everything is ready for 0.5.0.
> > > > 
> > > > What is your plan now?
> > > 
> > > Since I started to add globallook component, my plan is to finish it.
> 
> Ok, I did it and it seems good to me.
> 
> You once wrote about sticking buttons@ to colors-decor@ in some themes,
> like Mech, this is not done. I thought about using a memory for restoring
> previous buttons@ when colors-decor@ is unloaded, but this is not trivial.
> 
> > > I also want to replace colors@default unless anyone objects, gray and gray
> > 
> > I've no objection for changes in the default colors
> 
> A new (much better IMHO) color scheme is implemented.
> 

Yes I found it also much better.

> > > > What I want to do is a new .cfg config option of the form
> > > > 
> > > > 	system-requires="test"
> > > > 
> > > > for component (and also maybe for individual variant).
> 
> I renamed "system-requires" to "unhide-if" and did some other renamings.
> I am not sure how good is to hide whole components and not only variants,
> but we will see.
>

But it is possible to hide only variant and I think that an empty
component can trouble the users.

> A start-stop stuff you wrote about in another thread may wait for 0.5.1.
> I started to do Metal (java-like) theme, but it probably should wait too.
> 

I've implemented the start-stop stuff. I think that it is safe and
it fix also some "stop" problems with minimal switching. Moreover,
I cannot add ewmh support without this new feature. So, I would
like to add it as soon as possible. Also, I think that it will be
good to solve the buttons@ vs colors-decor@ problems before 0.5.0.
So, I will prefer to wait the 19th to go into feature freeze (I also
want to add debian menu system support and maybe improve "minimal"
switching) and release 0.5.0 after some testings.

But any way, if you want to release 0.5.0 soon go head.

> Now, let test that everything works before releasing 0.5.0.
> I get "Can't load font" in ThemesCenter (12 times).

Can you give more info ($LANG, $LC_CTYPE, fvwm version,
fvwm-config --supports-multibyte)?

Regards, Olivier

Re: releasing 0.5.0

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

On 01 Aug 2001 06:48:55 +0200, Olivier Chapuis wrote:
> 
> On Sun, Jul 29, 2001 at 07:00:48AM +0000, Mikhael Goikhman wrote:
> > On 28 Jul 2001 06:26:12 +0200, Olivier Chapuis wrote:
> > > 
> > > On Sun, Jul 22, 2001 at 10:44:17PM +0000, Mikhael Goikhman wrote:
> > > > I think everything is ready for 0.5.0.
> > > 
> > > What is your plan now?
> > 
> > Since I started to add globallook component, my plan is to finish it.

Ok, I did it and it seems good to me.

You once wrote about sticking buttons@ to colors-decor@ in some themes,
like Mech, this is not done. I thought about using a memory for restoring
previous buttons@ when colors-decor@ is unloaded, but this is not trivial.

> > I also want to replace colors@default unless anyone objects, gray and gray
> 
> I've no objection for changes in the default colors

A new (much better IMHO) color scheme is implemented.

> > > What I want to do is a new .cfg config option of the form
> > > 
> > > 	system-requires="test"
> > > 
> > > for component (and also maybe for individual variant).

I renamed "system-requires" to "unhide-if" and did some other renamings.
I am not sure how good is to hide whole components and not only variants,
but we will see.

A start-stop stuff you wrote about in another thread may wait for 0.5.1.
I started to do Metal (java-like) theme, but it probably should wait too.

Now, let test that everything works before releasing 0.5.0.
I get "Can't load font" in ThemesCenter (12 times).

Regards,
Mikhael.