[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 [http://glade.gnome.org/] 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 "filedlg.glade"] } 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: True False Add Event gtk-add 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] (21-Nov-09) Returning to the comments made by [tb] above. Rather than parsing the glade file an building a gnocl script equivalent, I've followed the route of loading the glade file and registering the new widgets with the Tcl interpreter using existing gnocl library calls. To do this I've worked through the glade gui widget trees obtaining pointers, names and widget types. During the registration process, the new widgets are supplied handlers, again from the existing libraries. This means, that once loaded, the various parameters can be set and modified using the established scripting method. ---- [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 #--------------- #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" package require Gnocl set win1 [gnocl::glade glade calculator.glade] $win1 configure -title "Calculator Renamed!" -onDestroy {puts "Done!" ; exit} gnocl::mainLoop ====== And the sample screengrab.. [http://lh4.ggpht.com/_yaFgKvuZ36o/SwqGbOXRLyI/AAAAAAAAAKw/brqGSzFCucw/s800/Screenshot-Calculator%20Renamed%21.png] Keep watching this space... more to follow! [RLH] That is most awesome! [WJG] Thanks. I'm quite pleased with this one. Although I personally prefer scripting GUIs directly, I know that a lot of potential Gnocl users are waiting for a bridge between Tcl and Glade/Guibuilder. Looking at the library functions it might also be possible to 'dump' GUIs out to a glade file. This would be a useful development as it would enable GUIs built or protyped in Gnocl to be reused in other applications. One feature that might also be useful is that selected 'parts' of a Glade based GUI, eg a particular toolbar layout, can be picked out and selectively reused. [tb] Amazing!!! - A big step towards rapid prototyping of Gnome apps. I'll definitely stay tuned :) ---- [WJG] (30/Nov/09) Well, the major structure for implementing glade files is in place and now, all that remains is the lengthy task of sewing glade into gnocl. Here's the current test script to show how progress is moving along. ====== #--------------- # gladeXMLTest1.tcl #--------------- # William J Giddings # 30-Nov-2009 #--------------- #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" package require Gnocl # load a simple glade file, containing three buttons in a horizontal row # the variable glade1_widgets contains a list of all widgets created # by loading this file, they will include the names given in the glade file # itself along with the names assigned when registering these with Tcl set glade1 button1.glade set glade1_widgets [gnocl::glade new $glade1] # create a list of aliases for these new widgets # we can use the glade widget names to do this, to make things manageable # when switching between Tcl and Glade foreach item $glade1_widgets { foreach {gnocl glade} $item {} set $glade $gnocl } # in the glade file the toplevel window is named window1 # lets resize, rename and centre it on screen $window1 configure -title "Glade Test" -width 320 -height 200 $window1 centre ;# or 'center' if you wish # we can now access the widget attributes as these are registered with gnocl! $button1 configure -icon "%#New" -onClicked { puts "NEW! from %w" } $button2 configure -icon "%#Open" -onClicked { puts "Open! from %w" } $button3 configure -icon "%#Save" -onClicked { puts "Save! from %w" } # as there needs to be a container for these widgets we can get its name with set box [$window1 cget -child] # and, of course, add new widgets too! $box add [gnocl::toggleButton -text "CLICK ME!"] gnocl::mainLoop ====== After all this, out simple layout... [] becomes this... [http://picasaweb.google.com/lh/photo/7AbBmm6Y7Nd8sXWFh14D-g?authkey=Gv1sRgCPeA4vWzk8as2AE&feat=directlink] ====== your script ====== ---- !!!!!! %| [Category GUI] |% !!!!!!