fvwm-themes-devel — Developing FVWM Themes

Re: New FvwmForm-ThemeSettings and FvwmGtk-Themes

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

On 05 Nov 2000 21:12:35 +1030, Alex Wallis wrote:
> 
> Mikhael Goikhman wrote:
> > 
> > I already did several fixes. It's possible to improve a layout a bit,
> > but I would not spend much time on this.
> 
> I touched up the FvwmGtk-Themes a bit. See attached.

Ok, notebooks are nice. Although, I probably like more to see all choices
on one screen than on three screens. I did something in the middle this
time - two screens. I hope you like it too.

> On a related point, the ability to adjust the --time-limit option for
> fvwm-menu-desktop would enable me to get all my KDE menus since 15 secs
> is too short on a slow machine.

This is strange. I get less than a second. Probably there is something
interesting in your kde apps and a problem in fvwm-menu-desktop.
Please determine which command from these ones takes so much time:

  fvwm-themes-config -e | grep fvwm-menu-desktop

> Perhaps a slider widget could be added to FvwmGtk-Themes, KDE Options,
> for this new setting?

Regards,
Mikhael.

Re: fvwm-themes 0.3.21 is out

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

Mikhael Goikhman wrote:
> 
> On 04 Nov 2000 22:44:25 +0100, Olivier Chapuis wrote:
> >
> > Unfortunately, there is a "big" bug for me:
> > the "use strict" line in fvwm-themes-script break
> > completely the ConfigCenter (the Xmessage Script appear
> > and never disappear because a fatal error happen in
> > fvwm-themes-script).
> > I've just commented this line in my last commit.
> > May be Mikhael you can re-upload 0.3.21 with this
> > change?

The ConfigCenter has never worked for me either. All I get is the
hanging FvwmScript XMessage too. I'm just compiling the latest cvs
sources now, so I'll see what happens.

Nope! All I get is still the hanging "Loading Configuration" window and
the following X error log entries......
com: No lock Fifo .tmp-com-lock-script-8747 for script-8747
communication
cannot open .tmp-com-buf-script-8747 at /usr/local/bin/fvwm-themes-com
line 62.
[FVWM][Echo]:  ConfigCenter: problems when loading themes config!
[FVWM][Echo]:  ConfigCenter: can you send a bug report to:
[FVWM][Echo]:  ConfigCenter: <fvw...@li...>

> 
> This is what happens when you are not available for several days. :)
> 
> We can't simply re-upload this (but if you do this I am not against).
> Creating .tar.gz, .tar.bz2, then rpm's for both fvwm and fvwm-themes
> on 2 systems (both remote), uploading and adding all this takes time.

I just did an install of SuSE6.2 for my brother, but when I tried to
install with the rpm's of fvwm and fvwm-themes I had a couple of
problems.

The first was the fvwm had failed dependencies even after upgrading the
readline libs from the link noted on the rpm page. The --no-deps
installed it but of course it was broken.

Now I've installed the cvs sources from a few days ago, and fvwm can't
find the libstroke version 4. I'll try and send more details next time I
get on my brother's machine.

> 
> Maybe we can work on remaining tasks quickly and just release 0.4.0?
> 
> The remaining tasks (in TODO):
> 
>   * Revise all existing docs
>   * I should write more docs on CCDS

I'm willing to assist with the documentation if I can, and help with
adjusting any minor spelling and grammar errors. I'm not sure of the
best way to go about it though.

>   * I planned to have doc/creating-themes with instructions [optional]
>   * I should optimize fvwm-themes-config a bit, 2 secongs is bad
>   * Someone should test and port fvwm-themes to BSD and Solaris. Anyone?
>     There are problems for sure, mkdir without -p, no killall etc.

I have installed fvwm-themes a couple of times on Free-BSD and Open-BSD
machines. If the BSD box has support for linux libraries, I haven't had
a real problem.
On a BSD only machine however, fvwm had lots of problems and wouldn't
compile.

>   * Convert all hardcoded $FT_DATADIR/... paths to relative $./ [optional]
>   * Translations [optional]
>   * Full testing of all combinations, all choices etc.

I'm losing the odd menu or two. Especially the "Restart Other" menu.

>   * One day for internal packaging and testing packages, then uploading
> 
> Regards,
> Mikhael.


Regards, 

Alex

Re: fvwm-themes 0.3.21 is out

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

On 04 Nov 2000 22:44:25 +0100, Olivier Chapuis wrote:
> 
> Unfortunately, there is a "big" bug for me:
> the "use strict" line in fvwm-themes-script break 
> completely the ConfigCenter (the Xmessage Script appear 
> and never disappear because a fatal error happen in 
> fvwm-themes-script).
> I've just commented this line in my last commit.
> May be Mikhael you can re-upload 0.3.21 with this
> change?

