One week of Glade brought to you by Openismus GmbH

So its Tuesday afternoon prime time on Planet GNOME, here’s an inside look on whats been going on this week for Glade.

Runtime Warnings

Last week we got the GtkToolPalette integrated into Glade and got Glade vertical again, this week I went on a rampage of hunting down startup warnings, warnings caused by loading Glade files and generally any warnings/assertions that can be fired while manipulating projects in Glade.

That effort left us with a couple interesting side effects:

  • Now we introspect if widget classes are scrollable and we don’t allow adding non-scrollable widgets to scrolled windows
  • Now we update treeviews in the workspace seamlessly when the underlying treestore columns are redefined
  • A nasty data corruption bug occurring when loading liststore data that contains gaps (missing unserializable columns) was also fixed.

Once these items were fixed I was pretty much left on my own to fix some issues of my choosing and improve some things in Glade – awesome – so I decided to prioritize on issues that did not need backing support in GTK+, as there has been lots of development there that we haven’t been able to keep up with.

The signal editor

The first issue I decided to tackle was the ‘swapped’ attribute for signal connections defined in Glade – that’s right, until this week Glade was never able to read/write this attribute. To illustrate the importance this has in Glade I want to show you a before shot:

The "before" signal editor

Ok so the editor looks alright at first sight but there are some confusing aspects, for instance the “user data” in the signal can only ever refer to an object in the Glade file – no mention of that is made. Furthermore when one goes through the whole google research to find that the user data is supposed to be an object, they immediately get stumped by GTK+ swapping the object at connection time for seemingly no desired reason – very, very confusing.

Something to keep in mind as well is that signal definitions in Glade have generally been unused. Mostly because of an inability to pass data external to the Glade file as user data to callbacks. Generally people use a parent or controller object as a module pointer to be passed to all callbacks; this technical problem with signals has really been a non-issue ever since the introduction of the gtk_builder_connect_signals() api which takes a default pointer argument to pass to signals for just this purpose.

Well, moving on – after adding the “swapped” attribute to the editor I was quite unable to tear myself away from the editor, it hasn’t seen an update in many years and has been lagging behind the rest of the UI, so without further adieu I present to you:

The "after" signal editor

Now the signal editor is doing a bit better, I didn’t have the time for a full scale rewrite using GtkBuilder for its store, view and renderers as I have been hoping to do for a while but – at least she learned some tricks from her big brother the property editor:

  • Now the signal editor lets you view the documentation for a signal at the click of an icon (Thank you Frédéric Péters for getting DevHelp page contextual searches working again ! sorry for waiting 6 months+ to notice !).
  • The editor does not let you type text for connected objects for user data, instead you get an object selection dialog
  • Now versioning support icons/tooltips show up for signals that are introduced in the future of your project’s target version.
  • Tooltips explaining about the signal editor fields show up on the treeview column headers
  • Signal, Handler and Object fields in the editor are user resizable but allocate a reasonable size.

Actions

So, with a rocking new signal editor in master I still had some hours to kill, I went on to tackle the relationships of GtkActionGroup <–> GtkAction in Glade – I wasn’t able to pull out a customized editor for this yet, but I imagine it will look like the menu or toolbar editor and allow hierarchical configuration of the project’s action groups/actions (currently Glade will only let you add an action to a group via the Inspector widget: Right click -> Add widget here / Paste commands will do the trick).

Glade now also lets you set an accelerator key for a GtkAction, the property only applies to actions which are placed into a group, ideally this will be the ultimate place to define accelerator keys using Glade so that they integrate well with menus and toolbars.

Thank you

A big thankyou to Openismus GmbH who sponsored the project and made all of these unlikely advancements in Glade actually happen.

I’ll be turning my attention away from Glade this week to look at some other serious GNOME issues, keep up with my blog for regular updates on this Openismus sponsored effort.

6 Responses to “One week of Glade brought to you by Openismus GmbH”

  1. suryaden says:

    glad to hear this, and can’t wait for awesome GNOME

  2. antimonio says:

    Why improving Glade if it’s being deprecated?

  3. tvb says:

    Antimonio,
    libglade is being deprecated in favor of GtkBuilder.

    please check out our website for more information about Glade.

  4. antimonio, libglade is deprecated. Glade is not at all deprecated. Glade can use either the old libglade or new GtkBuilder file format.

  5. I really enjoyed your article and would like to know if I provide a link back to your site if I can use your article on one of my sites?

  6. tvb says:

    I’m sorry it took me so long to get back, I had disabled email notifications as I was suffering from lots of spam…

    Sure I have no objection that you cite my blog and link back to it.

    Cheers,