Subject: Re[2]: gui install system
To: None <a.mcmurry1@physics.oxford.ac.uk>
From: None <nick.maniscalco@alfalaval.com>
List: current-users
Date: 07/09/1998 15:42:45
    =20


______________________________ Reply Separator ____________________________=
_____
Subject: Re: gui install system
Author:  PC:a=2Emcmurry1@physics=2Eoxford=2Eac=2Euk at INTERNETALFALAVAL
Date:    1998-07-09 15:15


    =20
>      Anyone interested the option of a graphical install?
>      The option of a graphical install would exist only for cdrom based=20
>      installations possibly=2E
    =20
>      Anyway if people are interested in this I would like to know=2E  As=20=
for=20
>      the gui I think gtk would make a nice widget set for such a task=2E=20=
=20
>      Opinions on this?
    =20
For this to be as useful as possible, the install program should be=20
based on a UI layer that can either talk to an X widget set or a=20
curses-based widget set=2E Then whether you choose text or X based=20
installation, you get the same thing=2E
    =20
     Are you talking about having one binary for both text and X installs?
    =20
This will avoid having two different installation processes:
    =20
A) One that is easy to use, and nice looking, but requires a large=20
code base to be available and only works with suitable display=20
hardware for X to run=2E It will probably have to assume things about=20
the video system that might live up to NetBSD's portability goals=2E
    =20
     Yep, good portability on a gui installer is not going to happen=2E  X=20
     servers aren't well supported on alpha at all=2E  I would almost see=20
     this as a primary effort for i386 as much as I hate to say it=2E
    =20
B) The old sh based installation system=2E
    =20
The multi-interface installer would work on ALL systems (OK, not quite=20
all, as someone might want to install on a system with an old teletype=20
as a console)=2E It would not have to worry about getting X running from=20
the start, but could give the user a chance to change to the X version=20
of the installer, once the X installation step had been taken=2E
    =20
     The plan all along was to have the user prompted (at a text console)=20
     as to which type of install they would like to persue (an X based one=20
     or a text based one)
    =20
The same interface might also be useful for other things=2E I noticed=20
someone wishing for such an interface for the kernel config front end=20
system=2E A system administration tool could also use the system=2E In=20
fact if the installer was written in a suitably modular fasion, then=20
several of the modules would be useful parts of the admin tool=2E=20
Modular code would also make it easy for any machine-dependant=20
installation steps to be easily included=2E
    =20
Andrew
    =20
     Yes, a nice set of tools (gui and text) for kernel, system, printer,=20
     daemon, fs, and user configuration etc, this is all wanted and needed=20
     in a way=2E  This is a major task and it would be nice to have somethi=
ng=20
     like this have a seemlessly integrated interface that is just like the=
=20
     installer's interface=2E  I am not sure however that these things will=
=20
     get done any time soon=2E  I do feel that a gui based install would ha=
ve=20
     a better chance of getting under way=2E
    =20
     As for the basis for the gui install (and text install as well)  The=20
     idea of building a generic library of widgets an and functions with=20
     console based and X based equivalents may proove to be a large task=2E=
 =20
     I think it would be great to write one program and then just use it as=
=20
     either a gui based app or a text console app=2E