Elizabeth Smith wrote:
 > > The issue isn't "is php-gtk worth it" it's "do we need yet another 
[windows] installer that does things its own way"


No, but we do need some published standards to follow.

I avoid standards.
Non-the less there should be a standard *published* schema for win32 
php-gtk essentials

I avoid messing with anyones registry
Non-the less its the perfect place to keep such information, both php, 
NSIS and other popular installers can access this data.

SO: as a developer packaging my wares I should be able to check

a) if & where PHP is installed (because I know where to look ...I don't 
want to have to search)
b) what php-gtk specific extensions are available if my install depends 
on them (glade etc)
c) what the installed file-association is (.phpw (I like .phpx))
d) what the php version is.
e) where the default (php-gtk) php.ini is

/*simplistic e.g.*/ HKEY_LOCAL_MACHINE/blah/blah/php-gtk2
                                                    /path "c:/program 
files/php-gtk2/bin/php.exe"
                                                    /inifile  
"c:/program files/php-gtk2/etc/php.ini
                                                    /assoc  "phpw;phpx"
                                                    /ext_path      
"c:/program files/php-gtk2/lib"
+ of course the relevant entries for the file association.

Then we need a *published* install routine, so lets say I want to 
distribute my application which I might  package with /*e.g.*/ NSIS 
(easy, free)

NSIS (and most other installers) can read the registry (& we know where 
to look) and if it finds that all is well can continue with the 
installation, it can also create *my_app.phpw* launcher shortcut since 
it knows where everything is.

.....................................

In fact one could pre-package an NSIS installer config file that would 
also include e.g. the win32 version of wget (which is  quite small) and 
if php-gtk is not installed (in the correct place) it could download and 
install a php-gtk team sanctioned installer, install php-gtk then 
continue with the original application.

WIth such a distributed pre-configuration for popular installers 
developers only need add their application folder to the NSIS build tree 
and voila their app is wrapped and ready.

Vista's pointless UAC will complain as would the SP2 or 3rd party 
firewall about wget but there is not a lot one could do about that.
.....................................

To avoid
... forcing installation to 'c:/' ... when I was a windows user I HATED 
anything that installed to c:/ , not sure why, but I was not alone (and 
quite  guilty of doing such with phpdev ;))

... PEAR , love it or hate it its a problem, I don't personally think 
PEAR should be anything other than an joyful extra , what I mean is I 
don't think php-gtk2 runtime installation should rely on PEAR in any form.

To consider
... a standard installation makes life easier for those with less than 
ideal motives .. PHP (as with PERL/Python etc) can do a lot of damage 
and can be used for evil.
Last time I created an installer I ended up creating an application 
registry script and forced all phpx scripts to be launched via the 
registry script, so .phpw file association actually called `php.exe -f 
registry_script %1` which would check if the user had run this script 
before and ask them if its OK etc etc, probably overkill .. but I have 
paranoid days ;)

Anyway them's my thoughts whether anyone wanted them or not :)
This is something that really needs to be sorted out though.

If some basic standards can be agreed on then the rest is really quite 
straightforward.

Regards,
Simon.




                                                                 
>     
> > Whether it is the "best" is an exercise left up to the individual 
> > developer. Having a single software platform to share data with 
> > client and server has proven to me invaluable. That my servers run 
> > PHP and share data with my client software makes PHP-GTK a no-brainer. 
> 
>  Err, you're missing the point here.  Windows + gtk and dependency dll 
>  hell + a million php installs is not a good combination.  Every 
>  php-gtk script installing their own version of php-gtk will add up 
>  (especially with many small scripts) and doesn't gain you a thing.  A 
>  single common way to install php-gtk (on windows or even unified 
>  locations/settings on  *nix) is an excellent thing.
> 
>  I can tell you right now that gnope breaks any php installed using the 
>  "official" php msi installer.  Do we really need a dozen installers 
>  overwriting each other and putting conflicting ini files in bad places?
> 
> > And the 10 or so MBs for the installer has *NEVER* shown up on the 
> > RADAR as in any way problematic. (For MacOSX, the installer 
> > effectively swallows some 400 MB with X11, XCode, and the PHP-GTK 
> > binaries, and even that is deemed worth it by my clientelle) 
> 
>  The issue isn't "is php-gtk worth it" it's "do we need yet another 
>  [windows] installer that does things its own way"
> 
> > I guess the real question to answer is introspective - is your 
> > program actually worth $0.01 to your end users?
> > -Ben
>