This is what happens when you are not available for several days. :)

We can't simply re-upload this (but if you do this I am not against).
Creating .tar.gz, .tar.bz2, then rpm's for both fvwm and fvwm-themes
on 2 systems (both remote), uploading and adding all this takes time.

Maybe we can work on remaining tasks quickly and just release 0.4.0?

The remaining tasks (in TODO):

  * Revise all existing docs
  * I should write more docs on CCDS
  * I planned to have doc/creating-themes with instructions [optional]
  * I should optimize fvwm-themes-config a bit, 2 secongs is bad
  * Someone should test and port fvwm-themes to BSD and Solaris. Anyone?
    There are problems for sure, mkdir without -p, no killall etc.
  * Convert all hardcoded $FT_DATADIR/... paths to relative $./ [optional]
  * Translations [optional]
  * Full testing of all combinations, all choices etc.
  * One day for internal packaging and testing packages, then uploading

Regards,
Mikhael.

Re: fvwm-themes 0.3.21 is out

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

Mikhael Goikhman wrote:
> 
> The new version contains the completed cde theme, updates to several GUI's
> and some more.
> 
> Due to temporary problems on SF, the packages are currently on:
> 
>   ftp://fvwm-themes.sourceforge.net/pub/fvwm-themes/src/
> 
> The rpms are in the usual place (src/ replaced with rpm/ in the URL above).
> 
> This version has some incompatibilities in components bindings@ and
> desktop@ (replaced with globalfeel@), but you should not notice it if you
> start fvwm as usual using fvwm-themes-start or do Restart fvwm-themes
> after upgrading from within a Restart Other menu. There also may be some
> problems with old fvwm-themes sessions because of these incompatibilities.
> If you have problems, run 'fvwm-themes-config -r' manually and Restart.
> 
> It may be the last 0.3 version. The next one will be focused on clean-ups,
> fixes, documentation, porting to non GNU platforms and similar.
> 

Unfortunately, there is a "big" bug for me:
the "use strict" line in fvwm-themes-script break 
completely the ConfigCenter (the Xmessage Script appear 
and never disappear because a fatal error happen in 
fvwm-themes-script).
I've just commented this line in my last commit.
May be Mikhael you can re-upload 0.3.21 with this
change?

Olivier

fvwm-themes 0.3.21 is out

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

The new version contains the completed cde theme, updates to several GUI's
and some more.

Due to temporary problems on SF, the packages are currently on:

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

The rpms are in the usual place (src/ replaced with rpm/ in the URL above).

This version has some incompatibilities in components bindings@ and
desktop@ (replaced with globalfeel@), but you should not notice it if you
start fvwm as usual using fvwm-themes-start or do Restart fvwm-themes
after upgrading from within a Restart Other menu. There also may be some
problems with old fvwm-themes sessions because of these incompatibilities.
If you have problems, run 'fvwm-themes-config -r' manually and Restart.

It may be the last 0.3 version. The next one will be focused on clean-ups,
fixes, documentation, porting to non GNU platforms and similar.

Regards,
Mikhael.

Re: fvwm-config

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

On 01 Nov 2000 18:11:49 +0100, Roeland Moors wrote:
> 
> when I tried to install fvwm-config, the program is saying that I need
> fvwm-config, and that I have to install fvwm 2.3.22. But I already installed
> version 2.3.5.
> Is there something changed in that version ?

Hi, Roeland.

Even fvwm-themes 0.0.1 will not work with fvwm 2.3.5. Try to install the
latest fvwm version and scan files NEWS and ChangeLog, there are about
100 new features, dozens of bug fixes. fvwm now contains fvwm-config.

And fvwm-themes always uses the latest fvwm changes. Example. The latest
released fvwm version is 2.3.21, but the latest fvwm-themes 0.3.20
requires fvwm pre-2.3.22, i.e. the version from cvs or latest snapshots.
To get things even more interesting, the next fvwm-themes version (which
will be released soon) also requires pre-2.3.22, but more current.

The rule is this, you should always install the latest for that day fvwm
before installing fvwm-themes. It may be inconvenient for a user, but
development versions are not supposed to be convenient for the end user.
When fvwm 2.4.0 will be out, these dependency problems will disappear.

For now, I can suggest you to use cvs or latest snapshots (if exist),
or to get rpm's for both packages, they should have correct dependances.

Regards,
Mikhael.

fvwm-config

