[lokisetup] setup v2 (was lokisetup for dummies)

[Sean Middleditch]

On Sun, 2004-01-04 at 14:57, Chunky Kibbles wrote:
> On Sun, Jan 04, 2004 at 10:46:39AM +0000, Adam D. Moss wrote:
> > 
> > >If we're statically linking GTK+, then it really might be worth writing
> > >some extremely minimalistic toolkit if it'll save a megabyte, but that
> > >might be going too far once the actual link size is evaluated.
> > 
> > I'm sure that some pretty minimal statically-linkable toolkits
> > came out of the pre-gtk/qt chaos and could be dusted off.  FLTK
> > comes to mind (or hey, how about crufty crummy old Xaw -- ugly, but
> > probably safe to leave dynamically-linked).
> 
> Personally, I think that Less/Motif would be a better bet if we're
> gonna drop pretty stuff altogether, but FLTK is only about 50k,
> iirc... Bleargh. I really think that in the end there oughta be a
> choice of UI bits, as there will be many, many cases where GTK is
> simply the way to go.

Separating the GUI/engine from the package format is of course the best
way to go for this sort of thing.  Letting the system's "installation
engine" of choice handle the install files lets the user have a fully
integrated intelligent installation experience.  I, for one, would think
any modern app using something like Motif for installation was made by a
pack of inept idiots (there are tons of proven problems with it, not to
mention it quite clearly shows it age visually).  KDE users would prefer
a KDE installation engine that follows the KDE style guide.  GNOME users
would want a GTK+ based engine that followed the HIG.

Also, separating the engine from the application packages allows at
least some future proofing.  Look at menu entries, as an example - most
older Loki-Setup based games no longer create menu entries on modern
KDE/GNOME installation, because the menu system has changed several
times (and is now being standardized across all desktops as per the
FreeDesktop.org specs).

Simply describing the application in the installation package and
letting the user's installed engine handle creating the menu entries
guarantees that packages will always work, even if the menu system
changes in the future for any reason.

System like Autopackage partially do this, by using a single
installation engine (which is *not* packages with the application in
most cases), while separating out the GUI into separate modules
(Autopackage currently has both a TTY and a GTK+ front-end, which work
equally well for all packages) and letting the installed version special
cases situation that a "stock" Autopackage may not handle correctly for
the specific system.

This is Linux/UNIX we're talking about, after all.  There is no single
system image.  Even on a single distribution, each version is often
wildly different from previous and following versions.  And then, even
on the same distro and version, users can easily tweak the system in
incompatible ways.  As much of the logic as possible should be pulled
out into the system, or (as is already shown with all existing Linux
packaging/installation systems that predetermine just about everything
as package creation time, including RPM and Loki Setup) the applications
will no longer be able to install 100% correctly within a couple years. 
Letting the engine handle most of the logic allows much more complete
system integration, as well.  For example, Autopackage has plans to put
any installed .package file into the RPM database of the system (for RPM
based distros), so users can use their already existing system package
manager to remove applications.  (Again, a much better user experience.)

The application package needs to just describe what it is carrying, and
let the engine handle the rest.  For CD distributors, the engine can be
included on the CD to install or upgrade it if the user's copy is too
old (or she doesn't have a copy at all).  For downloads, the
installation engine can simply be a pre-requisite, and should be
available on modern distributions (which it would be if it becomes
useful and popular).

> 
> Gary (-;
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.