I don't know if anyone ever reads this journal. /. just doesn't seem to be that kind of place. I'm just writing to announce that Gt is on track and partly working. Signals and slots are there and the basic framework exists - now there are two things left polishing the framework and wrapping GTK+. Sounds like fun!

Ah, the link is: http://www.digitalfanatics.org/projects/gt.

Ok, it was a while since I entered something into my journal (I think that the new verb is "blogged"). This is just a small update.

Gt has a moc, it works, but the exception handing (and thus the error feedback) is not good. It will be available from http://www.digitalfanatics.org/projects/gt/.

I've written (or rather, am writing) a Qt tutorial. I've had good feedback from it, please check it out at http://www.digitalfanatics.org/projects/qt_tutorial/.

Finally I'm working on my first large open source project. It is fractal related. I want to enter a competition with it, but as soon as I've submitted the first version I may (and will) publish the source. It, too, will be available from http://www.digitalfanatics.org.

After thinking alot about how to manage signals and slots in Gt I have decided to redo the project, but in a more Qt-like way.

The following issues have come up:

• A moc makes things easier and better looking.
• A moc can easily be implemented in Perl.
• A moc makes it easier to wrap GTK into Gt.

I intend to write a moc-like tool (with support for signals and slots) producing code with the same functionality as Qt's moc. This moc will be freely available and GPL'ed without any restrictions on the resulting files.

The moc will be easy to build if the following conditions are met:

• One mocable class per file.
• Nice types, i.e. the same restrictions as in Qt's moc.

I wonder if there are any legal risks in doing this. Trolltech might be pissed... :)

I've gotten some more time to fiddle with GObject/GWidget and to try getting the signal/slot mechanism to work properly.

Now it seems to work, you can test connections and actually call 'em. The pointer can be of another class, e.g. a GObject pointer can dispatch signals in a GWidget object without knowing of them.

It seems to be possible to automatically generate code that works with this. I've tried with the Bin, Container and Button classes and got it to work without too much tweaking.

The basic parsing and automatic wrapping of GTK+ into C++ classes is ready for use. I've begun a rewrite of the basic Gt classes.

I begun this project by wrapping parts of GTK+ into Gt and designed a class hierarcy around this that gave me signals, slots and events. In order to get the GTK+ to Gt wrapping to work better, I've decided to rewrite these classes.

What do I offer? I have a GObject with safe pointers, automatic deletion of children, etc. Also, a handmade Gt widget serving as the base of the entire GTK+ class hierarcy.

The only main hurdles left are these:

1. Get the basic classes to work perfectly (GObject, GSafePtr and GWidget).
2. Get the automatic wrapping to work 100% (all GTK+ widgets will work without patching).
3. Write a GPainter wrapper for GDK to make the porting of Qt/KDE widgets easy.

Then there is just one point left: get people to use it!

I've actually tried my huge Perl hack to see if I can produce any good C++ files. There have been some minor hickups, as expected, but nothing major. The only big headache for the moment is constructor resolving.

For example the gtk_button class (GButton in Gt) has two constructors (well, three, but two automagically detected): gtk_button_with_label and gtk_button_with_mnemonic. The problem is that both accepts a string as the 'additional' parameter, i.e. I've got two identical constructors doing different thing. This is however easily resolved as the _mnemonic version simply is a cooler (more features) version of the _label version. Thus, I have to resolve this by removing one of them.

Some thoughts halfway though the project. It seems like everything aught to work. In order to make the automagical conversion tool work with new versions, I need to be able to fix small problems and store the fix somehow. This is to avoid having to do the same adjustments over and over again.

As for the resulting code, you can always enjoy this. (Notice that this is still in alpha version, so not much is working yet...) The types of the properties is also missing (not retrieved by the script yet) but it is a quick hack to get it working. As for all the macros, yes, the pre-processor will be heavily utilized to avoid the need of a moc, but I don't know how far one can go with this solution.

The editor ate my tabs. The code will be neatly indented!

--- HEADER ---

#ifndef GBUTTON_H
#define GBUTTON_H

#include "gtmain.h"
#include "gbin.h"

// The GButton class
// Wraps GtkButton
class GButton : public GBin
{
GOBJECT
GSLOT( activate )
GSLOT( clicked )
GSLOT( enter )
GSLOT( leave )
GSLOT( pressed )
GSLOT( released )
GEND

public:
// Constructors
GButton( GWidget *parent=0, char *name=0 );
GButton( <typ> label, GWidget *parent=0, char *name=0 );
GButton( <typ> mnemonic, GWidget *parent=0, char *name=0 );

// Slots
virtual void activate( void );
virtual void clicked( void );
virtual void enter( void );
virtual void leave( void );
virtual void pressed( void );
virtual void released( void );

// Properties (first set, then get)
void setRelief( <typ> )
void setLabel( <typ> )
void setUse_stock( <typ> )
void setUse_underline( <typ> )

<typ> relief( void );
<typ> label( void );
<typ> use_stock( void );
<typ> use_underline( void );
};