[Roeland M. <tr...@wa...>]

when I tried to install fvwm-config, the program is saying that I need
fvwm-config, and that I have to install fvwm 2.3.22. But I already installed
version 2.3.5.
Is there something changed in that version ?

Roeland

Re: New FvwmForm-ThemeSettings and FvwmGtk-Themes

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

On 29 Oct 2000 23:11:08 +1030, Alex Wallis wrote:
> 
> All the variant commands are now apparently numbers, and a few options
> have changed, so the form needed a little work here and there. I liked
> the improvements someone made to the structure and syntax too.

I only changed some syntax, not the structure.

> I tried to make the form represent what I see in the menu version as
> closely as possible. I also updated the FvwmGtk-Themes config to match
> the form. (See attachments)

Ok, good, I commited them.

> However, although I have tried to make them comply with fvwm-themes
> command structure, neither form nor gtk dialog actually work and produce
> the following errors.

At least the error windows are nice, eh? :)

> The form produces a nice little xmessage window entitled
> "fvwm-themes-config error" which contains only the following line...
> Unexisting variant ` 1 ` in component `settings/gnome/anotherlevel-menu`

This is due to a bug (misfeature) in FvwmForm regarding selection, it
should not add leading and trailing space. I did a workaround for this in
fvwm-themes, but this should be fixed in FvwmForm instead.

> The gtk dialog produces a similar spiffy little box with the same title
> but contains...
> No component `settings/session` cfg in theme Current

It says true, there is settings/session-manager component instead.

> I'm sure these problems can/will be fixed though.  :-)
> 
> Let me know if anything about these GUI's needs rearranging, or fixing.

I already did several fixes. It's possible to improve a layout a bit,
but I would not spend much time on this.

Regards,
Mikhael.

New FvwmForm-ThemeSettings and FvwmGtk-Themes

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

Mikhael Goikhman wrote:
> 
> 
> Another issue. Alex, the FvwmForm-ThemeSettings does not work, since
> 'session' variant now renamed. If this will not be fixed soon we will
> need to comment in this form, since there are 2 alternatives now.
> 

All the variant commands are now apparently numbers, and a few options
have changed, so the form needed a little work here and there. I liked
the improvements someone made to the structure and syntax too.

I tried to make the form represent what I see in the menu version as
closely as possible. I also updated the FvwmGtk-Themes config to match
the form. (See attachments)

However, although I have tried to make them comply with fvwm-themes
command structure, neither form nor gtk dialog actually work and produce
the following errors.

The form produces a nice little xmessage window entitled
"fvwm-themes-config error" which contains only the following line...
Unexisting variant ` 1 ` in component `settings/gnome/anotherlevel-menu`

The gtk dialog produces a similar spiffy little box with the same title
but contains...
No component `settings/session` cfg in theme Current

I'm sure these problems can/will be fixed though.  :-)

Let me know if anything about these GUI's needs rearranging, or fixing.


Regards.

Alex

Re: follows in ft-config and more

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

Mikhael Goikhman wrote:
> 
> Please describe all globalfeel@ dependances. Here is the correct way.
> For example, menus requires some-thing that globalfeel provides:
> 

Du to the ColorLimit command, globalfeel have to be read before
any icon is loaded. Also globalfeel have to be loaded before
modules and styles. So, in fact rougthly globalfeel have to be
read before any other component (but say function and bindings).
Olivier

Re: follows in ft-config and more

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

On 25 Oct 2000 21:39:28 +0200, Olivier Chapuis wrote:
> 
> It seems that the following instructions in modules.cfg
> is not respected:
> 
> follows+=styles
> 
> styles is always loaded at the end. It seems that there are
> other problems with settings/autoraise (which should be read
> after modules). Maybe this is my fault: I add some (to many
> and not in the good place: in background and all backgroud.cfg
> should be enough)
> 
> follows+=globalfeel
> 
> I try a lot of change in the *.cfg files and now I am little
> bit lost ...
> 
> Any way, globalfeel must be loaded before any icons is loaded.

Please describe all globalfeel@ dependances. Here is the correct way.
For example, menus requires some-thing that globalfeel provides:

[in menus]
requires+=some-thing

[in globalfeel]
provides+=some-thing

This way, if we move some-thing from globalfeel@ to another component,
the menus@ dependancies are not changed, as expected.
In theory, "follows" should not be used, I have added it for practical
reasons only. I have changed a bit the function, so requires+=globalfeel
has no effect now, because noone provides globalfeel item.

We should beware of circular dependances, there will no be an error, but
the result will be random.

