Version 11 of Loading Glade UI Confgiuration Files into Tcl/Gnocl Applications

Updated 2009-11-23 12:56:50 by WJG

WJG (26-Mar-09) One of the features added into Gnocl 0.9.94 is the import of Glade files and there are some expiremental scripts in the present release to illustrate the power of using Glade files.

Glade is a Gnome developer application which allows for the visual creation of detailed UIs drawing upon the wide range of Gtk/Gnome widgets. The latest release of Glade [L1 ] may even have support for other popular third party widgets. The resulting layout is saved as an XML file and be easily loaded into a tcl script using the gnocl::gladeXML command. At the moment this feature is still under development and much work needs to be done on settling upon a strategy on how to bind the UI signal callbacks to scripts on the Tcl side of the interpreter.

Whilst I personally have steered away from using visual UI builders and prefer the direct approach of scripting, for the vast majority of Gtk developers Glade is a 'wonder-tool'. Incorporating full support for both Glade and GtkBuilder would place Tcl in a good position in the Gtk bindings stakes as Gnocl would really come into its own, not merely as a UI builder, but enabling the runtime reconfiguration of widget which is complex using C.

tb 2009-03-26 - Me Too! I was thinking about just traversing the glade file using tdom and then returning some code, containing a window creation procedure and some callback handler stubs.

Package example:

 namespace eval ::sysdlg::file {
   eval [::gnocl::tclFromGlade ""]
 package provide filedialog 0.1

Now, one could load the package, lookup the callback handlers like...

  info proc ::sysdlg::file::handle*

...and start overwriting the stubs. Ready!

WJG (26-Mar-09) Yes, I've looked at tdom and, found it more reliable. You see, if Tcl has conflicting object orientation extensions, then Gtk has conflicting UI xml files. There's glade and builder. Both types can be valid XML (according to tdom) but not necessarily loadable (although matters might have eased since the near simultaneous release of new versions by both the Glade and Gtk development teams). But, for Gnocl to work well, we need access to widgets from their Tcl names and the ability to script the callback signals which libglade and GtkBuilder would not do for us. So, step in tdom. As you suggest, parsing the XML file and making assignments is quite straight forward. Here's a Glade snippet which relates to the addition of a button to an existing button bar:

 <widget class="GtkToolButton" id="add">
    <property name="visible">True</property>
    <property name="sensitive">False</property>
    <property name="label">Add Event</property>
    <property name="stock_id">gtk-add</property>
    <signal name="clicked" handler="on_add_clicked"/>

This would correspond the following line of Gnocl script:

 $toolBar add item \
   -visible 1 \
   -sensitive 1 \
   -text {Add Event} \
   -icon "%#Add" \
   -onClicked on_add_clicked

Straightforward, eh? As can be seen there are some option names which are more inspired by Tk than the GtkWidget properties to which they map. In fact, when they are at variance there can be a lot more hidden than meets the eye. The %# prefix for the icon, for instance, tell us that it is a stock item from the current Gnome theme. This could equally be an image file stored on disc as supported by the GtkImage libraries. Some widgets, like the gnocl::text, gnocl::tree and gnocl::list widgets are in fact pretty well mature megawidgets which would produce some unsual effects if used in the way listed above. But, adding support in terms of new Gnocl library functionality for the instancing new widgets, assigning properties and registering them with the interpreter should not be too problematic. Its the error checking that is the nightmare but would be usually handled by Glade itself as any compiled C code application loading a glade file would not check the validity of the XML file either.

Maybe you're interested in taking this project further? XML gives me a headache but I'd be only too delighted to co-operate with anyone who enjoys it.

tb - Hi, I did some investigation over the weekend. To me it seems a job of translating Gtk widget class names to Gnocl, while traversing the "child" tree of the glade file. There are lots of implications, like for example most properties with an underline character in their names don't exist in Gnocl. Though using rules and translation tables isn't the best way, because things might change over time, I don't see a real robust solution at the moment.

WJG (20-Mar-09) Thanks for taking a look at the issue. Its not as problematic as it would seem. Each one of the GtkProperties has a Gnocl C library routine associated with it order complete the wrapping process. A Tcl side solution, of course, is always on the cards and once the initial framework is in place most of the work would be quite straightforward, albeit laborious!

WJG (23-Nov-09) Put a little more time into the glade routines for gnocl this weekend. Previously, the gnocl libglade stubs just permitted the loading of the glade description file, now the the widgets are registered with the interpreter itself. All that remains is completing the job of assigning handler functions to the widgets created libglade. After that, the widgets can be directly configured using Tcl scripting. And, of course, widgets appended or removed. Here's the test script...

# gladeXMLTest.tcl
# William J Giddings
# 21-Nov-2009

# the next line restarts using tclsh \
exec tclsh "$0" "[email protected]"

package require Gnocl

set win1 [gnocl::glade glade]
$win1 configure -title "Calculator Renamed!" -onDestroy {puts "Done!" ; exit}


And the sample screengrab..

Keep watching this space... more to follow!