Page 1 of 1

phpGTK applications?

Posted: Tue Jul 25, 2006 8:46 am
by neophyte
I've never used phpGTK and never heard of anyone else using it either. I understand its a PHP interface for GTK. I'm just wondering has anybody used it to create an app? What's your opinion of it? And do you know of any applications that use it? There site ( http://gtk.php.net/apps/) doesn't show any applications built with phpGTK.

Posted: Thu Jul 27, 2006 9:19 pm
by neophyte
Hmmm Just as a note: the just released issue of PHPArc has an indepth look at phpGTK2..... Looks interesting.

Re: phpGTK applications?

Posted: Fri Jul 28, 2006 12:57 am
by alex.barylski
neophyte wrote:I've never used phpGTK and never heard of anyone else using it either. I understand its a PHP interface for GTK. I'm just wondering has anybody used it to create an app? What's your opinion of it? And do you know of any applications that use it? There site ( http://gtk.php.net/apps/) doesn't show any applications built with phpGTK.
I've played aorund with it...

The idea isn't really solid though...

GTK is a abstraction library, which I believe is cross platform (NIX & WIN)...which makes working with Windows (as in actual window, not the OS) easier...

Basically, by offering a cross platform wrapper/abstraction layer, you can easily port from one OS to another...

So, under linux, using native funciton calls, one might create a XLib window like this:

Code: Select all

XCreateWindow(display, parent, x, y, width, height, border_width, depth, class, visual, valuemask, attributes)
While under Windows, you would create a window, like this:

Code: Select all

HWND CreateWindow(          LPCTSTR lpClassName,
    LPCTSTR lpWindowName,
    DWORD dwStyle,
    int x,
    int y,
    int nWidth,
    int nHeight,
    HWND hWndParent,
    HMENU hMenu,
    HINSTANCE hInstance,
    LPVOID lpParam
);
Both are quite different and both might require different initialization, I know from experience that hand coding a Windows window is quite a tedious task and complex if you don't understand the Windows system. Likewise XLib is also complex and supports networked windows I believe, which would only further complicate things...

GTK and the plethora of other abstraction wrappers, serve to basically wrap each platforms native functions under a single unified function call

So the GTK code might look something like:

Code: Select all

GtkWidget* pWidget = gtk_window_new(gtkType);
By specifying at complie/preprocessor time (using directives) which OS you wish to support GTK could possibly include the appropriate API, Windows, XLib, etc...

PHP, is not a compiled language, we know this, well it can be, using RoadSend and GTK, but typically I imagine PHP/GTK+ bindings work something more like this:

PHP script (index.php) must be executed by the PHP CLI, and therefore, every time you call PHP CLI an application instance is started.

PHP is still being executed under the gun of the PHP interpreter, parser, etc...

But it has bindings or an interface for also communicating with GTK C/C++ interface...

I imagine this works much like PHP extensions which are written in C...

When you compile PHP with and XML extension, you then have PHP callable interface to work with XML files using a faster binary function...

MySQL is another good example. You call the C/C++ MySQL API using PHP...

The PHP parser does something like:

1 - Parse the PHP
2 - Determine loaded extensions, bindings, etc...
3 - Call the PHP extension function
4 - Perform data type conversion of PHP loose types to C/C++ strict types
5 - Pass converted parameters to actual C/C++ MySQL API
6 - Get results from MySQL API and convert back to PHP types and return to PHP

It's a PITA for sure...but thats how I would guess bindings & extensions would work...

ZE likely offers functions which do alot of this jaxx for you, but still...

The downside to using this approach to writing applications using PHP & GTK natively, is that, GTK is itself an abstraction layer...

PHP, is, a highly abstracted language when executed under the command of it's native interpreter...so thats an additional performance hit ontop of GTK itself...

PHP is not designed for desktop development, as being an interpreted language makes it easy for your users to bugger up source code and start calling tech support...

One application would require multiple modules, and those modules are open for editing, which is asking for trouble...

As a web development language, your users don't have ability to modify source...as it's stored on a remote server...PHP succeeds because of this caveat...

Basically it's missing that critical compliation step, which takes an applications resources, source code, etc and bundles it all into a single entity for simple and easy execution...

Windows, etc wouldn't know, by default how to get a PHP application going, but I suppose you could easily configure a desktop link to fire the PHP CLI and execute a given script and emulate a Window'ed application...

It's just not ideal, for the reasons I listed above...

If your interested in writting desktop applications using GTK I suggest looking into Roadsend compiler...which I believe supports Gtk...

These are just my opinions of course and I do not gaurantee their accuracy...but it hopefully gives you some insight and perspective as to why PHP Gtk possibly hasn't take off as a development combination...

Cheers :)