In addition, I have found a problem in evaluating dependencies.
I will try to find a fix before 0.4.0.

> So in particular after that the "themes menu" is loaded.
> Moreover, it seems to me that the themes menu have to be
> put in a separated file (for CCD reasons and others) and 
> that themes-rc-2 have to read it (say at the last line ...).

Maybe. I don't like too much to have many themes-rc-*, we can experiment
later with this, but for now we can simply put these menus at the end.

Regards,
Mikhael.

Re: cde theme

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

On 25 Oct 2000 21:54:49 +0200, Olivier Chapuis wrote:
> 
> > >     * Added module files for CDE button bar in two versions.
> > >       One small version for laptop panels, one large version.
> > >       Two sets of pixmaps are included.
> > 
> > Ok, I rearranged them.
> 
> This a great idea :o) but I think that the small panel is to small
> (icons are ok) but I think some thing like 680x57 on a 800x600 screen
> will be better.

If we implement later an option 5+5 (or any+any) buttons, the current
default 4+4 has probably a good size. The pager can be rethought.
I didn't try to understand the math yet, say, what the constant 5 means.

And we don't work on cde@ before 0.4.0 except for small fixes anyway.

> > >     * The text colors in the color schemes were changed, so
> > >       as to conform more to CDE by using a threshold value
> > >       of 200 instead of 128 for generating the text color.
> > 
> > I recalculated using a threshold 192 (75%), but this still gives too
> > bright foreground color (too white-ish). I would do something like 140,
> > but I don't want to decide here. Currently it is 192.
> 
> When I generate with 128 I do not try to think, it was logic for me. But
> after some test I see that a bigger value will be better. However, I
> think that 192 is too much and IMHO 140 is the next value to test.

If 192 (or 200) matches the real thing (I didn't get yet an answer what
the real cde fore colors are), it is ok by me. With less than 182, one of
the default fore colors becomes black and Jos says they all are white...

-==-

If we speak about cde, I have tried xfce yesterday. It is ok. The window
manager xfwm is a bit old though (it is based on fvwm-2.1.*, I think).

It is possible to run the xfce itself (without xfwm) even from fvwm
and you get a good cde panel emulation, it is gtk-based. Worths a look.

Regards,
Mikhael.

Re: cde theme

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

Mikhael Goikhman wrote:
> 
> On 22 Oct 2000 20:28:17 +0200, Jos van Riswick wrote:
> >
> > I've been working on the cde theme, and although it's not
> > completely finished yet, here's a first version:
> 
> Ok, looks nice. I needed to do many changes expecially to modules to close
> a lot of small issues and still there are some of them to improve sometime
> in the future, but they are not urgent.
>

Yes, it looks nice !


> 
> I added DepressableBorder to windowlook@cde (I thought whether it belongs
> to globalfeel, but probably it should be with all other border options).
>

Yes
 
> -==-
> 
> > Some things are not working properly yet, see the README file:
> >
> >
> >     * Changed fvwm-themes-images, so that only the dark color
> >       can be specified. As in CDE, the dark color comes from
> >       the color scheme (color nr 3), and is displayed at the
> >       bottom. The light color is then calculated from this.
> 
> Ok.
> 
> >     * Added module files for CDE button bar in two versions.
> >       One small version for laptop panels, one large version.
> >       Two sets of pixmaps are included.
> 
> Ok, I rearranged them.
> 

This a great idea :o) but I think that the small panel is to small
(icons are ok) but I think some thing like 680x57 on a 800x600 screen
will be better.

> >     * The text colors in the color schemes were changed, so
> >       as to conform more to CDE by using a threshold value
> >       of 200 instead of 128 for generating the text color.
> 
> I recalculated using a threshold 192 (75%), but this still gives too
> bright foreground color (too white-ish). I would do something like 140,
> but I don't want to decide here. Currently it is 192.
> 

When I generate with 128 I do not try to think, it was logic for me. But
after some test I see that a bigger value will be better. However, I
think
that 192 is too much and IMHO 140 is the next value to test.

Olivier

follows in ft-config and more

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

Hello,
It seems that the following instructions in modules.cfg
is not respected:

follows+=styles

styles is always loaded at the end. It seems that there are
other problems with settings/autoraise (which should be read
after modules). Maybe this is my fault: I add some (to many
and not in the good place: in background and all backgroud.cfg
should be enough)

follows+=globalfeel

I try a lot of change in the *.cfg files and now I am little
bit lost ...

Any way, globalfeel must be loaded before any icons is loaded.
So in particular after that the "themes menu" is loaded.
Moreover, it seems to me that the themes menu have to be
put in a separated file (for CCD reasons and others) and 
that themes-rc-2 have to read it (say at the last line ...).

