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

[jfm2@club-internet.fr]

   Delivered-To: jfm@sidney.remcomp.fr
   X-Authentication-Warning: belegost.mit.edu: majordomo set sender to owner-seul-dev-install@seul.mit.edu using -f
   Date: Fri, 10 Oct 1997 16:17:35 +0100
   From: Kai Wetzel <k.wetzel@welfen-netz.com>
   Organization: Free Software Union (http://www.fslu.org)
   X-Mailer: Mozilla 4.01 [en] (Win95; I)
   MIME-Version: 1.0
   X-Priority: 3 (Normal)
   References: <343DABF5.410A@mho.net>
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit
   X-MDaemon-Deliver-To: seul-dev-install@belegost.mit.edu
   Sender: owner-seul-dev-install@belegost.mit.edu
   X-UIDL: bf1ddb2887781f5f7e7922df53a2a8b0

   John Munoz wrote:
   [...]
   > There are many positive features in the W95 registry.

   > A registry inplemented with flat files will be *VERY* bad anytime
   > more than one process needs to access it, and don't try to tell me that
   > the FS handles locking or relational integrity well.  The problem with a
   > DB is that your OS becomes dependent on the operation of the DB( I think
   > this is obvious and the main reason against it), so the question is "can
   > we implement a bombproof DB that will be one of the mandatory OS
   > components like the scheduler or the root shell?" A second option might
   > be to design it so that in single user mode there will be no concurrency
   > issues, have the application handle relational integrety, and allow
   > certain processes text mode access, untill we switch info "full db
   > working, multi-user mode".  Might be tricky...

   When I thought abou this isuue the last time, I came to
   the preliminary conclusion that it's the best idea to store
   the master preference settings in editable text files (*.rc)
   and have a "db" process which builds up a cached copy from
   this in memory.  Applications would handle read/write access
   through this "db" process.  I don't know whether it's a good
   idea or not, though ;)

   > I was looking at window managers.  AfterStep, Enlightenment, and K all
   > caught my eye.

   While I still use FVWM2 ;) I think WindowMaker is the nicest
   (if we consider e somewhat 'special') and the one with the
   fastest development cycle currently.  WindowMaker isn't stable
   enouhg for a "default" WM but I have the impression that it'll
   be there when SEUL ships.

   > Olvwm was not the coolest, but not bad looking.

   This waas my first impression of X and it was a very
   nice impression.  I think some anti-aliasing of the
   round menu and button edges as well as a nice raytraced
   pin would have been a significant improvement, though.

   [...]
   > What we really need to do is list our requirements.

   E.g. looking at one of them and ask "What's lacking ?"

   I think it would be cool to provide a default WM (candidates
   would IMO be: WindowMaker, AfterStep, and FVWM95) as well
   as offer quite a lot of auto-configured alternatives as we
   proceed.  I think switching WMs on the fly is one of the
   cool features of X which people who like to try new stuff
   will like.  think of the success of the '95 themes :)

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.  Redhat's FVWM95 comes with m4 scripts
than build the menu entries based on what is installed so menu entries
don't point on empty air.  I think than there is a version of these
scripts for FVWM2.  The LST/Caldera distribution uses different tricks
but manages to do the same thing with plain FVWM.  Afterstep or
Windowmaker don't have a builtin pre-processing capability like the
FVWMs, neither has OpenLook and in all cases you will have to write
the scripts.  That rules them out.

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.

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

-- 
			Jean Francois Martinez

==================== The Linux.  Use the Linux, Luke! =======================