Letter to Community

Dear PHP-GTK community, I have just read the extensive "what is going on with gtk.php.net?" thread that Steph has brought to my attention and I have to say this: I'm sorry. It is apparent there is an impression out there that PHP-GTK has been relegated to the convalescence home of dying open source projects. Mostly it is my fault, as I have been absent from the scene for entirely too long. All I can say in my defense is that in the last year I had moved to another coast, switched jobs, started a new relationship, and have generally been busy pursuing other interests. Hopefully, you've been in the same situation and know what I am talking about. Might not be much of an excuse, but that's all I have at the moment. Steph, in her infinite patience, has possibly been the only person who has been investing any significant amount of time into PHP-GTK by fixing the docs, answering emails on the mailing lists, and poking me from time to time to find out when I would be back. For that, I think we all owe her a debt of gratitude. Without Steph, this project would be quite dead indeed. But, let me also say this: PHP-GTK has not and will not be abandoned. It has been made clear from the thread that there are a lot of people in the world using it for things that I, frankly, could not have imagined when I started tinkering with the code almost 4 years ago. And seeing the renewed interest in the project with the release of PHP 5 I cannot help but be inspired by the energy that is suddenly circulating through our little community. So, what's to be done? Clearly, the documentation is lacking. Obviously, it is an enormous effort to document all the classes and methods that PHP-GTK inherits from GTK+ in addition to its own idiosyncrasies. Simply linking back to GTK+ manual is not a solution as that manual itself is quite incomplete. So, what seems to me to be a good approach is to invest some time and effort into either fixing the current documentation system and continuing the course or rebuilding it to use Livedocs. Whatever we do, we should probably be compatible with the PHP documentation project to facilitate reuse of tools and technologies. Everyone says that PHP documentation is simply great, but how did it get to be so great? Through efforts of regular users and developers who self-organized into teams of documentors, administrators, user note maintainters, etc. Of course, the PHP doc project consists of many people, but I remember when there were only a few folks who even knew how to build the docs. We are basically in the same position right now, but we have the advantage of hindsight and can draw on the best practices of PHP docs team as well as learn from their mistakes. Website can also be improved. Ben Ramsey has offered to work on it, and I couldn't be happier to hear that. It would be even better if we had 2 or 3 people maintaining the web site as there is a lot of good PHP-GTK and GTK+ information out there that the website simply does not link to. It is, after all, supposed to be the central repository of all PHP-GTK knowledge. Improving search, moving Wiki to be hosted on gtk.php.net, and implementing a semi-regular news system would be something to do as soon as possible. Beyond that, I will leave the ideas for how the website should function best to those willing to work on it through collaboration and consensus. Borrowing ideas from php.net, go-mono.com, and other sites should not be viewed as a bad thing. This may sound familiar, but I think that my personal strength lies in developing code, rather than designing web sites or writing documentation. So far I have been waiting for PHP 5/Zend Engine 2 API to stabilize, and now that PHP 5 has been released, I believe I can re-start work on PHP-GTK 2. However, it is not going to be a straightforward port of PHP-GTK 1 because Zend Engine 2 offers much better ways to exploit the power of object orientation and we can build a very slick interface to GTK+ if we start from scratch. I am going to start thinking about it and posting RFCs on the mailing list in hopes of soliciting feedback from users as to how this interface can be best structured. Consider the connect() and connect_object() functions (a source of much confusion apparently): There is no reason that the second one needs to be called connect_object() aside from the fact that that is what GTK+ uses. So, one of the first questions will be, do we stick to GTK+ API rigidly or do we replace/rename some methods to suit us better? As far as project structure goes, perhaps we could have 3 loosely organized teams: development, website, and docs, each one headed by an informal leader. I nominate Steph for the docs team which will probably leader to her kicking my virtual butt. :-) Well, I'd better wrap up. The recent activity on the lists makes me think that people are willing to contibute to the project. Of course, how much time we can contibute is the biggest issue. No one can make you share your time, effort, and goodwill except yourself. I just hope that the ant analogy holds and piece by piece, grain by grain, we keep building this project up. As Ben said, let's not let the interest die out, And to paraphrase JFK, ask not what PHP-GTK can do for you, ask what you can do for PHP-GTK. The project cannot die until the last one of us loses interest in it. Talk to you all soon, -Andrei Documentation is worth it just to be able to answer all your mail with 'RTFM'. -- Alan Cox