Olivier

Re: cde theme

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

On 22 Oct 2000 20:28:17 +0200, Jos van Riswick wrote:
> 
> I've been working on the cde theme, and although it's not
> completely finished yet, here's a first version:

Ok, looks nice. I needed to do many changes expecially to modules to close
a lot of small issues and still there are some of them to improve sometime
in the future, but they are not urgent.

You didn't include one icon sliderarrow and one module config; I created
this icon myself, but I have no idea what FvwmScript-CDEDate does, so
please send it to me.

-==-

About images. The first time I saw this corporate crap, I wanted to delete
it, we don't want to include any copyrighted data. On the other hand we
are not the first (and not the second) simulating CDE, so I did some work
on images. Renamed them to be wm-icons compatible, edited some of them,
replaced one. The ideal solution is to replace them with ones from
wm-icons 16x16, 32x32, 48x48 icon sets (f.e. kde sets) or create our own
replacements. We can always do this later if someone from CDE states we
don't use their data fairly. The same story about their palletes, we can
always remove them completely on the first request and replace them by
our own 8 colors, generated by our to-be-written quasi-random algorithm.

-==-

I changed menustyle@cde to be more like 'MenuStyle * mwm'. Probably this
is a not good idea. IIRC CDE uses dtwm, not mwm, but it still seems more
logical to me. I changed AnimationOff, PopupDelay (mwm style don't use
delay at all, but this is not very good), PopupOffset, TitleUnderlines2
and Hilight3DThickness (-1 is nice, but is this used in CDE?).
If you think my changes to menustyle@ are bad, tell about this.

-==-

I don't think that we should include bindings@cde, we don't do this with
other themes. Also they are not good. For example, Ctrl-K, Alt-N and
similar used in a lot of applications. Ctrl-Alt-K is better, but even
this can be used in an application, so we should be careful with these.
Anyone may suggest a good binding to be included into bindings@default.

-==-

I added DepressableBorder to windowlook@cde (I thought whether it belongs
to globalfeel, but probably it should be with all other border options).

-==-

> Some things are not working properly yet, see the README file:
> 
> 
>     * Changed fvwm-themes-images, so that only the dark color
>       can be specified. As in CDE, the dark color comes from 
>       the color scheme (color nr 3), and is displayed at the
>       bottom. The light color is then calculated from this. 

Ok.

>     * Added module files for CDE button bar in two versions.
>       One small version for laptop panels, one large version.
>       Two sets of pixmaps are included.

Ok, I rearranged them.

>     * The text colors in the color schemes were changed, so 
>       as to conform more to CDE by using a threshold value
>       of 200 instead of 128 for generating the text color. 

I recalculated using a threshold 192 (75%), but this still gives too
bright foreground color (too white-ish). I would do something like 140,
but I don't want to decide here. Currently it is 192.

>     * Added a second set of color schemes, using only
>       4 colors instead of 8. (Color 5=2, 6=2, 7=1, 8=3). (These
>       look less clashing.) Don't know yet how to do this, put
>       this in the menu structure? 

I implemented this as an option.

> TODO
> 
>     * The small and large button bar should be accompanied by 
>       a small and large font scheme. I don't know yet how
>       to do this, as fonts are set in each component separately.

In the (far) future we may have fontsets (like colorsets) in fvwm, so we
could define fonts for different purposes centrally. Until then I don't
see any good solution for this. Of course, we can have a fonts@ component,
which should be m4 processed, but then all other components should also be
m4 processed and this is too expensive.

The real TODO:

* Change pager layout. Currently it is not proportional; cde uses 2x2,
not 4x1. Probably introduce an option showing buttons instead of pager,
similar to "First", "Second", "Third", "Forth" in CDE.

* Dynamically generate panel-*.xpm icons for a given colorset, like I
wrote some days ago. Not urgent. This looks acceptably good now.

* Probably add a run-time option, which will switch from 4+4 buttons (now)
to 5+5 and/or 3+3 buttons (for both small and large panels, of course).

* Improve bound menus/applications, although they are already good.
You know you can have function-appbind@personal and redefine every app.

* Probably some colors can be improved.

TODO for fvwm (probably in 2.5):

* Fix a problem causing the left-top menu do not fully work.

* Add FvwmButtons SendToButton module config command to change a state of
buttons, so it would be possible to switch mail or (dis)connected icons.

-==-

Ok, nice work, Jos, keep it. :)

Regards,
Mikhael.

Re: globalfeel editor

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

