Month: March 2010

It looks like this can be a good year for Glade !

A tale of Palettes

Among some other recent developments, one interesting thing is that the GtkToolPalette; which was previously EggToolPalette dating from 2008 by Mathias Hasselmann modeled to behave as a palette written for Glade by Vincent Geddes back in 2007 (drum roll…) : is now integrated as a drop in replacement for the original palette code in Glade !

This allowed me to remove 3 source files and 3 header files from the Glade tree, but not only that; it was also an enriching experience to see the improvements that have been made on the palette (the built-in drag/drop support, integration with GtkToolItems and better scrolling functionality was noticeable) and to think of all the bright individuals who put work into it from a variety of continents.

All that being said I think there still needs to be a generic way to do context menus for the palette, GtkToolbar exports something like this; currently we are stuck with something of a hack to get our context menus working.

Vertical Glade

Another event of interest this week is that Federico Mena-Quinero came around and showed willingness to fix Glade side effects on that nasty horizontifying bug. After short lapse of thought I agreed to throw away the “orientation” property from Glade and only support it for base classes which are not implicitly oriented – in short; Glade will not do that horizontal weird thing with .ui files that fail to mention the orientation explicitly (likely converted by gtk-builder-convert stript…).

Sponsored by Openismus

It’s truly a pleasure to announce that the GtkToolPalette integration patch along with a few other bugs I closed yesterday are  only the first patches in an effort sponsored by  Openismus GmbH. This effort will be focused partly on Glade and partly on GTK+, I’m very excited and determined to make the most of this time improving GNOME.

Follow my blog for details and updates 😉

So I took another Saturday afternoon to look after the whole composite thing I started hacking on last week. It’s surprisingly not a lot of work to do in terms of lines of code written.

First, I went and enhanced GtkBuilder so that you can add a parent widget context to the parse; this way while parsing GtkBuilder fragments you can start them with the <child> tag instead of <object> and have the builder parent the serialized children onto a dynamic runtime instance (in our case, a composite container widget).

Second, I trashed gtkcomposite.[ch] and integrated the code into GtkContainer (following Rafael Villar Burke’s advice); this way any already existing container widget can be extended as a composite widget.

Third thing was, as Torsten Schoenfeld pointed out was missing, I added api for bindings to assign a GtkBuilderConnectFunc to be used on a per class basis, this means that for instance, composite widget code in GTK+ gets connected with regular C callbacks, but derived code of that same widget in another language gets to use a connection algorithm specific for that class vtable for that language… which brings me to..

Finally composite classes can also be extended and each class can optionally pull in a .ui template to define its children, which means with some added magic of gtk_container_get_composite_child() to pull out implicitly defined composite children, GtkBuilder has no problem to “blend in” widgets added from subclasses into internal composite containers exposed from a composite parent (I added a new test case to the bug describing this).

For those who are wondering what the hell kinda crack this guy is cookn’ up, basically… its an api of GtkContainer that lets you associate a GtkBuilder .ui file with any container class you define, automatically assigning any property endpoints you define to the corresponding instances built from the GtkBuilder fragment – at construct time, for free – an effort to completely abstract the packing of widgets from user code, and hide GtkBuilder semantics under the hood.

Thats it for me today… I hope you’re excited !

So it was saturday afternoon this weekend, and I was already tired – of reading all crap being thrown back and forth at one another on our own foundation-list,  that is really a shame because it looks like we could be ready to make some real changes and set a better directive – or at least our OWN directive for GNOME as a foundation – for us – for the hackers.

Obviously feelings are mixed in this debate, and before people started throwing crap at eachother, for misrepresenting each other and correcting each other and basically looking like very professional and like pompous asses, there were some interesting things said. This post by Dave Neary was drowned out in noise twice so far and thats a shame, hopefully linking to it here on planet will help to give his post a better audience, personally I really love the “dangerous and racy” proposal/idea: GNOME hidden in plain sight, if you like you can read why in my post – in a nutshell I think our code base suffers from popularity and we end up writing results-oriented software because of it – because we end up working on what “downstream needs now” instead of the innovative future technology that we should be working on… and everyone here has worked for a corporation – we know that results-oriented code gets thrown in the garbage.

