[gentoo-dev] GUi installer brainstorm

[gentoo-dev] GUi installer brainstorm

[Geert Bevin]

Hi all,

I post a log of what Hallski and I have been talking about on irc, 
please add you comments.

<Bevin>   what did you already imagine in terms of GUI tools for gentoo? 
installer, package manager, admin tools, ... ?
<Hallski> not much really, the problem for packagemanager and admin 
tools would be which toolkit (or mulitple)
<Hallski> about the installer I would really like to have it so that 
users see what happends and take an active part in it
<Hallski> since it's very educating
<Hallski> *puh*
<Bevin>   that's also how I see the installer, more like a guide with 
blanks to fill in and commandlines to choose from, not something that 
tries to detect and do everything automatically
<Hallski> yes
<Hallski> well, some kind of hardware detection would be nice though
<Bevin>   I saw this kinda like a frame based approach, left frame with 
details about the current step and required data with links to 
alternative paths
<Hallski> that takes you through setting the different parts up
<Bevin>   right frame almost exactly as a normal shell, but i which 
commands get auto-pasted from the left frame
<Bevin>   didn't the new developer was going to work on auto-detection 
of hadrware
<Hallski> yes, I think it would be rather nice to have that, so it can 
autoinsert commands
<Hallski> oh, nice
<Bevin>   so it's a kinda like an interactive and guiding documentation
<Hallski> yes
<Bevin>   with no need to print out the installation manual before 
installing
<Hallski> it could even be so easy to just have a html-browser that 
shows the installation
<Hallski> but it would be nicer to have some more interactive aproach
<Hallski> like, when you excecute the command in the shell-prompt it 
takes you to the next step in the guide-part
<Hallski> wonder if that would be easy to do :)
<Bevin>   exactly my thoughts :-)
<Hallski> you can have like Next-button
<Bevin>   or even a real website-like navigation with possible 
installation actions tat still have to be done
<Bevin>   the most important part will in fact be to write a good 
'story-board'
<Hallski> agree
<Bevin>   where every step in clear explanantions and all 'follow-ups' 
needed
<Hallski> yes
<Bevin>   guess I'll get onto that storyboard first then
<Bevin>   and post it to the mailinglist as soon I have a first draft
<Hallski> yes, that would be great
<Bevin>   about the toolkit, I like to use qt for it for several reasons
<Hallski> ok
<Bevin>   1. everything possibly needed is available in 1 lib
<Hallski> I don't want to hack QT but it's ok if you do it :)
<Bevin>   2. it officially supports operating without X
<Bevin>   first however I'd like to try to make a boot cd that contains 
the qt-embedded lib and an example app, as a proff of concept
<Bevin>   do you know if drobbins has 'portagified' his build cd 
creation scripts already?
<Hallski> well, I think I can look a little at QT, but I'd rather not 
spend to much time learning about it
<Hallski> dunno
<Bevin>   helping out with the storyboard will be most of the work
<Hallski> yes

Re: [gentoo-dev] GUi installer brainstorm

[Taras Glek]

Why is a gui needed to do an installer? One could do a ncurses based
console "gui" that would be just as useful, but wouldn't depend on shaky
things like framebuffer(not all cards do vesa, some do it better/worse
than others), imho using a console interface, sort of like the one in
dos borland ides would be more than sufficient.
 