Mikhael Goikhman wrote:
> 
> On 22 Oct 2000 22:40:30 +0200, Olivier Chapuis wrote:
> >
> > Mikhael Goikhman wrote:
> > >
> > > I suppose you start with separate windows for all component editors.
> >
> > No, in fact my plan is to do *one* "Configuration Center" (CC) which can
> > edit almost all the files "desktop", "bindings", "function-appbind",
> > the look files ...etc. Other GUI can take place, as the Menu Editor
> > which need some works, a GUI for modules themes (no idea yet) and
> > one for application styles (maybe based on menus, as we have but
> > with a save options).
> 
> All these editors are unrelated one to another, so I see no benefits
> in fitting them into one huge script. And a big work of hiding/unhiding
> all widgets will not be needed if you do it separately.
> 
> > I think that we need a limited numbers of GUI ...
> 
> Yes, but this does not contradict with a modular way. A user will not see
> a difference if you use "Swallow another FvwmScript" widget. 

There two problems with Swallowing in FvwmScript:
1. This does not work well (problem of communication)
2. One big script will use less memory that one script that
swallow say 5 scripts (~ 4 times less).

The fact that "All these editors are unrelated one to another" is
not a problem for me. 

> And even if
> it is not possible to do now (I hope it is possible), I still prefer
> separate windows to a huge one script/window. A bug (or change in spec) in
> one component editor will only break this one editor, not entire center.
>

It have to be well designed so that each components are more or less
independent in the script. But, you are true this is more difficult
than, multi scripts. Also, I think that with a lot of GUI the
user will be lost. In fact it is for me the main reason I want
a limited number of GUI.

> 
> I only want to make your work easier and more extensible. You decide here.
>

Thanks, I will think on all your suggestions
Olivier

Re: desktop

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

On 22 Oct 2000 11:56:15 +0200, Olivier Chapuis wrote:
> 
> And what about "general"?

Seems too general to me. And it's adjective unlike other component names.
90% of "desktop" is a feel, so I prefer "globalfeel"; "globals" is ok too.

Regards,
Mikhael.

Re: globalfeel editor

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

On 22 Oct 2000 22:40:30 +0200, Olivier Chapuis wrote:
> 
> Mikhael Goikhman wrote:
> > 
> > I suppose you start with separate windows for all component editors.
> 
> No, in fact my plan is to do *one* "Configuration Center" (CC) which can
> edit almost all the files "desktop", "bindings", "function-appbind",
> the look files ...etc. Other GUI can take place, as the Menu Editor
> which need some works, a GUI for modules themes (no idea yet) and
> one for application styles (maybe based on menus, as we have but
> with a save options).

All these editors are unrelated one to another, so I see no benefits
in fitting them into one huge script. And a big work of hiding/unhiding
all widgets will not be needed if you do it separately.

> I think that we need a limited numbers of GUI ...

Yes, but this does not contradict with a modular way. A user will not see
a difference if you use "Swallow another FvwmScript" widget. And even if
it is not possible to do now (I hope it is possible), I still prefer
separate windows to a huge one script/window. A bug (or change in spec) in
one component editor will only break this one editor, not entire center.

> > They can be named FvwmScript-ConfigEditor-globalfeel and all be of the
> > size, say, 640x480. 
> > Maybe we need ThemeEditor instead of ConfigCenter,
> > which can create a new theme, add/delete components, edit them by calling
> > their editors (in a new window or by swallowing) if exist.
> > 
> > A general component editor could be a stand-alone app with an optional
> > theme parameter (default can be 'personal' for some components). Later
> > it can be added a common theme picker if no theme parameter is given.

I only want to make your work easier and more extensible. You decide here.

Regards,
Mikhael.

Re: globalfeel editor

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

Mikhael Goikhman wrote:
> 
> On 20 Oct 2000 07:12:35 +0200, Olivier Chapuis wrote:
> >
> > So, I've begin the "Configuration Center" and of course I begin
> > by this globalfeel files (In fact almost finished).
> 
> I am sure you know what to do for GUI, here are my small comments.
> 
> I suppose you start with separate windows for all component editors.

No, in fact my plan is to do *one* "Configuration Center" (CC) which can
edit almost all the files "desktop", "bindings", "function-appbind",
the look files ...etc. Other GUI can take place, as the Menu Editor
which need some works, a GUI for modules themes (no idea yet) and
one for application styles (maybe based on menus, as we have but
with a save options).
I think that we need a limited numbers of GUI ...
 
