Apologia
More than anywhere else in PHP development, the state of the win32 port is crucial to PHP-GTK. Why is it so important? Because we're talking here about desktop applications and, regardless of the strength of open source software throughout the development community and at the heart of the world wide web, the vast majority of the GUI-application-using public still have some form of MS Windows as their desktop operating system.
It is both PHP-GTK's strength and its weakness that developers can use it to write applications that should run pretty much anywhere, from any platform. If this article seems a little obsessive over portability, bear in mind that this writer believes it to be a critical factor in PHP-GTK's potential success. It's good and fine that everything works so readily under *nix systems - but where are you most likely to need to distribute your applications?
DND, new extensions, and the arrival of Zend Engine 2
Our community hasn't been idle over the months since the last article on PHP-GTK appeared in this magazine. Before the first issue hit the streets, Frank Kromann made the bindings for a more recent version of the GTK libraries to win32 and proved me wrong over drag'n'drop. We now have DND working as well under Windows as it does under *nix systems.
Frank's next innovation was the port of GtkScintilla, which finally provided win32 with the halfway decent text widget it had so badly needed. This opens up possibilities we simply didn't have before. For example, when I went to speak about PHP-GTK at LinuxTag, I made the slides for my presentation with a quickly knocked-up PHP-GTK application that utilises the Scintilla library. It effectively played the role of PowerPoint. Okay, so you can't insert images in GtkScintilla - but if you're writing your own application you can knit yourself neat little options like `minimise this window mid-show and allow other programs to be demonstrated, then let me return directly to the slide I was working from'. There has to be a catchier way of saying that.
Fig. 1: GtkNotebook and GtkScintilla coming into their own
Andrei and Alan K. were hardly inactive during this period either; between them they wrote (and assiduously maintain) a ZE2 port of PHP-GTK. The first and most obvious bonus of PHP 5 from our perspective is that object destruction works in PHP now. With the ZE2 port, memory-eating graphics are a thing of the past. An unexpected side effect has been the loss of DND in both the *nix and the (very new) win32 versions of PHP-GTK. Evidently this is a PHP 5 issue rather than a GTK+ issue, and that's good news. It means it's likely to be something we can fix.
A newcomer to PHP-GTK development, Angel Maza, gave us GtkExtra back in May. It took some weeks for me to notice that there was nothing to prevent this widget set from being ported to win32, but only a couple of hours for Frank to adapt my attempts into a working version of that port. It's very cute, if still buggy at the time of writing. Here are some screenshots to whet your appetite:
Fig. 2: An early version of GtkPlot running under Windows 98
Fig. 3: GtkSheet in action
Alan Knowles chose the same month to play with GtkCanvas, an aptly named widget that allows all things to be drawn on it - string, colour, shape or widget. If we were still using the GTK+ libraries that don't allow DND, we'd be able to have this running under win32 too. As it is, GtkCanvas has imlib as a dependency, and imlib relies on an X11 environment. Tor Lillqvist - the guy chiefly responsible for porting GTK+ to win32 in the first place - threw out nascent win32 imlib support well over a year ago, with a view to replacing it with the more portable gdkpixbuf in GTK 2. Alan suggested going through the original source and removing the graphics support before attempting to build GtkCanvas under win32. This hasn't really been discussed on the development list, and may not be an option as PHP-GTK is supposed to bind to existing libraries rather than mutilated versions of those libraries. It would, however, be the only way we could allow win32 users to embed pixmaps in text widgets.
Fig. 4: GtkCanvas (screenshot courtesy of Alan Knowles)
The GdkPixbuf saga runs and runs. Both myself and Frank have made several attempts to port it for win32 now, but it seems that the libraries that are available to us fight with our GTK+ version all the way down the line. At the last attempt, we were four functions away from success - but those functions included
new_from_file() and
finalize(), so that's less good than it sounds.
All in all, GTK 2, with its internal cross-platform solutions, remains the equalizer we're all waiting for. The holdup there is PHP 5/ZE2 stability; when we have that, it will be possible to finally move on.
Ready to go?
One of the items that is already within our reach is a distribution mechanism. Alan wrote the bcompiler some time ago, initially as a feasibility study for a PHP to C convertor, but also with the problem of PHP-GTK application distribution in mind. Bcompiler is available in PECL, and the pre-made
.dll can also be downloaded from snaps.php.net for the latest stable release of PHP 4.
Let's take a very simple, if less than stylish, `Hello World' example script and run through the process.
<?php
class main {
function main() {
dl('php_gtk.dll');
$window = &new GtkWindow(GTK_WINDOW_DIALOG);
$window->set_title('Compile test');
$window->set_position(GTK_WIN_POS_CENTER);
$window->set_default_size(200, 50);
$window->connect_object('destroy',
array('gtk', 'main_quit'));
$label = &new GtkLabel('Hello World!');
$window->add($label);
$window->show_all();
gtk::main();
}
}
main::main();
?>
The bootstrap file MUST call
main::main(); Generally this file would only contain a list of required files and the class
main. The
main::main() function itself would simply call another function in one of the required files which would be responsible for generating the GUI, and you would of course have set up your
php.ini or a required file to load the
php-gtk dll.
Create a basic script like the one above. Name it something simple; I called mine `hello', for obvious reasons. Don't bother with the
.php file extension - this is the basis for a binary executable file, and the .exe extension will be added to the full name of the original file at present.
The bits and pieces you need to create an executable are:
php_bcompiler.dll, a file named
bcompiler_compile.php which is in the examples folder in the bcompiler extension in PECL, and (assuming you don't have access to MSVC++) a copy of
phpe.exe. The only way I've found to get hold of this last item, other than building it, is to download Alan's mbdesigner from devel.akbkhome.com and allow it to create a default installation. This isn't necessarily a bad thing - it's useful to see how a PHP-GTK project copes with this install methodology - but it would be cool to see a version of this on Edin Kadribasic's site, given that he invented it.
Put all three items and your bootstrap file into the directory where your php.exe and php-gtk.dll live. Open up a DOS box and cd to that directory.
C:\WINDOWS>cd \php4
Then type something like this:
C:\php4>php bcompiler_compile.php hello phpe
The output you should see looks like this:
Fig. 5: Bcompiler output
There should now, of course, also be something named
hello.exe in your php4 (or equivalent) directory. You can run that by double-clicking directly on the executable, or alternatively through the DOS box:
C:\php4>hello
Fig. 6: A compiled `Hello World'
Naturally there are gotchas in a less basic application, particularly when Glade or images are involved. These are amply covered on Alan's site, under talks/gtk_to_desktop.html. The only item I can see that is not covered there is the issue of the background DOS box. There are two simple options for eliminating this. The first way is to use the
php_win.exe (a wrapper written by Frank Kromann that is part of the standard PHP-GTK distribution). The other, perhaps less complex, option is to open the PHP-GTK application via a desktop shortcut to a DOS batch file that has been set to run as `minimized'.
Once you have an executable PHP-GTK application, it can be worthwhile looking at the various installers available for distributing applications for Windows users. The aforementioned page gives clear instructions on using Inno Setup to create a professional installer for your app.
Gnomic themes
While we're on the subject of how things look, there's a very nice piece of work from Christian Weiske filed in the PHP-GTK applications repository. He's compiled a selection of GTK theme engines for use with PHP-GTK apps, and created a sane test suite to check that you've installed them correctly. While the theme engines themselves are written in C, the rc files that call them allow the PHP-GTK programmer to override tiling pixmaps, colours, fonts and key bindings as normal. The advantage of the theme engines themselves is that they work at a deeper level than this, determining precisely how a widget is drawn to the screen - so if you happen to hate the way GTK looks, you can now override that with something much sexier and *nix-like, or even with something that makes your applications appear to be native. One notable side-effect of loading a theme engine is that the strange cursor behaviour normally seen on PHP-GTK applications under win32 is eliminated in several widgets - regardless of which engine you choose to load.
All you need to do to load one of Christian`s engines is add the lines:
putenv("GTK_DATA_PREFIX=full_path_to_phpgtk_dir");
putenv("GTK_EXE_PREFIX=full_path_to_phpgtk_dir");
gtk::rc_parse("relative_path_to_gtkrc");
to your PHP-GTK code and, to return to my earlier compiled example, you'll be rewarded with something like this:
Fig. 7: Using the `Brushed' theme
Further up and further in!
Naturally, all these (and many other) new adventures in PHP-GTK development are still undocumented, and that has to be the next field of attack. We really need to have a complete set of documentation for the current, stable version before we're faced with an entirely new version in the form of PHP-GTK 2. Although backward compatibility is always a major concern in both PHP and GTK+ development, GTK 2 contains almost an entirely new widget set alongside the old, and both PHP 5 and GTK 2 internals involve changes to the ways in which objects are created, used, and destroyed. There is now, and will be for the foreseeable future, plenty of room for active participants in PHP-GTK documentation, whether in the form of manual pages or in the form of Wiki snippets.
In summary, although PHP-GTK is in the unenviable position of having two sets of ancestral tribes, it's continually improving. If you have a project that requires a basic lightweight, cross-platform, database-friendly GUI, we have the toolkit to help you produce that right here, right now, and with a very gentle learning curve. If you're looking for something that can cope with more complex specifications, keep one eye on PHP-GTK. It's on the move.
Links and Literature
