fvwm-themes-devel — Developing FVWM Themes

Re: CVS messages ?

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

On 28 Jul 2000 09:26:27 +0200, Olivier Chapuis wrote:
> 
> I do not know if we have cvs messages.

No, we have no these messages for now, I should ask to install some
scripts for us. But we can live without them for now.

No needs to post here parts of ChangeLog, anyone who wants can read it. :)

Regards,
Mikhael.

A colorset spec

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

Hello,
Here a spec for fvwm-thmes colorsets
Any suggestions are welcome before I begin the work on colorset.

1- Fvwm colorsets:
------------------

Colorset 0: default colorset.
 I think that we have to add "DefaultColorset 0".
 This color is used by the geometry window. is it
 use for other windows?
         
Colorest 1 and 2: Colorset, HilightColorset
 The colors of the shaded and hilight part of the title bar of
 a window (with and without the focus), the color of the icons title
 bar. Colors of the windows of FvwmPager. Is these colors used in othe
 situation?
 Note that we will not use this color for setting the color of the 
 normal part of the title bar of a window. For this we use
 TitleStyle and ButtonStyle (in general) because these commands are
 more powerful that the above style.

Colorest 3 and 4: BorderColorset,  HilightBorderColorset
 Colors of the borders of the windows

Colorset 5, 6 and 7: colorset for menu: as now

Colorset 8, 9: reserved for future use! is it a good idea to reserve 
intermediate colorsets? Or do we have to put it all at the end?

* Modules Colorsets
-------------------

Colorset 10: default module colorset: FvwmPager FvwmButtonColorset. 
 Can be use for *FvwmIconMan*Colorset FvwmIconBoxColorset (see also
 colorset 12)

Colorset 11: hilight default colorset: for hilighting a part of 
 of an FvwmButton or a certain swallowed applications.

Colorset 12: special colorset: as 10 but a more funny colors a gradien
 or a pixmap.

Colorset 13: Pager hilight colorset

Colorset 14: tips colorset (Pager, TaskBar)

Colorset 15: colorsets for swallowed applications

Colorset 16: colorset for more colors in a swallowed application
 (e.g., xclock & xload have -hl & -hd color)

Colorset 17: colorset for a normal button in the AppMans (IconBox, IconMan,
 TaskBar, WinList)

Colorset 18: colorset for a button which represent a window
 with the focus in the AppMans.

Colorset 19: colorset for a button which represent an iconified
 window in the AppMans.

Colorset 20: FvwmIdentColorset

Colorset 21: FvwmScrollColorset (do we need this colorset, colorset 32 is
  ok? or Colorset 0?)

Colorset 22: FvwmConsole

Colorset 23: dynamic colorset (a colorset that can change during use
  without affecting the whole look, e.g., for FvwmScript-ColorsetBrowser)

Colorset 24 to 25: reserved for modules themes

Colorset 26 to 29: reserved for future use

* Applications colorsets (Form and Script are here!)

Colorset 30: default (text) colorset for terminal like application
  (E.g., xterm in our menu)

Colorset 31: (text) colorset for remote shell/applications

Colorset 32: (text) root colorset

Colorset 31: default text colorset (the editors for xres, input text
  zone of Form and Script , ...)

Colorset 32: default colorset for the other part of the applications
 (normal color of Form and Script, no text part of an app: menu buttons 
 in emacs ...) 

Colorset 33: special applications colorset (for hilight)

Colorset 34 - 35: Reserved for future use.

Ok, so users colorsets can go from 36 to infinity ...

So, Do we have enought colorset? Do I forget something?
Any suggestions?

Olivier

CVS: a few "modules massive renaming" fixes

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

