Re: CCDS

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

On 24 Dec 2000 12:41:12 +0100, Olivier Chapuis wrote:
> 
> I think we must work on CCDS now. Mikhael do you have any plan
> about this?

My plan is to work on wm-icons first. :)
Both fvwm-menu scripts and fvwm-themes depend on it.
We may work on the minimal reload (MR) concurrently too.

> I think a little bit about this. Here a few reflections:
> 
> 1. I think that the *-extra components need to have a special
> dependence rule: they should be loaded *immediatly* after its
> corresponding (*) component (and we may want to add an cfg command
> to force the extra component to be loaded just before its
> corresponding component).

Maybe. But if we implement extends as it was intended, this may be enough.
Extra components do not really should go immediately after. Maybe it looks
better for human when they go together, but not really needed.

> 2. It will be great to have component of the form
> theme-component-extra loaded if selected and if
> component@theme is used.

Do you mean load (first choosing) or minimal reload? Please give example.

> Also it will be great to have extra component for the settings.

For every sub-component? Teoretically this may help. but practically it
would be better to add a new setting or move this subcomponent outside of
settings@ if it needs more customization.

> 3. At the present time we have "requires/provides" and "follows"
> dependency rules. These rules allow to build the "all" config
> in the good order. We want to do more: (a) reload only the
> needed components during theme switch (b) check dependence
> consistency and either automatically load/drop some components
> or generate an error messages if some inconsistency happen.
> 
> I think that the requires/provides rule are goods and that we
> may want to only have this rule (follows is just a kind of
> alias). However, I think that there are not enough precise:
> if a component A provides foo and B requires foo, there
> are a lot of different possible reasons for this dependence:
> 
> - (order): A must be loaded before B (order=1) or B must be
>            loaded before (order=-1, a priorie this never 
>            happen but ....). We can have also order=+/-2 for
>            immediately after/before. 
> 
> - (existence): So that B can be used A must be present 
>              (exist=1)
> 
> - (needs): if B have to be reload, A have to be reloaded too
>            (needs=1) or if A have to be loaded B have to be
>             reloaded (needs=2), or both (needs=3).
> 
> - maybe others ...?

Originally I though about 'extends' (which is like both 'requires' and
'provides'); 'provides-extends' (which becomes 'provides' if there is no
other 'provides', or 'extends' otherwise; and 'uses' (requires existence,
but order is not important unlike 'requires' and 'extends', it also does
not participate in MR).

Probably there are more cases, but I can't think about any.

> Of course we may have to found better name than order, needs and exists.
> Also some hints can be given for partial load reload of a component
> 
> So in cfg files we have
> 
> provides+name=foo                  # maybe id in the place of name?
> provides.read-command=read blabla  # default is the component read command
> provides.start-stop=Xyz            # default to the component start-stop
> 
> ....
> 
> requires+name=foo
> requires.order=a # default to nothing or 1?
> requires.exist=b # default to nothing (0)
> requires.needs=c # default to nothing
> requires.read-command=read pouf # default is the component read command
> requires.start-stop=Zyx # default to the component start-stop

I am not sure whether 2 dependancy rules with many parameters is better
than several dependancy rules without parameters.

I think we may suppose that load and reload is the same, i.e. there is no
need in individual 'read-command' or 'start-stop' (which I don't quite
understand anyway without example).

> 4. Implementation. The order stuff is already perfectly implemented. I'm
> really concerned about "minimal reloading".

[closure definition skipped]

I think we should only work with directional graphs, it is in fact not any
harder than non-directional ones.

I see this similarly to you. There are 2 independant parts.

1) Evaluate a set of components needed for MR.
2) Implement MR using themes-rc-3 or whatever.

We may temporarily implement (1) by hardcoding a hash of C => MR(C),
and than just conjunctArrays() of components.

After implementing (2) we may return to (1), implementing this using CCDS.
Then we will see better which rules are needed for MR.

> we have to rebuild
> the themes-rc-2 file and need to update the theme management
> menu but we surely not have to read themes-rc-2. A simple solution
> is to add themes-menu. There is also a problem with the stop function.
> Finally, I think we have to add a global variable to ft-config,
> ENABLE_CCDS, set to 0 by default and the "new" code will apply if it
> is set 1.

I don't think we need menus-themes@, but we will see.

It would be better to turn MR on and off dynamically using something like
--set-minimal-reload and storing this boolean in _core@current component.

Regards,
Mikhael.