So – partly because I think people are sore about the whole mobile thing (silly but true), and partly because it seems like a perfect time to innovate, and partly because I just miss the days when we would argue vehemently on gtk-devel-list about future apis and if they were perfect enough or what… I think we need a bit more of that excitement in general, to attract more serious hackers, and make GNOME by GNOME for GNOME – an umbrella for free software projects to really get the space, infrastructure and as Dave so elegantly put it; the “stewardship” that these projects need to really flourish and innovate (ok misrepresentation mittens on, no he didnt say “stewardship” exactly like that… but I’m borrowing the word for today).

So because of all those reasons above I just LOST IT and wrote a patch, the patch is something I had in mind for some months now and I’ll try to explain in human terms as best I can what this patch does.

The patch introduces a notion to GTK+ that a GtkBuilder file can be associated with a Widget Class, when a widget is built with a template.ui file assigned to it, then any instances of that class will come with its composite hierarchy prebuilt, signals from its child hierarchy connected to its own class methods – and instance variables already preinitialized to access desired components of a composite widget’s children.

And I need people who implement language bindings to look at this 🙂 ideally, how it should look in super-duper object oriented language ‘x’, would be something like this:

class MyClass:GtkComposite {
    var someObject:GtkAdjustment; // some instance variable
    connectable var someLabel:GtkLabel; // A "connectable" instance variable

    function the_button_clicked (var button:GtkButton) {
        someLabel.setText ("the button was clicked");
    }
}

So, for the user – the idea is they compile a class MyClass, and hopefully he doesnt have to say anything explicit, i.e. when the compiler/interpretor finds that MyClass.language has an accompanying MyClass.ui – the ui should just be compiled into the class and the above code should “just work” after instantiating a “MyClass” object.

For the language binding – it would mean that the language binding would have to install GtkParamSpecComposite properties onto the GObject it creates under the hood for a derived GTK+ widget class (i.e. Im sure this will work for vala but others… dont know) – this way the language can introduce the “connectable” keyword which explicitly asks for a property name <–> child instance name association before any user code runs.

For the devtools front, it means we can have a tool like Glade add a feature that lets you rip out a sub-hierarchy and implement it as an object class in the user’s language of preference, the sub hierarchy would become an independant Glade file and can be re-included with its hierarchy at multiple places in the program/UI.

The general idea of this patch is to push GNOME devtools/GTK+ apis towards catching up with the industry leaders in UI tools, its a migration of coding practice in GNOME uis all across the board.

We can move from: old-school “kinda dynamic” interfaces where an object loads an interface explicitly and then plays god on the widgets, connecting to signals and making the whole thing move from some controller proxy object, or worse, not modular and handle all callbacks in a main “application bussiness logic” zone.

To: A world where if you need a widget to have different functionality – you add to it – always by inserting your code onto the object running in the interface – if you need a form with lots of entries and an OK button – thats a Composite widget, can be reused over and over without any added hassle of using a controller object, can be derived and extended like any object, no controller proxy, no hassle – just a UI inside a widget fully functional after g_object_new() time.

So lets create some hype and lets do some real innovations – we could very easily come up with some tools that leverage GObject and GTK+ in modern ways and smash the competition (I’m thinking Xcode/Interface Builder as an initial “beat them” target, hey what if we had the same API usability and integration of IDE tools, but we werent restricted to Objc, or Cocoa api, and we compile everywhere, and we support every popular language… what could beat us then ?)

Well as I said we need to create some hype – bugzilla is okaaaay but I started a thread for this on gtk-devel-list, ofcourse in the hope to turn some heads and get ṕeople excited about GNOME… please jump in !