Re: SEUL: Re: Berlin is openning up! YES!!!!!

[jfm2@club-internet.fr]

   Delivered-To: jfm@sidney.remcomp.fr
   X-Authentication-Warning: mail.txcc.net: majordomo set sender to owner-seul-project using -f
   From: Loren S Osborn <lso8219@cs.rit.edu>
   Date: Mon, 11 Aug 1997 19:50:32 -0400 (EDT)

   >    >I think we should find
   >    >(or patch togeather) a "GUI" (used loosley) toolkit that would work WITH THE
   >    >*SAME* API under multiple enviornments.  Enviornments that come to mind are
   >    >X, MGR, Berlin, GGI, SVGAlib, and ncurses. I think that support for DOS &
   >    >Win* would help us build an installer with the same basic Look-n-feel.
   >    >
   >    >This way we give the users a choice  as to how THEY want to use our software.
   >    >
   >    >comments?
   > 
   >    this is exactly what i'm thinking right now.
   >    objections to this plan...?
   >    thoughts on feasibility?
   > 
   > First: Probably unfeasible.  These graphic environments have wildly
   > different programming interfaces.  And of course if you want to let
   > them true freedom of choice then you have to port every 

   Agreed, I don't think it's likely to find such a thing off the shelf,
   It may be something we need to write. (For SEUL we would probably develop

How many man years will you need for your API, and how many people
will participate?  Now divide to get the number of years.  Sorry but
the goal of SEUL first edition is NOT developping APIs.  If we start
going in every direction then let rename that project to SEUL 97, 2097
of course.  :-).


   an API, and only implement the versions we needed i.e. build seul_x_gui_api
   on top of LessTif, but Leave seul_mgr_gui_api unimplemented.  (I haven't any
   experience with motif/LessTif... just used as an example).

There are many areas where existing distributions can be significanly
improved with little effort.  It seems me absurd to start a
development using huge programming resources just to support a dead
tool (MGR), an experimental one without apps (Berlin), a toy
(SVGAlib), and something people will hate at first sight (ncurses).

   > Second: I have used MGR.  Not bad.  Limited respective to X.  A lot
   > less resource intensive but that was a factor in 386 with 4 Megs of
   > memory.  Few software for it.  As far as I know it is virtually dead.

   I must admit I haven't used MGR.  I know it had a very simple design, and
   was really scaled back relative to X, but much faster.  The beauty of Linux
   is it will run (almost) equally well on a '386 as a Pentium II.  that  was
   my main reason for mentioning MGR.

MGR has no apps.  Point.  And I don't think it is actively developped,
or getting new apps.


   > THird: SVGAlib is very good for games because it is very fast.  But it
   > is a BIG security hole.  Every program must run setuid root.  Base
   > software on SVGA lib and we will soon have a virus invasion: SVGALIB
   > games are an ideal vehicle for them.  So it is the first thing I
   > uninstall.  Furthermore there are a lot of cards supported by X and
   > not by SVGAlib, specially modern cards.

   I am aware of this... I don't like it...I REALLY prefer GGI (which will be
   able to emulate SVGAlib securely), but SVGAlib IS availible.  (For SEUL I
   recommend that any SVGAlib program bring up all sorts of warnings before being
   enabled for normal use for the above reasons, but it would provide easy 
   access to graphics before X is configured.

Configuring SVGAlib is NOT easier than X.  And you don't have tools
for doing it like with X.  Yes you will say than we can develop one.
Of course but people doing it will not be available for doing things
more useful.

And besides games what software is available for SVGAlib?  The only
soft of note I know is ZGV.

SVGAlib provides graphics, not windowing, no menus, no cut and paste
between windows.

To my knowledge SVGAlib does not support the Mystique.  In fact I
don't remember last time I saw a new release of SVGAlib with support
for new cards.


  > Fourth: ncurses.  Are you kidding?  People are used to graphics, the
   > kind of people SEUL is aiming to strongly dislike character based
   > tools.  You can base config tools on it in case they have problems
   > with X but few people will accept curses for day to day work.

   "Help! my video card burned out.. all I could scrounge up is a CGA card..."
   I don't wan't to fource SEUL users without another option to use an
   unfamiliar command line enviornment, when most GUI widgets are easy to 
   represent with a character display.  Most users want some sort of safety
   net that doesn't scare the $%^&*& out of them.

End users are afraid to open their computer.  And they don't have CGA
cards.  A person having one has used computers for more than ten years
and can assemble a PC with bandaged eyes.  When normal people burn
their video card: a) they put their PCs into the hands of a service
man or b) they buy another card.  You can get an S3 for 50$.  Only
hackers will try to use a CGA card.  And not even hackers will use a
CGA card for an extended period of time.

   > FIFTH AND MAIN: You forget the goals of SEUL: Simple End User Linux.
   > You are not making a hackers distribution.  When planning for end
   > users YOU must make choose what is good for them: if you force them to
   > make choices, they will choose wrong and worse they will be confused,
   > and when confused they will find SEUL is not simple at all.  Choose
   > the best, give them only one possibility and try to make things
   > install automatically.  That is the lemma when dealing with end users.

   I think what SEUL isn't quite grasping is that SEULs job should be to make
   the "grade" of the learning curve much more shallow.  Not to reduce the
   "altitude" of the final "goal".  I'm not saying that 90% or even 10% of
   SEUL users are going to tweak their system and learn to become a power user.
   I'm saying that SEUL should allow you to work right away, but also to 
   experiment right away.  I'm suggestion SEUL *SHOULD* have very well
   established defaults, and a very consistant UI, but that it *SHOULD NOT*
   constrict the user to that, nor should the SEUL utilities abandon him/her
   if they decide to venture beyond X.  SEUL will attract your average point-n-
   click secretery, but it will also attract Windows hackers (yes there are such
   things) that haven't felt comfortable enough to try Linux.

The problem is than you are willing to lead those beginners to higher
lands than those visted by most hackers.  Most hackers will never
bother with MGR or Berlin.


   I want to see SEUL become both a way for technophobes to be comfortable using
   Linux/Unix, and a tool to learn to use Linux/Unix.  If we ignore the underlying
   flexibility, then Linux looses it's magic and appeal.

I said than most of time it will be to us to choose what is good for
the user.  Now imagine this: a person without Unix background.
Perhaps he is a programmer but he does not know anything about UNIX
editors.  Make him choose: Do you want VI, Emacs, Xemacs or Nedit?

He will give a random answer.  This is a mild case.  There are other
things the person will begin to feel uneasy because he will fear than
his choices will break his system.  And he knows he is making bad
choices when giving random answers.

-- 
			Jean Francois Martinez

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

----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------