Re: PEAR Installer GUI project

Started looking at this this afternoon, mainly from an interface design aspect. browsing packages = whats available, what have I got already looking at documentation/code - phpcodedoc?/manual/cvs.php.net..... ,/deciding to install it.... / run pear installer.... - options to say 'where to install'.... I've got to go through the current installer code to get an understanding of the concepts of the 'registry' etc... can you point me at the key classes? I'm looking at mon/tues to get a better grip on it.. basically 1st version can use libglade, (as it's quick to put together), but evenutally look at phplibglade in phpmole - a glade emulation layer, (as glade on windows is currently a bit flakey)... regards alan Stig S. Bakken wrote:

On Fri, 2002-05-24 at 12:48, Bertrand Mansion wrote:

Hi all, I have heard some time ago someone (sorry I don't remember who) talk about a php-gtk version of the PEAR installer with a GUI. Is this a project or is it already started ? I have some time this afternoon to code a PEAR Installer GUI for MAC OSX with Objective-C. My main concern is how to detect if php is installed as cgi and, if not, to install it. Do you believe installing php from the PEAR installer is a good idea or not ?

Hi, I'd love to get some help with the Gtk version. But please don't start a separate project with a different codebase, because the installer already have a PHP infrastructure for different user interfaces. Right now all the PEAR commands are implemented in a UI-neutral way (take a look at the files in php4/pear/PEAR/Command/*.php). All user interaction should go through a frontend class (php4/pear/PEAR/Frontend/*.php). I have added a skeleton for the Gtk class there. If you have php-gtk installed and run "pear -G" it will start the installer in Gtk mode, but right now all it does is open a window. ;-) I have lots of ideas on how to design this technically, which has lead to the current command/frontend architecture. I'm not completely confident about the user interaction scheme yet, right now it does interaction calls "on demand", which may not give the best results in Gtk. For example, if the user should confirm something, the UI class does not know this until the command code requests confirmation, so it's not possible to render a screen in Gtk with a checkbox for the confirmation. It has to be a pop-up window right now. The alternative, that would allow for Gtk screens with all options laid out in advance, is using an XML-based form format, but that's much more complex so I wanted to try this approach first. - Stig