Over the last few days, I finally decided to revisit the old OSInet PHP library, to dust it off somehow, and convert the class-based parts to PSR0 and the whole to what seems to be liable to become PSR1 at some point.

This library contains a zoo of function helping with PHP-GTK development, and three packages with their demo application:

Class Grapher

Build a graph of inheritance and interface implementations on a directory (and subdirectories) of PHP code

This package uses the Drupal Grammar Paser to parse code, and includes a Drush 5 plugin for easy use within a Drupal site, but can also be used to parse non-Drupal code, as long as the Grammar Parser - which does not depend on Drupal either - is installed in the include path.

It is a more complete version of the Drupal-only Class Grapher sandbox on drupal.org.

In the current version, graphs are generated using GraphViz. An extension to a client-side visualization tool like the Infovis toolkit should come someday. Suggestions for other client-side libraries welcome (please comment!).

Open Document Calc reader

This package provides a few classes and methods to extract the content of OpenDocument (LibreOffice, OpenOffice.org, ...) spreadsheets.

Finite State Machine

This package is used to build applications designed around a finite state machine, and is mostly intended for use in PHP-GTK applications, to provide asynchronous processing.

The demo application uses the PHP FTP extension to expose its asynchronous notifications in a PHP-GTK UI

After recent complaints in the PHP-GTK mailing list, auroraeosrose mentioned mgdm has set up a SVN repository for the docs, to ease working on them.

This new repository is available at
http://svn.thefrozenfire.com/phpgtkdoc/

I just found out a very strange PHP feature by browsing the PHP-GTK2 API with the Reflection classes : spaces can be used in some alien places, like variable names.

But the doc says you can't !

Well, try this in PHP 5.2.5, for instance:

With OSInet focusing more heavily now on Drupal services, the company is now offering internships for students interested in working on Drupal.

First things first, I've offered to mentor for the Google Summer of Code, and would be specifically interested if a student picked up the live Drupal backup project if it came to be approved.

With OSInet having a large part of its business with suppliers and customers within the EU at large, I often find myself having to check the validity of the VAT information for third parties, and the EU VIES database comes in handy.

However, although I had been discussing remote access using XML-RPC or SOAP as early at 2004 with the database administrators, the UI had remained web 1.0-only until quite recently (apparently march 2007), when an AXIS SOAP service went online, just as I had suggested three years ago. So I figured I really couldn't let the occasion pass, and did a PHP-GTK client to VIES, which happens to be my first production SOAP application in PHP-GTK, previous ones having always been done in Pascal using Delphi or Kylix.

Let's see how this can be done... (code updated 2010-09-21)

I had been in need of a class to read config data into both the PHP-GTK OSInet back-office front end, and the back-office client UI for the Drupal 5.x offload module, and hesitated between various solutions, ranging from roll-our-own to the various frameworks out there and the existing PEAR packages.

Since Zend Framework appears to be well on its way to becoming a standard for professional PHP developers, I figured I'd give it a spin :

A discussion these days on the PHP-GTK general mailing list revolved around the issue of feeding a large amount of rows to the model bound to a GtkTreeView.

The PHP-GTK community site has been running on Drupal 5 betas since its creation one month ago, and I thought it really needed a live chart of statistics to match its glorious Garland dress, and GD would allow it. But how does one go about creating charts within Drupal ?

.

A few days ago, I was glad to learn that this blog had been included in the Planet PHP blogroll. And today, when checking the news, what did I see ?

The problem: while coding PHP-GTK apps, the most elementary debugging method is to use echo or print statements. These are fine and dandy for english or usonian coders, but may be a problem for coders elsewhere around the globe, since PHP scripts are typically stored under UTF-8 encoding to limit i18n headaches, while the console in which their output will be displayed is normally configured to some regional encoding, like IBM850 in Windows/XP French.

So we need a workaround...