2000-07-28  olicha <olivier.chapuis@free>

	* themes/modules/Applets/fvwm:
	* bin/fvwm-themes-config.in:
	FvwmScript-NoteMessage was called as scripts/FvwmScript-NoteMessage
	so no theme switch without ctl-alt-escape ...

	* themes/redmond98/background/*
	use 8bits hex nbr in the place of the X name for colors 
	(for speed: win 5%).

Mikhael, why you have install scripts/* and forms/* to flat 
FT_DATADIR? the script/ prefix may be a part of the ft
name system?

Olivier

CVS messages ?

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

Hello,
I do not know if we have cvs messages. So here a
"cvs commit" message for my last/first commit:

	* bin/fvwm-themes-images.in:
	clean up and speed the code (note the --be-fast option for
	cde-sky). Complete the man page.
	Unlock fvwm-themes-images

Seems that everythings work fine. Great!!

Olivier

fvwm-themes in cvs

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

Starting from 0.3.12, fvwm-themes is in cvs.
You can read about an access info at:

  https://sourceforge.net/cvs/?group_id=1738

For a write access, contact me or Olivier.
You need the latest fvwm cvs to proceed with the latest fvwm-themes cvs.
The instruction are the same as for fvwm cvs, after an initial checkout:

  automake --add-missing
  autoreconf

As usual, new releases will be available every week or two from:

  https://sourceforge.net/projects/fvwm-themes/

Regards,
Mikhael.

fvwm-themes 0.3.12

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

Hello, all.

This release is mostly renamings, several bug fixes and some small
improvements. BTW, fvwm-themes-images is great!

A huge work was done for moving to a new module alias scheme. All module
aliases are now of form FvwmModule-SubName. To continue with this scheme
without conflicts we should change fvwm a bit.

I hope I didn't introduce problems while renaming in about thousand
places, I tested this release, but please test it more. Note that
segmentation faults and crashes (X and fvwm related) was not fixed yet.
IconMan in blackbox theme crashes as usual, because of a wrong geometry.

If your personal or local themes are partially not working, read ChangeLog
about what was renamed, say 'FvwmScript scripts/ScriptFvwmIconBrowser'
is now 'FvwmScript FvwmScript-IconBrowser'.

You need a recent fvwm snapshot from this week.

Regards,
Mikhael.

Re: version 0.3.11

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

On 23 Jul 2000 18:00:23 +0200, Olivier Chapuis wrote:
> 
> About module I think that the - or the . are two good ideas, maybe
> we can use "FvwmModule-Alias." this will give clear config file.

This is incorrect to fix an fvwm syntax problem by file names. I.e. a dot
(or space or semicollon) should be a part of fvwm module config syntax,
not a part of file or alias. I hope both syntaxes will work soon:

*MyModuleAlias:ConfigOption
*MyModuleAliasConfigOption

I definitelly planned to add this to fvwm before 2.4, just wanted to have
an active supporter first. We will discuss this on f-w after our 0.4.0.

> Your original proposition of using - is ok for me. In general,
> your are better than me for name, so go on if you want but this
> is an enormous work for an almost not visible result, do you have 
> a perl script for doing that?

I have a good text editor. This should be done manually to avoid errors.
I will do this in 2 steps (the second one will be optional & easy later).

Regards,
Mikhael.

Re: advanced dependancies

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

> 
> My point is this can be done after 0.4.0, but probably before fvwm-2.4.
> 

So ok.
Do you note that theme switching is slower? a litle bit
as before the remove bindings fix.
Olivier

Re: version 0.3.11

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

Mikhael Goikhman wrote:
> 
> On 23 Jul 2000 09:23:33 +0200, Olivier Chapuis wrote:
> >
> > Ok, now Mikhael, I wait the cvs :o) can I lock the colors
> > components?
> 
> Ok, I don't modify them.
> 
> I still wait for some comments, especially whether I should rename
> module aliases (there are many), it is easier to be done before cvs.
> Also probably at the beggining we will not have cvs log messages...
> 

About module I think that the - or the . are two good ideas, maybe
we can use "FvwmModule-Alias." this will give clear config file.
Your original proposition of using - is ok for me. In general,
your are better than me for name, so go on if you want but this
is an enormous work for an almost not visible result, do you have 
a perl script for doing that?

Regards, Olivier

Re: version 0.3.11

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

Olivier Chapuis wrote:
> 
> Hello all,
> Version 0.3.11 is available at:
> 
>   https://sourceforge.net/project/?group_id=1738
> 
> The main new stuff is a new script fvwm-themes-images. See,
> the man page for a description. It contains some jos colors
> scripts (colorize, cde-sky, some color functions). Jos your
> comments are welcome (I've done some modifications).
> Applications of this script:
> 
> * if you have GNOME installed you can try:
>         ./configure --enable-gnome-icons
> the gnome icons are converted to xpm icons (if you install
> again with --enable-gnome-icons the conversion is not done
> again). Then, try settings->GNOME->system-menu->fvwm menu and style
> (I think that I succed to remove the black noise created by
> ImageMagick; the conversion use ImageMagick and an internal
> filter).
> 
> * ft-images cde-sky is used to produce cde backgrounds. I've
> used color 1 and 2 of the cde shemes colors. better ideas?
> 

Oops, you need to 
	mv themes/cde/back:partten to themes/cde/back:pattern

> * ft-images colorize is used to produce a few optional
> backgrounds.
>

This is slow but it will be faster.

Olivier

Re: version 0.3.11

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

On 23 Jul 2000 09:23:33 +0200, Olivier Chapuis wrote:
> 
> Ok, now Mikhael, I wait the cvs :o) can I lock the colors
> components?

Ok, I don't modify them.

I still wait for some comments, especially whether I should rename
module aliases (there are many), it is easier to be done before cvs.
Also probably at the beggining we will not have cvs log messages...

Regards,
Mikhael.

version 0.3.11

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

Hello all,
Version 0.3.11 is available at:

  https://sourceforge.net/project/?group_id=1738

The main new stuff is a new script fvwm-themes-images. See,
the man page for a description. It contains some jos colors
scripts (colorize, cde-sky, some color functions). Jos your
comments are welcome (I've done some modifications).
Applications of this script:

* if you have GNOME installed you can try:
	./configure --enable-gnome-icons
the gnome icons are converted to xpm icons (if you install
again with --enable-gnome-icons the conversion is not done
again). Then, try settings->GNOME->system-menu->fvwm menu and style
(I think that I succed to remove the black noise created by
ImageMagick; the conversion use ImageMagick and an internal
filter).

* ft-images cde-sky is used to produce cde backgrounds. I've
used color 1 and 2 of the cde shemes colors. better ideas?

* ft-images colorize is used to produce a few optional 
backgrounds.

Ok, now Mikhael, I wait the cvs :o) can I lock the colors
components?

Olivier

Re: Colorset

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

On 03 Jul 2000 21:43:54 +0200, Olivier Chapuis wrote:
> 
> Mikhael Goikhman wrote:
> > 
> > * colors@ components. We should improve colorset list, probably add some
> >   items and move others. Application bar modules have only 3 colorsets, it
> >   is inacceptable, there should be 4-6. Olivier, do you want to do this?
> 
> Yes I am agree for doing this. But I need some suggestions:
> 
> 1. Do I use the new config command (Hilight)BorderColorset. This can
> fix some problems with icons and solve some conflicts between colors
> and windowlook. I think we must do that.

Yes, of course.

> 2. Which colorset you want to add/move? There are not 3 colorsets for
> app bar modules, there are in fact 5/6 (there are the tips colorset
> and there are the default/special modules colorset). Do you want a
> separated tips colorset and separated default/special colorsets (for
> the iconman background)?
> IMHO we can add a colorset for hilightning some of swallowed windows 
> and maybe an hilight colorset for "FvwmButtons".

Personally I don't use window list modules (but I will add them to migo
theme defaulting to off in 0.3.12), so I can't really decide on the number
of their colorsets. Alex said that he misses selected colorset(s) in his
modules. I think we should add 1-3 colorsets, probably there is no need
for a separate tips and/or individual background, but you will decide.
BTW, I support Tim's suggestion to unite all window list modules to one.

> 3. Do we need special colorsets for xres and gtkrc? Jos? 

xclock & xload have -hl & -hd colors, we can probably use them as fg & bg
of an additional colorset, defaulting to black/black?
For xmessage we use one colorset, I don't know whether this is enough.

> 4. We need to reserve some colorsets by saying which is the first
> colorset that can be used in colorset-extra.

Interesting thought. Maybe 40? :)

A similar thought. If a theme creator needs to use more colorsets (say in
modules), does she need to use the first unused number (25 for now, but
this number may be changed in new fvwm-themes versions) or we should
allocate the range for this too? Say, 35-39 - non-standard theme colorsets
in colors@, 40+ - user specific colorsets in colors-extra@.

> But the above, I think that we have enough colorset but If one
> want an other colorset just say it!

Regards,
Mikhael.

Name convention for module aliases

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

Olivier, you said that you prefer FvwmModuleSubName scheme for fvmw
modules. I agree, but probably a delimiter - dot, dash or anything else,
is better/needed between FvwmModule and SubName. So the aliases would be
FvwmEvent-Sound, FvwmForm-Talk, FvwmScript-ThemeCenter, FvwmPager-Single.

Should I move all fvwm-themes module aliases to this scheme?

Regards,
Mikhael.

Re: advanced dependancies

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

On 08 Jul 2000 06:27:52 +0200, Olivier Chapuis wrote:
> 
> Mikhael Goikhman wrote:
> > 
> > Ok, I would prefer not to implement temporarily solutions, and to spend
> > more time to find a better one, so 'needs' structure is auto-created from
> > 'requests'/'provides'/'extends'/'uses'.
> > 
> > I am not against to simplify our task, but 'needs' solution is probably
> > too hardcoding and duplicating. We should think more, I guess.
> 
> My problem is that I do not see how the "needs" can be computed from
> 'requests'/'provides'/'extends'/'uses'.

This is 'requires' not 'requests', and let call it 'reloads' not 'needs'.

  provides - provides a dependancy item
  requires - requires a dependancy item
  extends - like both requires AND provides, important for order
  uses - like requires, but should not be taken into account for order

Actually there are at least 2 variants of 'extends', one which requires
that another component 'provides' this item, and one without such
requirement (in this case 'extends' simply becomes 'provides').

Note, all these relations work with dependancy items, so a component may
provide, require, extend, use a given dependancy item, whereas your
'reloads' works with other components directly (a kind of hardcoding).

So here is a simplific algorithm:

  components getAllComponentsToBeReloaded(component) {
    foreach item (component.provides) {
      foreach component0 (allCurrentComponents) {
        if component0.requires(item)
          components += component0
      }
    }
    foreach component1 (components) {  # components before loop
      components += getAllComponentsToBeReloaded(component1)
    }
  }

> Typically, modules requires colors but when switching between two
> modules themes we do not need to reload colors. How do you solve this?

modules@ does not provide any dependancy item, so no other components
should be reloaded.

Note, if you don't want modules@ to be reloaded after changing colors@
replace one of its "requires" with "uses".

> Also, I think that we have to implement a kind of AD before the
> first public release of fvwm-themes. If the users see what happen
> at the present time when you do a background switch fvwm-themes
> will be not very popular?

My point is this can be done after 0.4.0, but probably before fvwm-2.4.

Regards,
Mikhael.

Re: Things to do before 0.4.0

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

On 08 Jul 2000 06:15:32 +0200, Olivier Chapuis wrote:
> 
> Mikhael Goikhman wrote:
> > 
> > On 03 Jul 2000 22:16:28 +0200, Olivier Chapuis wrote:
> > >
> > > * Do so that KDE and GNOME image path works (external-imagepath).
> > 
> > Why not just include the line in the settings/kde/system-menu/menu:
> > 
> >   ImagePath +:$KDEDIR/share/icons:$KDEDIR/share/apps/kappfinder/pics
> 
> Because we have 2 KDE menus (and maybe more in the future) and we do
> not want to add  2 times the previous path.

Ok. Still I think that this can be done after 0.4.0, and this line is a
good temporary solution.

> > > > * completing 'cde' theme. Jos?
> > 
> > I don't think the foreground can be improved, it is hardcoded to white
> > in the CDE color schemes (AFAIU), which have either 8 or 4 colors.
> 
> So we have to add other colors in CDE colors shemes. Also, we may
> change main so that the modules colors use more colors (taken from
> menus and active/inactive windows colors).
> I'am far from my solaris machine (for a long time) but I do not
> think that the fg color is fixed to white in mwm.

Ok, searching for +link:NorthernSky.dp produced two results in AltaVista:
  http://catalogs.hotnew.com/dt/share/palettes/
I am sure you can do better than CDE does, but will this be CDE then?

I always wanted to add 'scalar' property(ies) to components, in addition
to 'option' and 'choice', so that it can be freely chosen by a user,
unlike fixed options and choices. Some kind of a smart preprocessing.
Unfortunately fvwm itself does not support this and FvwmM4 is tricky.

  scalar+name=ForeGround color
  scalar.default=White
  scalar.current=Yellow
  # and probably 'type' too, like: string, int(1..4), color
  # 'type' may be used in GUI to restrict the scalar value input
  scalar.type=color

I don't say this is a good solution for cde foreground, this is just an
occasion to introduce the 'scalar' idea. :) Probably not for 0.4.0.

Regards,
Mikhael.

Re: Things to do before 0.4.0

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

Jos wrote:
> 
> > Optional:
> >
> > * better integration of fvwm-themes-xres
> >
> > * Creating fvwm-themes-gtk. Jos?
> >
> > * Creating fvwm-themes-qt. Someone?
> >
> 
> The next 2 weeks I'll be visiting the PIERS symposium in
> Boston. It's a dirty job, but sombody's got to do it.
>  After that I'll shurely finish the cde theme, and
> make a better fvwm-themes-xres (and for gtk and qt).
>

Good news! Olivier

Re: advanced dependancies

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

Mikhael Goikhman wrote:
> 
> Ok, I would prefer not to implement temporarily solutions, and to spend
> more time to find a better one, so 'needs' structure is auto-created from
> 'requests'/'provides'/'extends'/'uses'.
> 
> I am not against to simplify our task, but 'needs' solution is probably
> too hardcoding and duplicating. We should think more, I guess.
> 

My problem is that I do not see how the "needs" can be computed from
'requests'/'provides'/'extends'/'uses'.

Typically, modules requires colors but when switching between two
modules themes we do not need to reload colors. How do you solve this?

Also, I think that we have to implement a kind of AD before the
first public release of fvwm-themes. If the users see what happen
at the present time when you do a background switch fvwm-themes
will be not very popular?

Regards, Olivier

Re: Things to do before 0.4.0

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

Mikhael Goikhman wrote:
> 
> On 03 Jul 2000 22:16:28 +0200, Olivier Chapuis wrote:
> >
> > * Do so that KDE and GNOME image path works (external-imagepath).
> 
> Why not just include the line in the settings/kde/system-menu/menu:
> 
>   ImagePath +:$KDEDIR/share/icons:$KDEDIR/share/apps/kappfinder/pics
>

Because we have 2 KDE menus (and maybe more in the future) and we do
not want to add  2 times the previous path.

> > * Do so that the session support work again (need discussion).
> 
> I am not against a special session support, but doesn't it currently work
> automatically? We don't even need to define Session*Function's in the
> core, just document how it is possible to add them in the personal theme.
> Anyway I will accept any your solution if it is not very complicated.
>

This need a separated thread :)
 
> > Hum ... may be we have to add a .cfg command as
> > option.read=before/after
> 
> No problems, let it be .read-afterward=1 (default is as usual 0).
> You can change modules@ option files accordingly.
>

In the TODO list ...
 
> > > * desktop@, we may leave this for now as is, but in the future it should
> > >   be more formalized.
> >
> > Yes. Moreover, IMHO, we need only one desktop@ and an amelioration of
> > ScriptFvwmBaseConfig.
> 
> Maybe ScriptFvwmBaseConfig can accept an argument (save file), but by
> default create $FVWM_USERDIR/themes/personal/desktop? I really like an
> ability to specify another desktop file in theme. This is one of the
> features that we should ask users, what they prefer, global or local.
> I, as usual, like a local solution. :) So it is possible to define several
> desktop configurations (one per theme) and switch between them.
>

OK
 
> > > * completing 'cde' theme. Jos?
> >
> > Yes it will be good to finish this already cool theme.
> > I think that the most important thing is to fix the fg colorset
> > and to improve the modules one. Of course a window buttons component
> > and a modules theme will be cool too.
> 
>   http://www.xs4all.nl/~josvanr/pl/DefaultCDE.jpg
>   http://www.xs4all.nl/~josvanr/pl/Cinnamon.jpg
> 
> I don't think the foreground can be improved, it is hardcoded to white
> in the CDE color schemes (AFAIU), which have either 8 or 4 colors.

So we have to add other colors in CDE colors shemes. Also, we may
change main so that the modules colors use more colors (taken from
menus and active/inactive windows colors).
I'am far from my solaris machine (for a long time) but I do not
think that the fg color is fixed to white in mwm.

> I hope Jos will tell us where he got these color schemes from. :-)
>

I think that now mwm (and solaris) is more or less "open" ? 

Regards, Olivier

Re: Things to do before 0.4.0

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

On 03 Jul 2000 22:16:28 +0200, Olivier Chapuis wrote:
> 
> * Do so that KDE and GNOME image path works (external-imagepath).

Why not just include the line in the settings/kde/system-menu/menu:

  ImagePath +:$KDEDIR/share/icons:$KDEDIR/share/apps/kappfinder/pics

> * Do so that the session support work again (need discussion).

I am not against a special session support, but doesn't it currently work
automatically? We don't even need to define Session*Function's in the
core, just document how it is possible to add them in the personal theme.
Anyway I will accept any your solution if it is not very complicated.

> Hum ... may be we have to add a .cfg command as 
> option.read=before/after

No problems, let it be .read-afterward=1 (default is as usual 0).
You can change modules@ option files accordingly.

> > * desktop@, we may leave this for now as is, but in the future it should
> >   be more formalized.
> 
> Yes. Moreover, IMHO, we need only one desktop@ and an amelioration of
> ScriptFvwmBaseConfig.

Maybe ScriptFvwmBaseConfig can accept an argument (save file), but by
default create $FVWM_USERDIR/themes/personal/desktop? I really like an
ability to specify another desktop file in theme. This is one of the
features that we should ask users, what they prefer, global or local.
I, as usual, like a local solution. :) So it is possible to define several
desktop configurations (one per theme) and switch between them.

> > * completing 'cde' theme. Jos?
> 
> Yes it will be good to finish this already cool theme. 
> I think that the most important thing is to fix the fg colorset 
> and to improve the modules one. Of course a window buttons component
> and a modules theme will be cool too.

  http://www.xs4all.nl/~josvanr/pl/DefaultCDE.jpg
  http://www.xs4all.nl/~josvanr/pl/Cinnamon.jpg

I don't think the foreground can be improved, it is hardcoded to white
in the CDE color schemes (AFAIU), which have either 8 or 4 colors.
I hope Jos will tell us where he got these color schemes from. :-)

Regards,
Mikhael.

Re: advanced dependancies

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

On 04 Jul 2000 09:57:29 +0200, Olivier Chapuis wrote:
> 
> Maybe we can try now to do an elementary things. 
> We can do something at the files level only + some kind
> of start+stop functions (for modules themes we may want to have 
> some different start+stop functions, e.g., function which just
> restart the modules (with swallowed apps)).
> We can introduce new .cfg commands as:
> 
> needed.read+=a_component
> needed.start-stop+=Name

It should be colons, not dots. Here is the meaning [it is easy :-)]:

  '+' stands for a hash key of the next element in the hash array
  '.' stands for a hash key of the current element in the hash array
  ':' stands for a hash key of the specified hash
  '=' stands for a string value
  '+=' stands for an array's next/first string value

I can replace dot and colon meanings if it helps (not much IMHO).

Ok, I would prefer not to implement temporarily solutions, and to spend
more time to find a better one, so 'needs' structure is auto-created from
'requests'/'provides'/'extends'/'uses'.

I am not against to simplify our task, but 'needs' solution is probably
too hardcoding and duplicating. We should think more, I guess.

> It seems to me that if you do not use "drop this component" there are
> almost no "conflicts" in fvwm-themes.

This is only if you use your .cfg without conflicts. Conflicts are
possible by CCDS definition, they should be detected, but maybe not now.

Regards,
Mikhael.

Re: version 0.3.10

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

Mikhael Goikhman wrote:
> 
> On 03 Jul 2000 23:24:03 +0200, Olivier Chapuis wrote:
> >
> > Version 0.3.10 is available at:
> 
> Ok, continue with this. I will answer other messages later, but, I think,
> you know what I would like and what no. F.e. I don't like moving settings
> one level up, because this breaks a nice themes & components hierarchy.
> And I like you to discuss first any non trivial changes in CCDS.
> 

As you can see settings is not promoted, but a component with sub 
components without the global .cfg command setted is put at the same 
level than component with options :o)
Note that we can add an intermediate level in the current menu:

"global" compnents with sub components
--
compnents with sub components
--
components with options
--
the others components

Olivier

Re: version 0.3.10

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

On 03 Jul 2000 23:24:03 +0200, Olivier Chapuis wrote:
> 
> Version 0.3.10 is available at:

Ok, continue with this. I will answer other messages later, but, I think,
you know what I would like and what no. F.e. I don't like moving settings
one level up, because this breaks a nice themes & components hierarchy.
And I like you to discuss first any non trivial changes in CCDS.

I did some tests (not enough) to identify lock problems. Here are results.
When I load modules@ with Swallowed FvwmScript, this locks XFree 4.0.0.
I have tested fvwm[-themes] from the remote machine with XFree 3.3.6 and
there are no locks. But on that machine I have fvwm's core dump on every
FuncFvwmThemesConfigAndUpdate (change theme/component/option), which I
have no on my machine. I should have more free time to investigate this.
xmessage in XFree 4.0.0 has the size bug, so the message is invisible...

Regards,
Mikhael.

Re: advanced dependancies

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

Mikhael Goikhman wrote:
> 
> There are 2 major things about CCDS that could be implemented somewhen.
> 
> The first is evaluating the minimal dependencies and applying only them.
> This should reduce a time of changing an option or choice, or even loading
> another component(s). There are 3 big problems with this. 1) It's difficult
> to implement, the exact list of each fvwm element dependancies is needed,
> and probably some mathematical theory too, 2) It will only guarantee that
> everything will be update if exact list of dependancies for each component
> is defined (may be long). 3) It may screw user themes if a user adds some
> fvwm commands, but don't specify dependancies for them. Well, to be even
> more pessimistic 4) the algorithm can take more time than the restart. :-)
> Ok, let us be optimists, we should try to implement this anyway.
> But probably not now.
>

Maybe we can try now to do an elementary things. 
We can do something at the files level only + some kind
of start+stop functions (for modules themes we may want to have 
some different start+stop functions, e.g., function which just
restart the modules (with swallowed apps)).
We can introduce new .cfg commands as:

needed.read+=a_component
needed.start-stop+=Name

E.g., for colors:

needed.read+=buttons
needed.start-stop+=ModulesWithSwallow

Then, during theme switching theme-rc-2 is build as before and
a theme-rc-3 is also build as minimal as possible. The themes-rc-3
is build using the "needed." stuff and the read order is taken
from themes-rc-2.
Essentially themes-rc-3 is a subset of themes-rc-2:

For a colors switching it maybe as themes-rc-2 for menu and image
path but we will just have:

DestroyFunc FuncFvwmStartAllHooks
AddToFunc   FuncFvwmStartAllHooks
+ I FuncFvwmStartModulesWithSwallow

DestroyFunc FuncFvwmStopAllHooks
AddToFunc   FuncFvwmStopAllHooks
+ I FuncFvwmStopModulesWithSwallow

Read ...colors
Read ...buttons

Then, we replace read themes-rc-2 by themes-rc-3 in  FuncFvwmThemesConfigAndUpdate. Also, a thing that it is
maybe not very difficult to implement is to have only the
menus that have changed in themes-rc-3 (just a "diff"). 

I do not say that this is easy to implement, but for a one
component themes switching this is probably easy (almost hard
coded). If more that one component is changed at one time
some (may be tricky) computations have to be done: roughly 
speaking the "needed.a_comp" command will be forgotten if
"a_comp" have to be loaded.
But, with our current themes manager (menu), implementation 
of such a thing only for a one component switch will be very
appreciated by the end users.


> The second thing is determining conflicts in the current theme (and) when
> loading/dropping components. It may be easier to implement, but I would
> add some features, which make it much less easier. 1) When conflict on
> dropping or loading, provide a user interaction (via xmessage) specifying
> which component created conflict and possibility to drop it if possible.
> 2) Support already existing 'suggests' dependancy type, so when conflict
> is created check an option to also drop/load the suggested compnents.
> 3) Enable to work even with conflicts, what to do in this case?
> 4) If we implement the ability to add dependancies for individual choices
> (maybe not needed) the conflicts may occur even when changing choices.
>

I think that this is less important (than the above). It seems to me that 
if you do not use "drop this component" there are almost no "conflicts" in
fvwm-themes. Ok, some themes combinaisons are not very pretty, but this
is not a problem (and someone can like an horrible themes combinaison!).

> These are only very basic thoughts, more thinking is needed.
> Of course, the easiest solution here is to hard-code possible components
> and their formats and not deal with dependancies at all, but then we lose
> the ability to add really new components (xresources, wheel-mouse, more
> dynamical menus, joistick support, auto-shading, hehe). With CCDS they are
> easy to be added without changing fvwm-themes scripts at all.

I think that with the "elementary file dependency" it will be possible
to really add new components (of course the *.cfg may have to be changed
in a lot of place).

Regards, Olivier

version 0.3.10

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

Hello all,
Version 0.3.10 is available at:

  https://sourceforge.net/project/?group_id=1738

I've "finished" modules themes "settings/options".
I mostly use options (only default and olicha use
sub component). I create and edit a lot of files, 
so there are may be some bugs and sometime the 
names are not well chosen ...
Note that I've added two .cfg commands global (for
component which contains sub component) and popup
(for options). The difference is visible in the
Theme Management Menu. The changes in fvwm-themes-config
are minor.
Also, I've tried to improve awol FvwmButtons, in 
particular there are now two such Buttons (via the 
options). One with xdaliclock and kLo_mix and the other 
one with some "fvwm applets".
Finally, FvwmTheme is started in themes-rc-2 (this
may change in the future).

Olivier