So its Tuesday afternoon prime time on Planet GNOME, here’s an inside look on whats been going on this week for Glade.
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:
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:
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.
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.
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.