#endif
--- BODY ---
#include "gbutton.h"

GSIGNALEMITTER( activate )
GSIGNALEMITTER( clicked )
GSIGNALEMITTER( enter )
GSIGNALEMITTER( leave )
GSIGNALEMITTER( pressed )
GSIGNALEMITTER( released )

GButton::GButton( GWidget *parent=0, char *name=0 )
{
this_widget = gtk_button_new();
}

GButton::GButton( <typ> label, GWidget *parent=0, char *name=0 )
{
this_widget = gtk_button_new_with_label( label );
}

GButton::GButton( <typ> mnemonic, GWidget *parent=0, char *name=0 )
{
this_widget = gtk_button_new_with_mnemonic( mnemonic );
}

virtual void GButton::activate( void )
{
}

virtual void GButton::clicked( void )
{
}

virtual void GButton::enter( void )
{
}

virtual void GButton::leave( void )
{
}

virtual void GButton::pressed( void )
{
}

virtual void GButton::released( void )
{
}

void GButton::setRelief( <typ> value )
{
gtk_button_set_relief( this_widget, value );
}

void GButton::setLabel( <typ> value )
{
gtk_button_set_label( this_widget, value );
}

void GButton::setUse_stock( <typ> value )
{
gtk_button_set_use_stock( this_widget, value );
}

void GButton::setUse_underline( <typ> value )
{
gtk_button_set_use_underline( this_widget, value );
}

<typ> GButton::relief( void )
{
return gtk_button_get_relief( this_widget );
}

<typ> GButton::label( void )
{
return gtk_button_get_label( this_widget );
}

<typ> GButton::use_stock( void )
{
return gtk_button_get_use_stock( this_widget );
}

<typ> GButton::use_underline( void )
{
return gtk_button_get_use_underline( this_widget );
}

I've been working on a script to automagically wrap the GTK+ classes into a C++ suite. First I started with the GTK+ header files, but they do not provide all the info, so now I'm going after the html documentation.

I've got a small bash script to find the interesting files, then, for each such file, a Perl scrict is called. This perlscript is supposed to find all properties, events, relations, methods, etc. and simply output a class header and an implementation.

With my current version I find all the info that I need, but I only present it as a table. The next step will be to exchange the backend with a C++ code generator and hopefully, simply compile away. I know that their might be some fuzz with the GWidget base class, but doing 1 class out of 120 is pretty good, compared to that I actually concidered doing it all by hand.

I would like to thank Larry Wall and everyone else who has made Perl such a nice and powerful language!

I really hate the autumn and the change from summer time to standard time.

A few weeks ago the mornings went dark, the dawn dissapeared into a red sky which shifted into a dark blue shade until all I could see was the stars. It isn't a nice shift to see the sun appear lower and lower on the horizon each morning until it is finally gone.

Then comes the standard time along. I get to sleep one hour extra (which I needed) and the sun came back in the morning. One problem only, the afternoons went dark instead, so no sun in my spare time, unless I suddenly begun to get out of bed unnaturally early.

The other problem with the standard time is that once again I have do endure seeing less and less sun each morning, until today.

Today the sky was black, I could see some of the brighter stars, and I know that when I return home all I will see again is stars. The only happy part about this is that I sit next to a window at work, so I get to see the sun for a few hours, but only through a window.

Enough with the depressing stuff, it is less than two months for christmas, and I'll have a nice vacation and hopefully a nice layer of snow to look at (and throw at people).

I've begun wrapping GTK+ in a Qt-like frameword. I've got the connect and emit functionallity that I want, but the code is still a bit too verbose. I hope to achieve two things: 1) A nice looking, easy to use, library and 2) A somewhat Qt compatible alternative so that I can port my software easily.

Why am I doing this? Because I want to charge for my software. As thinks look today, I will probably not be able to live from consulting (customizing open source solutions), but I will have to make some other income. Since I cannot (yet) afford a proper Qt license, I'll just have to make GTK+ (which is LGPL) (IMHO) better looking.

How does the code look? Well, for starters, all objects are prefixed with a G, i.e. GMainWindow, GPushButton, etc. The connections are managed though the raw strings: connect( objA, "clicked", objB, "slotName" ). This is akward and needs to be resolved somehow. Also, parameters cannot be passed yet, and I'm thinking about skipping that part all together and just pass a void pointer, but perhaps I'll find the time and get the urge.

I'll make it look good and wrap up most of the useful components, and also (very important!) implement a GPainter object, then publish it as LGPL. For the wrapping I've created a small script that makes most of the work. All simple widgets such as labels, containers, buttons etc. can quite easily be wrapped. I do however want to do this completely automagically, i.e. feed the script a GTK+ header and recieve a Gt header and most parts of a body.