> They can be named FvwmScript-ConfigEditor-globalfeel and all be of the
> size, say, 640x480. 
> Maybe we need ThemeEditor instead of ConfigCenter,
> which can create a new theme, add/delete components, edit them by calling
> their editors (in a new window or by swallowing) if exist.
> 
> A general component editor could be a stand-alone app with an optional
> theme parameter (default can be 'personal' for some components). Later
> it can be added a common theme picker if no theme parameter is given.
> 

Yes, CC use by default the personal theme (or any theme in the userdir
directory) to save. We may add a "create/remove theme" in this GUI 
(planed but I will not doing it now since you just have to mkdir/rmdir 
to create/remove themes and restart the CC).
About the name "Configuration Center" it can be changed in the future,
this will not be difficult.

> And I definitely think we don't really need this before 0.4.0, maybe one
> globalfeel@ editor if you already started it.
>

Yes, but I think that the focus policy and paging must be configured
at once by the user. So I start the CC which will first be able to edit 
"desktop" and will be able to "edit" more and more components with the 
time!

> >   So, I need a
> > spec for this file. Below, a default file. I do not want to
> > start a discussion on these defaults, but the questions are:
> > 1. Do I forget a "global feel" config command/Styles?
> > 2. Do some config command/Styles have to go in an other place?
> 
> Let start with your proposal for globalfeel, I may make changes later.
> I know, you need a spec before writing a GUI, but we will not have it
> before we try and fix. 

Ok, changes in the script may be a little bit tricky but can be done.
Just an email to the list if the spec changes :o)

> Here FvwmScript configuration, although gives nicer
> results, is harder to modify than more simple FvwmGtk or FvwmForm.
> 

Yes, but I do not see how to do something as the ThemesCenter with
FvwmGtk or FvwmForm. Moreover, fvwm-themes-com allows to use
perl intensively with FvwmScript.
 
Olivier

Re: cde theme

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

On 22 Oct 2000 20:28:17 +0200, Jos van Riswick wrote:
> 
> I've been working on the cde theme, and although it's not
> completely finished yet, here's a first version:
> 
> http://www.xs4all.nl/~josvanr/cde.tar.gz

Ok, I will try to incorporate your changes shortly.
Then I will comment on them.

Regards,
Mikhael.

cde theme

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

Hi

I've been working on the cde theme, and although it's not
completely finished yet, here's a first version:

http://www.xs4all.nl/~josvanr/cde.tar.gz

Some things are not working properly yet, see the README file:


    * Changed fvwm-themes-images, so that only the dark color
      can be specified. As in CDE, the dark color comes from 
      the color scheme (color nr 3), and is displayed at the
      bottom. The light color is then calculated from this. 

    * Added module files for CDE button bar in two versions.
      One small version for laptop panels, one large version.
      Two sets of pixmaps are included.

    * The text colors in the color schemes were changed, so 
      as to conform more to CDE by using a threshold value
      of 200 instead of 128 for generating the text color. 

    * Added a second set of color schemes, using only
      4 colors instead of 8. (Color 5=2, 6=2, 7=1, 8=3). (These
      look less clashing.) Don't know yet how to do this, put
      this in the menu structure? 

TODO

    * The small and large button bar should be accompanied by 
      a small and large font scheme. I don't know yet how
      to do this, as fonts are set in each component separately.


best regards,

jos

Re: Quitting? and cvs error!

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

On 20 Oct 2000 02:00:44 +0200, Mikhael Goikhman wrote:
> 
> However, I can consistently  reproduce fvwm core dump in free_icon_boxes
> when loading modules@awol and refreshing the current theme twice.

This problem is fixed in the current fvwm. I think there are no any more
problems with modules@awol. If you think about improvements to awol, you
can always post them (changes to the existing awol components).

Another issue. Alex, the FvwmForm-ThemeSettings does not work, since
'session' variant now renamed. If this will not be fixed soon we will
need to comment in this form, since there are 2 alternatives now.

Regards,
Mikhael.

Re: desktop

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

Mikhael Goikhman wrote:
> 
> On 15 Oct 2000 21:00:57 +0200, Olivier Chapuis wrote:
> > Here I need a name. What about global-feel ?
> 
> I would prefer globalfeel spelling (like windowlook, menustyles).

And what about "general"?
Olivier

globalfeel editor

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

On 20 Oct 2000 07:12:35 +0200, Olivier Chapuis wrote:
> 
> So, I've begin the "Configuration Center" and of course I begin
> by this globalfeel files (In fact almost finished).

I am sure you know what to do for GUI, here are my small comments.

