To set the scene: you have PHP running happily as an Apache module on your Windows development machine. Quite sensibly you only test PHP/Apache on Windows and always upload to some *NIX flavour for the hosting of your pages and applications. So far, so good.
Then you hear about PHP-GTK and see the huge advantage of being able to develop x-platform client-side GUI’s with PHP as opposed to JAVA or VB. You already know that PHP can handle pretty much anything you can throw at it, and you already know it inside out — so why wouldn’t you use it?
So you download the latest PHP-GTK binary from gtk.php.net and follow the instructions carefully… which is where things start to go wrong. Let’s look at why, and see if we can’t get you back on the road to successfully running PHP-GTK and PHP-Apache on Win32.
The Install
Once you’ve downloaded PHP-GTK, if you were to follow the PHP-GTK installation instructions, you’d open a command prompt and type c:gtkphp4php.exe -q c:gtksamplestest.php. Now, when you hit ‘return’, 1 of 4 things will occur:
- PHP-GTK will work as expected and will not affect your existing PHP-Apache setup (preferred but unlikely)
Why does this happen? Because you followed the instructions!
The first thing many people do is exactly what the PHP-GTK download tells them to — they extract the php4ts.dll into the system32 folder, thus overwriting any existing versions, and, unless you’re very lucky, causing your mod_php apache setup to fail miserably.
Note that if your apache-php setup appears to fail after you install PHP-GTK, you’ll need to reinstall PHP — Apache is not the issue. Note also that if you do not already have PHP-Apache on your machine, the installation as recommended at gtk.php.net will work flawlessly, but that’s an unusual scenario for any developer who’s interested in PHP-GTK.
Why Does it Fail?
There are 2 main reasons why the recommended installation may fail.
1. PHP versions
As PHP-GTK and PHP are both evolving at different paces it’s not always easy to have the PHP & PHP-GTK binaries compiled against the same build. Thus php_gtk.dll & php4ts.dll might be compiled against PHP4.1.* cvs and your main PHP binaries against 4.2.1 (hopefully you have upgraded to 4.2.2 by now).
You can get more up to date PHP-GTK builds here, but even if you do have all the right versions, I’d still suggest at this point in the PHP-GTK development cycle that you proceed with the following structure. Why? Simply because it can’t go wrong — this has to (and does) work, and will continue to work even after you upgrade your Apache-PHP version.
2. The php.ini
The php.ini issue is partially related to the versioning issue. The php.ini that PHP (as an Apache module) uses, has several incompatible modules listed, plus totally different include paths, and includes several other possible stumbling blocks (such as the Zend optimiser, for example). Again, as it’s difficult to grab compatible GTK and PHP versions, we need to completely separate the two.
…so let’s get started!
Assumptions
I’ll assume that you have PHP running as an Apache module.
The location at which you’ve installed your PHP and Apache binaries is irrelevant, with the exception of having PHP installed to C:PHP. PHP-GTK will assume that PHP is installed to C:PHP (unless you tell it otherwise), and if you’ve installed it elsewhere, you may find that some PHP-GTK scripts will work, while others fail.
Installation
Grab the latest GTK binary from gtk.php.net, unzip it to the folder of your choice (I suggest c:gtk for the purposes of this tutorial), and you should have a structure a little like this:
- php4 -> php and php-gtk binary files
- winnt -> the default php.ini file
- winntsystem32 -> gtk binaries used by the extension
- samples -> a few samples to demonstrate the usage
I’ll assume that you unzipped to c:gtk though anywhere will do. Next, go into the winntsystem32 folder, grab its entire contents, and put these files into the php4 folder. Do the same for the php.ini file in winnt Once that’s done, you can delete the c:gtkwinnt folder (don’t worry — you’ll always have the zip file as a backup). That’s it: installed!
Now if that seems too easy, well it is. However, now you’ll want to check whether it works or not. There are several sample scripts that come with PHP-GTK, but let’s knock up a quickie here. We’ll make it as simple as it gets — a window with a button — but don’t worry about how it works at this point. Just test to ensure that it does in fact work!
The Test
Save the following as -f c:gtksamplessimple.php (and don’t worry about what’s in the code just yet).
<?
dl('php_gtk.'.(strstr(PHP_OS, 'WIN') ? 'dll' : 'so'));
function delete_event(){
return false;
}
function shutdown(){
print("Shutting down...
");
gtk::main_quit();
}
function hello(){
global $window;
print 'Hello World! "
."';
$window->destroy();
}
$window = &new GtkWindow();
$window->connect('destroy', 'shutdown');
$window->connect('delete-event', 'delete_event');
$window->set_border_width(10);
$button = &new GtkButton('Hello World!');
$button->connect('clicked', 'hello');
$window->add($button);
$window->show_all();
Gtk::main();
?> To run that script we need to use what can only be described as some inelegant command line scrawlings. To this end, I normally write a batch file — it’s far less frustrating than making typos in Windows’ woeful command window.
There are 3 sections to worry about in our command line:
- the path to PHP
- the path to your php.ini and
- the path to your script
cd c:gtkphp4php.exe -qThis command tells Windows where to find PHP.exe if it’s not in your PATH (and if it is in your PATH, it’s probably the wrong php.exe). The -q switch suppresses any HTTP headers that PHP might otherwise create.
Trying to use your existing php.ini in your system directory can cause many an error, depending on how much you have modified it (though, for a start, you can expect all the include and extension paths to be wrong).
The -c switch lets us specify an alternate php.ini to the defaults, which are c:windows(WINNT)php.ini or c:PHPphp.ini or ? your_pathphpphp.ini
-c c:gtkphp4php.iniNow: identifying the path to the script that we want to run. The -f switch tells PHP that this is a file and not some other argument. You can actually live without it in most cases, but it’s hardly a hassle to use it!
-f c:gtksamplessimple.php All this comes together as the ungainly but effective:
cd c:gtkphp4php.exe -q -c c:gtkphp4php.ini -f c:gtksamplessimple.php
You can see why batch files are so useful (masochists can type the above at a command prompt if they wish). I’d save the above as c:gtksimple.bat (or anywhere on your machine) and click away. Voila ! an x-platform window without a snake in site.
To sum up, get your gtk directory to look like this: C:gtkphp4
- gdk-1.3.dll
- glib-1.3.dll
- gmodule-1.3.dll
- gnu-intl.dll
- gtk-1.3.dll
- iconv-1.3.dll
- libglade-0.14.dll
- libxml.dll
- php.exe
- php.ini
- php_gtk.dll
- php_gtk_libglade.dll
- php_gtk_sqpane.dll
- php_win.exe
- php4ts.dll
And a testing directory C:gtksamples
- simple.php (among others)
That’s the basics — and all you actually need to run PHP-GTK!
Notes and Resources
php_win.exe?
You probably noticed the php_win.exe. As far as I can tell, the php_win.exe is only different in that it allows your PHP-GTK scripts to run without the DOS window that will otherwise pop up whenever you run a PHP-GTK application. This is great for presentation, but note that if you echo to stdout, then the app will crash, so direct any output to file if you want to debug with php_win.exe.
Also, it appears that php_win.exe looks first for extensions etc. in C:PHP. It will use those if it finds them, as opposed to the ones in system32 (this is only my observation).
Extensions
Your c:gtkPHP4php.ini should have no extensions enabled. We dl() the gtk module, and you will have to test individual extensions on a trial and error basis (MySQL/FTP etc are all available anyway).
Conclusion…
Now that you’re up and running, you’ll be wondering what’s next. I’d suggest you download the PHP-GTK manual from gtk.php.net and browse the site — there are some useful snippets in the manual, and a few links to apps and other resources that are a good starting point for world domination via PHP & PHP-GTK! Enjoy!
Simon WheelerSimon is a Perth-based IT consultant, data diviner and self-confessed php addict. He develops the phpdev package for win32 which can be found along with other bits and bobs at Firepages.com.au