On Sun, 2002-01-06 at 14:54, Geert Bevin wrote:
> Hi all,
> 
> I post a log of what Hallski and I have been talking about on irc, 
> please add you comments.
> 
> <Bevin>   what did you already imagine in terms of GUI tools for gentoo? 
> installer, package manager, admin tools, ... ?
> <Hallski> not much really, the problem for packagemanager and admin 
> tools would be which toolkit (or mulitple)
> <Hallski> about the installer I would really like to have it so that 
> users see what happends and take an active part in it
> <Hallski> since it's very educating
> <Hallski> *puh*
> <Bevin>   that's also how I see the installer, more like a guide with 
> blanks to fill in and commandlines to choose from, not something that 
> tries to detect and do everything automatically
> <Hallski> yes
> <Hallski> well, some kind of hardware detection would be nice though
> <Bevin>   I saw this kinda like a frame based approach, left frame with 
> details about the current step and required data with links to 
> alternative paths
> <Hallski> that takes you through setting the different parts up
> <Bevin>   right frame almost exactly as a normal shell, but i which 
> commands get auto-pasted from the left frame
> <Bevin>   didn't the new developer was going to work on auto-detection 
> of hadrware
> <Hallski> yes, I think it would be rather nice to have that, so it can 
> autoinsert commands
> <Hallski> oh, nice
> <Bevin>   so it's a kinda like an interactive and guiding documentation
> <Hallski> yes
> <Bevin>   with no need to print out the installation manual before 
> installing
> <Hallski> it could even be so easy to just have a html-browser that 
> shows the installation
> <Hallski> but it would be nicer to have some more interactive aproach
> <Hallski> like, when you excecute the command in the shell-prompt it 
> takes you to the next step in the guide-part
> <Hallski> wonder if that would be easy to do :)
> <Bevin>   exactly my thoughts :-)
> <Hallski> you can have like Next-button
> <Bevin>   or even a real website-like navigation with possible 
> installation actions tat still have to be done
> <Bevin>   the most important part will in fact be to write a good 
> 'story-board'
> <Hallski> agree
> <Bevin>   where every step in clear explanantions and all 'follow-ups' 
> needed
> <Hallski> yes
> <Bevin>   guess I'll get onto that storyboard first then
> <Bevin>   and post it to the mailinglist as soon I have a first draft
> <Hallski> yes, that would be great
> <Bevin>   about the toolkit, I like to use qt for it for several reasons
> <Hallski> ok
> <Bevin>   1. everything possibly needed is available in 1 lib
> <Hallski> I don't want to hack QT but it's ok if you do it :)
> <Bevin>   2. it officially supports operating without X
> <Bevin>   first however I'd like to try to make a boot cd that contains 
> the qt-embedded lib and an example app, as a proff of concept
> <Bevin>   do you know if drobbins has 'portagified' his build cd 
> creation scripts already?
> <Hallski> well, I think I can look a little at QT, but I'd rather not 
> spend to much time learning about it
> <Hallski> dunno
> <Bevin>   helping out with the storyboard will be most of the work
> <Hallski> yes
> 
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] GUi installer brainstorm

[Geert Bevin]

On Mon, 2002-01-07 at 00:12, Taras Glek wrote:
> Why is a gui needed to do an installer? One could do a ncurses based

Because I personally like it. 

> console "gui" that would be just as useful, but wouldn't depend on shaky
> things like framebuffer(not all cards do vesa, some do it better/worse
> than others), imho using a console interface, sort of like the one in
> dos borland ides would be more than sufficient.

Ideally though, there should be 2 versions.

-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98

Re: [gentoo-dev] GUi installer brainstorm

[Miguel S. Filipe]

Taras Glek wrote:

>Why is a gui needed to do an installer? One could do a ncurses based
>console "gui" that would be just as useful, but wouldn't depend on shaky
>things like framebuffer(not all cards do vesa, some do it better/worse
>than others), imho using a console interface, sort of like the one in
>dos borland ides would be more than sufficient.
> 
>On Sun, 2002-01-06 at 14:54, Geert Bevin wrote:
>
>>Hi all,
>>
>>I post a log of what Hallski and I have been talking about on irc, 
>>please add you comments.
>>
>><Bevin>   what did you already imagine in terms of GUI tools for gentoo? 
>>installer, package manager, admin tools, ... ?
>><Hallski> not much really, the problem for packagemanager and admin 
>>tools would be which toolkit (or mulitple)
>><Hallski> about the installer I would really like to have it so that 
>>users see what happends and take an active part in it
>><Hallski> since it's very educating
>><Hallski> *puh*
>><Bevin>   that's also how I see the installer, more like a guide with 
>>blanks to fill in and commandlines to choose from, not something that 
>>tries to detect and do everything automatically
>><Hallski> yes
>><Hallski> well, some kind of hardware detection would be nice though
>><Bevin>   I saw this kinda like a frame based approach, left frame with 
>>details about the current step and required data with links to 
>>alternative paths
>><Hallski> that takes you through setting the different parts up
>><Bevin>   right frame almost exactly as a normal shell, but i which 
>>commands get auto-pasted from the left frame
>><Bevin>   didn't the new developer was going to work on auto-detection 
>>of hadrware
>><Hallski> yes, I think it would be rather nice to have that, so it can 
>>autoinsert commands
>><Hallski> oh, nice
>><Bevin>   so it's a kinda like an interactive and guiding documentation
>><Hallski> yes
>><Bevin>   with no need to print out the installation manual before 
>>installing
>><Hallski> it could even be so easy to just have a html-browser that 
>>shows the installation
>><Hallski> but it would be nicer to have some more interactive aproach
>><Hallski> like, when you excecute the command in the shell-prompt it 
>>takes you to the next step in the guide-part
>><Hallski> wonder if that would be easy to do :)
>><Bevin>   exactly my thoughts :-)
>><Hallski> you can have like Next-button
>><Bevin>   or even a real website-like navigation with possible 
>>installation actions tat still have to be done
>><Bevin>   the most important part will in fact be to write a good 
>>'story-board'
>><Hallski> agree
>><Bevin>   where every step in clear explanantions and all 'follow-ups' 
>>needed
>><Hallski> yes
>><Bevin>   guess I'll get onto that storyboard first then
>><Bevin>   and post it to the mailinglist as soon I have a first draft
>><Hallski> yes, that would be great
>><Bevin>   about the toolkit, I like to use qt for it for several reasons
>><Hallski> ok
>><Bevin>   1. everything possibly needed is available in 1 lib
>><Hallski> I don't want to hack QT but it's ok if you do it :)
>><Bevin>   2. it officially supports operating without X
>><Bevin>   first however I'd like to try to make a boot cd that contains 
>>the qt-embedded lib and an example app, as a proff of concept
>><Bevin>   do you know if drobbins has 'portagified' his build cd 
>>creation scripts already?
>><Hallski> well, I think I can look a little at QT, but I'd rather not 
>>spend to much time learning about it
>><Hallski> dunno
>><Bevin>   helping out with the storyboard will be most of the work
>><Hallski> yes
>>
>>
>>_______________________________________________
>>gentoo-dev mailing list
>>gentoo-dev@gentoo.org
>>http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>>
>
>
>_______________________________________________
>gentoo-dev mailing list
>gentoo-dev@gentoo.org
>http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>
For me, without any doubt, grafical installers can only cause trouble 
and compatibility problems.. has you said.
A ncurses aproach would be preferable, like the instalers of :
freebsd
slackware
debian
redhat v5 (the one i liked most)

