discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Status of Installer.app?


From: Frederico Muñoz
Subject: Re: Status of Installer.app?
Date: Tue, 15 Feb 2005 00:34:55 +0100

Hello,

On 2005-02-14 19:48:46 +0000 Adrian Robert <address@hidden> wrote:

> Hi,
> 
> I was thinking of hacking up a simple barebones installer application for 
> GNUstep that just copies a .app somewhere and optionally runs pre- and 
> post-install scripts.  Then I noticed 
> http://savannah.nongnu.org/projects/gap/ .  Excellent!  Does anyone know the 
> latest status of Installer in the CVS tree there?  How much work does it need 
> (for barebones functionality, not bells and whistles)?
> 
> Alternatively, is anyone else working on a .app and/or framework installation 
> app?

I am.

> 
> Main necessities would seem to be:
> 
> - graphical operation from workspace

Of course, my app registers it self for the package types that it handles.

> - UI to get root permissions

Not done,simply because we will need a general solution to do this for other 
apps. If however you need it urgently I guess a NSPanel wrapper on su or sudo 
can be hacked. 

> - pre/post install scripts
> 

Perfectly possible, but depends on the actual package type (read below)

> 
> Eventual desirables would be:
> 
> - progress display (preferably not bogus, though the bar is low here)

I have in my copy a NSPanel with a NSProgressbar. The UI details are not fixed 
yet, and the actual progression info depends on the package type.

> - ability to sequence multiple steps
> - source-based build-install capability (to accomodate Windows and varying 
> unix installations)
> 

Right.

First of all, please understand that this is my first GNUstep program, so the 
actual code will look horrible since I tend to have an idea of what I want, 
implement it the quickest way I can, and only after do I clean it up :).

The Installer I'm making relies on bundles to support different package 
formats. The expected package info is put on a protocol and bundles must adhere 
to it, thus the actual mechanism of getting the info (that is highly dependent 
on the packaging format) is abstracted. My main testing bundle is the .deb one, 
but e.g. I make a Pkg bundle that could read NeXT/OPenStep .pkg's (see a 
somewhat old example at http://www.gesal.org/gnustep/installer_pkg.jpg). This 
can be extended to any packaging format.


For the multiple steps sequence a problem arises. My idea would be to have a 
bundle that supported the OSX .pkg format (basically the NeXT format on 
steroids, with preFlight, postFlight, available volume size checking,etc). This 
however has a great impact on the UI. I chose from the begining to base my work 
on the NeXT installer, that basically presents all the info and then lets you 
install. To multiple steps to work the UI needs to be like "Install Shield", 
wizard-like. OSX Installer does this 
(Welcome->next->next->next->install->close).

I can't honestly say that, as it is, my Installer is ready for prime time. I 
can however say that I have already installed debs with it, and that I'm 
actively developing it. There are probably some structural changes that need to 
be done yet that I'm only aware as I go along and detect that something is 
missing. The package protocolm for example, was made in a rather ad-hoc fashion 
and needs to be revised. But it is certainly possible to do most of what you 
ask (the biggest doubt being the sequential steps, and that only because I 
don't know how to do it without changing the whole UI structure). I was 
actually tempted to change the UI to be wizard-like, but most people I talked 
to disliked the idea. I welcome comments though :)

BTW, the homepage is http://home.gna.org/installerapp . Gregory seems to also 
have an installer in his GAP suite... I don't know the status of it, but if he 
is set on doing it his skills are far superior to mine.


Best regards,

fsmunoz
 

-- 
Frederico Muñoz
address@hidden






reply via email to

[Prev in Thread] Current Thread [Next in Thread]