I suppose you start with separate windows for all component editors.
They can be named FvwmScript-ConfigEditor-globalfeel and all be of the
size, say, 640x480. Maybe we need ThemeEditor instead of ConfigCenter,
which can create a new theme, add/delete components, edit them by calling
their editors (in a new window or by swallowing) if exist.

A general component editor could be a stand-alone app with an optional
theme parameter (default can be 'personal' for some components). Later
it can be added a common theme picker if no theme parameter is given.

And I definitely think we don't really need this before 0.4.0, maybe one
globalfeel@ editor if you already started it.

>   So, I need a 
> spec for this file. Below, a default file. I do not want to
> start a discussion on these defaults, but the questions are:
> 1. Do I forget a "global feel" config command/Styles?
> 2. Do some config command/Styles have to go in an other place?

Let start with your proposal for globalfeel, I may make changes later.
I know, you need a spec before writing a GUI, but we will not have it
before we try and fix. Here FvwmScript configuration, although gives nicer
results, is harder to modify than more simple FvwmGtk or FvwmForm.

Regards,
Mikhael.

Re: desktop

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

Mikhael Goikhman wrote:
> 
> On 15 Oct 2000 21:00:57 +0200, Olivier Chapuis wrote:
> >
> > Mikhael Goikhman wrote:
> > >
> > > On 09 Oct 2000 11:52:38 +0200, Olivier Chapuis wrote:
> > > >
> > > > ok, but XORValue which should be moved into background
> > > > (with XorPixmap).
> > >
> > > Usually 50% or more of my screen is applications, so these commands are
> > > as well can be included in colors@. Or maybe just leave it as is?
> >
> > Ok, but we know the color of the background, but we do not know
> > the colors all the applications. Any way, any objection for
> > moving this in @color?
> 
> Probably these commands need not be themable like background@ or colors@,
> I would leave them as is, but I let you decide here.
> 
> > > > I suggest to rename it major-modes but there are surely
> > > > a better name. Any ideas?
> > >
> > > I don't think that major-modes name is better than desktop.
> > > Maybe "globals"? Or "globalstyles"? Hmm, how about "feel"? :)
> > > I think we need some time to finalize its name... "commonfeel"?
> >
> > Here I need a name. What about global-feel ?
> 
> I would prefer globalfeel spelling (like windowlook, menustyles).

Yes, good.

So, I've begin the "Configuration Center" and of course I begin
by this globalfeel files (In fact almost finished). So, I need a 
spec for this file. Below, a default file. I do not want to
start a discussion on these defaults, but the questions are:
1. Do I forget a "global feel" config command/Styles?
2. Do some config command/Styles have to go in an other place?

Note that finally I "decide" to do not move the "Xor*" commands
(BTW, there are maybe a problem with the XorValue command, see my
message in fvwm-devel).

Olivier

PS: In fact comments for the default/globalfeel are welcome.

# Automatically build by FVWM-Themes on ven oct 20 07:07:04 CEST 2000 
# for ol...@sn...

# -------------------------- Focus and Placement
--------------------------

Style * SloppyFocus, ClickToFocusPassesClick, ClickToFocusRaises,
MouseFocusClic
kRaises
ColormapFocus FollowsMouse
Style * SmartPlacement, RandomPlacement, CleverPlacementOff,
GrabFocusOff, NoPPo
sition

# ---------------------------- Move and Resize
----------------------------

Style * ResizeOutLine
OpaqueMoveSize 10
Emulate FVWM
HideGeometryWindow Never
BugOpts FlickeringMoveWorkaround Off
SnapAttraction 0 All Screen
SnapGrid 1 1
XorValue 555555

# ---------------------- Paging and Mouse Parameters
----------------------

EdgeScroll 0 0
EdgeResistance 0  1 
EdgeThickness 1
ClickTime 300
MoveThreshold 3

# -------------------- Transient Windows and Animation
--------------------

Style * NakedTransient, DontRaiseTransient, DontLowerTransient,
DontStackTransie
ntParent, GrabFocusTransient
Style * WindowShadeSteps 20, WindowShadeScrolls
SetAnimation  10  -.01 0 .01 .03 .08 .18 .3 .45 .6 .75 .85 .90 .94 .97
.99 1.0

# --------------------- Hints, Busy Cursor and Avanced
---------------------

Style * MwmDecor, OLDecor, HintOverride, MwmFunctions, GNOMEUseHints
BugOpts ModalityIsEvil on
BusyCursor Read on, Recapture on, Wait on, ModuleSynchronous on
ColorLimit 0
BugOpts MixedVisualWorkaround off
BugOpts RaiseOverNativeWindows off
Style * SaveUnderOff, BackingStoreOff
ModuleTimeout 30