It should be, in order of priority: functional/pratical,  stable, safe, 
fast, pretty.

Regards, and happy new year!

Miguel Sousa Filipe
debian and gentoo user
m3thos@netcabo.pt (PORTUGAL)

Re: [gentoo-dev] GUi installer brainstorm

[Taras Glek]

On Sun, 2002-01-06 at 15:21, Geert Bevin wrote:
> On Mon, 2002-01-07 at 00:12, Taras Glek wrote:
> > Why is a gui needed to do an installer? One could do a ncurses based
> 
> Because I personally like it. 
If you absolutely need a gui installer, why not use a non-qt one. Afaik
the qt one requires that you write your apps in C++, and I don't know
how many drivers it supports. Alternatively stuff like microwindows and
directfb are more toolkit/language idependant and are somewhat less
propriatory.
> 
> > console "gui" that would be just as useful, but wouldn't depend on shaky
> > things like framebuffer(not all cards do vesa, some do it better/worse
> > than others), imho using a console interface, sort of like the one in
> > dos borland ides would be more than sufficient.
> 
> Ideally though, there should be 2 versions.
> 
> -- 
> Geert Bevin
> the Leaf sprl/bvba
> "Use what you need"           Pierre Theunisstraat 1/47
> http://www.theleaf.be         1030 Brussels
> gbevin@theleaf.be             Tel & Fax +32 2 241 19 98
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] GUi installer brainstorm

[Geert Bevin]

> > Because I personally like it. 
> If you absolutely need a gui installer, why not use a non-qt one. Afaik
> the qt one requires that you write your apps in C++, and I don't know
> how many drivers it supports. Alternatively stuff like microwindows and
> directfb are more toolkit/language idependant and are somewhat less
> propriatory.

Because I know qt and C++ very well and the power and flexibilty
included inside has no competition. It supports quite a lot of drivers
and there is a specific qt-embedded distribution targetted specifically
for these kind of implementations. Also the same applications written
for qt-embedded run without any modifications under x11.

-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98

Re: [gentoo-dev] GUi installer brainstorm

[Mikael Hallendal]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

mån 2002-01-07 klockan 00.43 skrev Miguel S. Filipe:

> For me, without any doubt, grafical installers can only cause trouble 
> and compatibility problems.. has you said.
> A ncurses aproach would be preferable, like the instalers of :
> freebsd
> slackware
> debian
> redhat v5 (the one i liked most)
> 
> It should be, in order of priority: functional/pratical,  stable, safe, 
> fast, pretty.

To clearify, just because it's written in QT/C++ (though I'm not a big
fan of either QT or C++) doesn't rule out functional/practical, stable,
what do you mean by safe? (safe as in user-can't-do-it-wrong?)

What is really the issue here is the functionality we need. Since this
is done on Bevins (and perhaps mine) sparetime there is another priority
you forgot above. The fun of doing it, otherwise it won't get done.

So, the reason for a GUI installer is simply that both Bevin and me
thinks it would be fun to write one. And we think that it would benifit
the users. Of course there will be an alternative of installing it in
the same way as it's currently done.

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] GUi installer brainstorm

