It was a saturday afternoon patch…

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 !

Do I really ever have to write another treeview again ?

You havent seen me blog in a long time, but that doesnt mean I havent been busy doing gnome stuff :)

there was alot of demand this year for a Glade that eats up and spits out GtkBuilder format ui definitions, this was undoubtedly hard for me to dish out so I missed the last stable release, but now we’ve got the mechanics in place plus a hand full of new toys to share. So heres a sneak peek at whats available in Glade for todays GNOME development release…

First of all, GtkBuilder – in general if you open a GtkBuilder file you just edit it in its format, if you need to convert your glade file, you need to pass through the project preferences dialog (Edit->Preferences):

Project Preferences

Setting the project format is undoable, and along with project target versions, will effect how the editors will react in glade (unavailable or warning highlighted widgets/properties by format and targetted version), I got a little carried away and brought you a fancy naming scheme control on the side. You’ll notice alot of the more commonly used editors have nicer formatting, we now have an iface that lets us format editor layouts by widget class (mostly we just add radio buttons with this), it also sports some ui candy; wrappy labels: long editor, short editor.

Another thing I had to do to get the show on the road was fix menus in gtk+ so that they would
build normally from GtkBuilder file input, I might be guilty of spreading roomers but there is a chance we’ll see that in a gtk+ stable release for GNOME 2.26… (currently native menus created by Glade will be depending on that release), oh yeah, we also have a simple editor in glade that applies pango attributes globally on your labels (without putting markup in translatable strings…)

Its worth noting what remarkable things you can do with GtkIconFactory, just create a factory, add icon sources to it, then use the newly created stock icons as stock ids in your widgets (its hard to make this feature obvious in Glade, it would really really rock if someone volunteered to write user documentation for Glade 3.6…), this feature allows you to define alternate graphics for your icon in different widget states, text directions etc (anyway, I was surprised by the obvious leverage after integrating that).

So I think the real question is “Do I really have to write yet another freakn treeview by hand ever ever again ?” … hehe, no I didnt mean to scare you, dont worry, you’ll never have to write one of those by hand again in your life :) heres a shot of the whole app with some views and a model:

Several views attached to a single model
Several views attached to a single model

Editing treeviews/iconviews/comboboxes takes a few steps, you have to create a data store, create cell renderers and sometimes columns, you have to define column types and optionally data in the store and finally you have to assing renderer attributes either to hard coded values or to indexes in the data store – I did my best to unify all of this into a single 2 tab editor, its totally based on Juan Pablo’s original menu editor, so it supports dynamic type changing of cell renderers, and drag’n’drop of renderers in a treeview to reorder them or drop them into other columns, on the face page it has the editor for the toplevel view widget embedded on the left, and the associated treemodel editor on the right that allows you to add columns to your data store and add and edit data in the store. On the second page it allows for adding and removing cell renderers, and editing thier attiributes:

set attributes to columns by name
set attributes to columns by name

This one will let you choose columns by name/type from the model for use as cell renderer attributes, I’m still having problems laying these properties out coherently, I would also like the combo box to stay small while the menu resizes to display the whole value (I’m using ellipsize=end when the combo menu is not popped down, and displaying the full text only in the menu)… anyway, this part is highly functional but needs some work in the ui ;-)

So that was a long time no see update on Glade and what we’ve been doing to it, in other news I have time on my hands so Im looking for some work (its pretty cold without a plane ticket in canada this time of year so I figured some planet roaming was in order) I put my text mode resume online today, in the mean time I got a great job helping the butcher at the supermarket shredding up meat all day, its spiritually calming honest grunt work and it sure beats relocating permanantly to california ;-D

dawn of the builder

Its been a long week, I went ahead and rewrote the parser code in Glade from the ground up, and then moved on to support dual formats, Im a little ashamed to say that this huge hacking experience was brought to you by coffee and cigarettes, for lack of *cough* other illicit substances that may have done better for my health, all grievances aside, it really is a nice piece of work I’d like to share with you all (its 7:15am Sao Paulo time and I’m blogging while cooling down and getting ready to sleep).

So lets see, what do we have ?

Well the new parser supports what Ive been calling class level definitions of xml layouts, in other words your widget library plugin is allowed to define, read and write properties and children in customizable ways, this was ofcourse needed to support the different formats that some widget classes are loaded from using GtkBuilder. We’ve also added an option, available in Glade’s edit menu, to decide which format your project will be saved in, Libglade or GtkBuilder.

Currently all widgets and properties formerly supported by Glade can now be saved and loaded in both formats. We dont yet have any support for the fancy GObjects now supported by GtkBuilder but VERY thankfully Johan has already provided a first try patch to get UIManager, our most awkward exception to load, this also must have been alot of work (and we may still need a few minor tweaks in the core to get it running). Other exciting things such as liststores and sizegroups should follow suit without too much of a headache. Another caveat is that Glade still has no idea what widgets are deprecated in the new builder format, which should be easy enough to remedy (glade will currently just save any widgets in the new format regardless).

This work is now available in trunk, and I do sincerely hope you all enjoy ;-)

Some popular features …

… that I finally managed to add to glade trunk today

So I finally applied a refit version of Yevgen Muntyan’s patch

One common source of frustration about glade 3 has been that, sure you can add your own widgets to the runtime but, you gotta write that catalog, install a support module, or struggle with your setup so that we can load the type from the widget library, but you dont want to write a widget library just for that one widget you got in your app so, here’s the solution:

you make a catalog that looks like this one note the “parent” element from the “glade-widget-class” definition, it choses which widget class your “fake” widget class will derive from.

then, since we now have user defined search paths for catalogs and modules; you put it wherever you want (it has to keep the .xml extention though), lets say ~/mycatalogs

then you fire up glade like so:

GLADE_CATALOG_PATH=~/mycatalogs glade-3

And voila ! you got your widget in the glade runtime.

Happy Glading !

Its release day !

Whew, its been a rocky road trying to wrap things up in
time for gnome-2-18, but with one
string freeze break
and one remaining
crasher,
Glade
is pretty much ready for the show

Incase you wonder what we’ve been doing in 3.1 ;-) well aside from
ironing out bugs in the framework as usual, we’ve been working on
the first version of the embedded workspace/one-window UI, which is
crash free except for the one I mentioned above, lets hope to see it
dissapear by 2.18.1… Juan has also been working on this bindings
framework – which is really a work in progress but proves that we
can easily load objects written in python and edit/serialize their
properties, C++ otoh proves to be a challenge…

Interestingly, I’m going to miss out on all the initial feedback
(complaints or otherwise ;-)) from the release… because I’ll be
chillaxing with the palm trees in florida for 5 days ! where
I’ll be attending one of the worlds biggest
breakdance competitions; so have fun untill then, I’ll be back
on the 19th ;-D