Re: I think It was Peter Luka's install abstraction proposal...

[Kai Wetzel <k.wetzel@welfen-netz.com>]

[Moved it to UI now where this discussion was continued]

jfm2@club-internet.fr wrote:
[...]
> A WindowManager for the public SEUL is aiming has to have three
> qualities listed in order decreasing order of importance.
> 
> 1) It must be able to update its menus automatically.  There would be
> nothing worse than having a beginner clicking on a menu entry and
> seeing than nothing happens.
[...]
> Afterstep or Windowmaker don't have a builtin pre-processing
> capability like the FVWMs, [...].  That rules them out.

Well, I don't agree here.

First, I'm a FVWM2 user, and I voted for it on the WM voting
page, too ;)  It's the perfect WM for the programmer within me.
I switched off those stupid little icons, and if it weren't for
the time wasting on config files, I'd config it not to show those
superfluous menus, the _ugly_ and unintelligent Goodstuff for me.
It doesn't show that wasteful "FVWM" at the beginning and Goodstuff
only has that pager (which is too small because there are no
icons) and the "NeXT" clock :O)

Now while I couldn't be happier with it, I don't think it's
the best WM for the end-user.  If I'd switch to end-user mode,
I'd rather prefer something good-looking, elegant WM rather then
something which looks like FVWM or FVWM2 :)

Second, we don't need the WM _now_.  Especially WindowMaker's
state progresses _rapidly_.  So it may very well have the
requested features one or two months from now.
(The TODO file says a Pager is planned AFAIK, and somebody talked
about some configuration file format in the WMaker context.)

_If_ WindowMaker isn't in a usable state when we want to distribute
SEUL, we can still picke another one, e.g. FVWM2.

IMHO we should have one default WM, but also _try_ to
include some other popular WMs which also auto-update
the "menus", etc.  So we don't need only _one_ manager
which has this feature and a couple of others in the
"you're on your own"-section =-)

Furthermore, we should ask "What schemes are used" and
"Are they good ?".  E.g. SuSE takes about 20 second after
each run of SuSEconfig to update some strange (and ugly)
files, including the WM menu support stuff.

So basically, what does this mean ?  IMO there are
some WMs which could become the default WM:
WindowMaker, FVWM2, FVWM-95, and AfterStep.  While I
assume WindowMaker will be the best bet two months
from now, of course we must not rely on this.  The
final decision should not be done now.  Furthermore,
we should be open for new WMs and WM-modifications and
possibly change the default WM in the future.

Also, there are some WMs which should be supported
by the auto-update feature in SEUL:
WindowMaker, FVWM2, FVWM, FVWM-2, AfterStep, KDE-WM.

We should also offer e, but I'd rather call it a cool
toy to show those lame '95 users rather then something
for daily work, so auto-menu support wouldn't be essential.

In addition, the following WMs could become usable enough
to be included in the list of "supported" WMs:
MLVWM, QVWM, and maybe some others I don't know much about ;)

*********************************************************
I think we should:

- List advantages and disadvantages of WMs
- Ask the WM maintainers what they intend to do about this.
- discuss how the auto-menu support should work, optimally.
- See how we can make a fair selection of WMs be usable to
  SEUL users, and after careful consideration decide which WM
  _must_ be usable in the SEUL context since beeing our
  "default" WM.
*********************************************************

> 2) A configurator.  If you want to change the Look and feel of your
> desktop you should be able to do it without hacking.  Afterstep has
> one.  I don't know one for the FVWMs.  WindowMaker and OLVM don't have
> one.  Notice than a configurator is LESS important than automatic
> upgrading of menus.

OLVWM ;)  WindowMaker does have the drag-n-drop button bar,
and I'm pretty confident they'll add some of these features
in the future.  IMO it's just the most _promising_ WM, so
we should only use another one _if_ they don't deliver in time.

> 3) Look nice.  That rules out TWM.  :-)

;)

Best regards,
kai