[Geert Bevin]

I've been thinking about the core engine, and what would be nice is an
abstracted installer storyboard language. This might for example use xml
to define actions, sequences, paths, default responses, etc etc
The storyboard in itself can be maintained independently and several
frontends can interprete it. I can freak out on the Qt version, Hallski
can make his Gtk+ version if he feels like it, and someone else (or
maybe me if I feel courageous) can do an ncurses version.

On Mon, 2002-01-07 at 02:00, Mikael Hallendal wrote:
> So, the reason for a GUI installer is simply that both Bevin and me
> thinks it would be fun to write one. And we think that it would benifit
> the users. Of course there will be an alternative of installing it in
> the same way as it's currently done.

That will not be too difficult :-)

-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98

Re: [gentoo-dev] GUi installer brainstorm

[Mikael Hallendal]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

mån 2002-01-07 klockan 02.10 skrev Geert Bevin:
> I've been thinking about the core engine, and what would be nice is an
> abstracted installer storyboard language. This might for example use xml
> to define actions, sequences, paths, default responses, etc etc

This sounds exactly like what I was thinking :)
That way it's going to be easy to define commands and stuff that can be
used to auto-insert on the command prompt if the user wants that.

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] GUi installer brainstorm

[John Stalker]

I like this idea.

Geert Bevin wrote:
> I've been thinking about the core engine, and what would be nice is an
> abstracted installer storyboard language. This might for example use xml
> to define actions, sequences, paths, default responses, etc etc
> The storyboard in itself can be maintained independently and several
> frontends can interprete it. I can freak out on the Qt version, Hallski
> can make his Gtk+ version if he feels like it, and someone else (or
> maybe me if I feel courageous) can do an ncurses version.

In general for install/config/admin tools I think the key is to separate
the functionality from the interface.  The kernel config tools are a
good example of what I mean: you get the same functionality no matter
whether you make config, menuconfig, or xconfig.  The kernel config
tools are a good model in one other respect as well: help which is
actually helpful most of the time.  It is important that help is
part of the functionality, so you get the same help no matter which
interface you choose.

I have one suggestion regarding hardware detection/configuration.
Doing things automatically is not easy--this is something even
big distributions get wrong frequently.  There are several options
intermediate between Windows-style automatic configuration and the
current extreme do-it-yourself approach.  One which involves minimal
work is to use ebuild scripts to do all the work.  For example I
could write an ebuild for Epson 777 printers (USB version) which
would download the upp files, check dependencies--in this case
ghostscript and a USB controller package--maybe check /usr/src/linux/.config
and warn if kernel support is missing.  It could also use lpadmin
to configure the printer, but maybe this shouldn't be automated.
If everyone who had trouble geetting a device working under gentoo
wrote an ebuild for that device then new users could save a lot of
time getting their systems working.  One advantage is that you could
use whatever UI front end you write for choosing and installing
applications to configure hardware as well.  I don't see much point
in hardware detection at the moment; I think most new users know
what hardware they have.
--
John Stalker
Department of Mathematics
Princeton University
(609)258-6469

Re: [gentoo-dev] GUi installer brainstorm

[Geert Bevin]

On Mon, 2002-01-07 at 15:24, John Stalker wrote:
> I have one suggestion regarding hardware detection/configuration.
> Doing things automatically is not easy--this is something even

We really don't want to do stuff automatically, however auto detecting
hardware configurations might be a good feature to help a user with the
identification of his/her system. People that install gentoo tend to
know their computer well, but not necessarely all aspects and components
of it.

> big distributions get wrong frequently.  There are several options
> intermediate between Windows-style automatic configuration and the
> current extreme do-it-yourself approach.  One which involves minimal
> work is to use ebuild scripts to do all the work.  For example I
> could write an ebuild for Epson 777 printers (USB version) which
> would download the upp files, check dependencies--in this case
> ghostscript and a USB controller package--maybe check /usr/src/linux/.config
> and warn if kernel support is missing.  It could also use lpadmin
> to configure the printer, but maybe this shouldn't be automated.

The installation process has not (yet) the intent of creating a fully
customized system. The first step will be to aid the user to go from the
build cd to a first running and custom compiled gentoo system.

> If everyone who had trouble geetting a device working under gentoo
> wrote an ebuild for that device then new users could save a lot of
> time getting their systems working.  One advantage is that you could
> use whatever UI front end you write for choosing and installing
> applications to configure hardware as well.  I don't see much point
> in hardware detection at the moment; I think most new users know
> what hardware they have.

-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98