Re: PEAR Installer GUI project
| From: | Alan Knowles | Date: | Sat, 25 May 2002 01:11:36 +0000 |
| Subject: | Re: PEAR Installer GUI project | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-6405@lists.php.net to get a copy of this message | ||
Ok, updated docs.akbkhome.com/pear to reflect current CVS and the installer..
Stig, it would be nice if you add a bit more phpdoc comments on PEAR_Command_* and PEAR_Registry (and similar) so that the input/return values are clearer - I'll survive without, bit a few notes would help :)
Ok, the gtk installer would have a few small issues, that would involve breaking a few methods up..
From the simplest aspect.The 'Confirm' process..
in the CLI. you print 'are you sure', and just wait for the user to type 'Yes' etc. on stdin.
in GTK. you display a window, tell the window what to do (what method to call) when the user and presses ok or cancel. - eg. you dont normally
if ($this->ui->confirm('some message')) {
do stuff..
you would do something a bit like this..
$this->ui->confirm_ok('some message',array(&$this,'install_confirmed')); // this is usually easier to deal with.
or
$this->ui->confirm_ok('some message',array(&$this,'install')) = and it would call the same method with a 'confirmed flag'
from the registry command code.doList();
array('caption' => 'Installed packages:',
'border' => true));
foreach ($installed as $package) {
if ($i++ % 20 == 0) {
$this->ui <http://docs.akbkhome.com/pear/classes/PEAR_Command_Registry.html#$ui>->tableRow(
array('Package', 'Version', 'State'),
array('bold' => true));
}
$this->ui <http://docs.akbkhome.com/pear/classes/PEAR_Command_Registry.html#$ui>->tableRow(array($package['package'],
$package['version'],
@$package['release_state']));
}
dealing with tables like this is a bit wierd... In gtk, doList should probably just return array( $installed,$list), or maybe just ignore this class and access the registry class directly.
. - it would have been nice to see $package->version, $package->release_state, rather than $package[] so the package data structure could have been documented easily as a class... (bit late now I guess :)
The GTK version would probably start up,
Ask the PEAR_Registry Class for a list of available classes (as array of objects?)
use this list to build a Collumned Tree with flags for new/installed ..... etc.
this could be expandable to show classes/methods/vars contained with in each package.......(phase II)
when you select a package - you get to see dependancies.... author, version status etc. in detail/ options to install/remove
when you select a class - you get to see some documentation/ overview....(phase II)
A PEAR config tab - where do want to install etc.....
it may be advantagous to add progress information - eg. if you are installing a package that auto downloads dependancies
$this->ui->progress_dialog('Transfering 1/2',1)
$this->ui->progress_dialog('Transfering 2/2',2)
$this->ui->progress_dialog_close();
The other issue that make life difficult is that code like this in PEAR_Remote will totally freeze the user interface if the application (you have to either use while(gtk::event_pending()) gtk::main_interation(); or use gtk_input_add($fp,array(&$this,'got_data'));
}
while (trim(fgets($fp, 2048)) != ''); // skip rest of headers
while ($chunk = fread($fp, 10240)) {
$response .= $chunk;
}
and again break the method up - so that it call this->ui->fetch_data($fp,array(&$this,'tranfer_completed'));
thats all for this morning..
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