Gnocl -the Tcl/Gtk Bindings

I'm not quite certain why, but the GtkPaned API has no direct support for tracking the events associated with the mouse pointer. Signals are implemented, but only for keyboard operations. The docs give useful function to isolate the handle gdkwindow but why didn't they go the whole hog and implement a proper binding? Well we have it now in Gnocl!   To test this feature get the latest nighly build. set p [gnocl::paned \ -children [list $b1 $ebox] \ -resize 1 -shrink 1 \ -onHandleMotion { ## puts "MOVING w= %w x= %x X= %X p= %p s=%s" if {"%s"== "256" } { foreach {x y w h} [gnocl::winfo geometry %w] {} _set_width $paned [expr $w - "%p"] gnocl::update } }]

The Gtk+ widget set contains two widgets, GtkHPaned and GtkVPaned which only allow the insertion of two child widgets. One might suppose that if more items are needed then folding boxed in a scrolling window would be adequate. One alternative, as I have used up to date, is the use of nested double panes. Implementing a new container widget in C using the Gtk+ libraries is possible, but implementing such an beast in Tcl/Gnocl is somewhat less complex. Over the past couple of evenings I've put together a proof of concept script to get the bare bones of this this megawidget in place. All seems well, although a little bit of easing on the gnocl source code side of things has helped. To this end I've added the geometry subcommand to the gnocl::fixed widget. The effect of this to allowing a single command to return the position and size of child objects placed in a gnocl:fixed container rather than making two separate calls in the script, one for the (x y) position and the oth...

Making headway now in implementing entry validation. As is always the case, the challenges don't arise from getting the code to work, but overcoming those instances when, theoretically, a block of code should work but doesn't. The most annoying aspect of all this is that such hindrances tyically occur in the simplest, most straight forward of tasks and those features which at first glance look daunting are implemented in a blink! Think I'm having a deja vu moment here. Ah, such is life. Zen and the the art of C programming -- frustration arises when one's vision of an ideal and perfect world are shot to pieces by an abrupt clash with the imperfect reality of things. The entry and parseoptions C modules now have all the necessary functionality coded into it, what now remains is to tidy it up, test and document it.

Admittedly, over the past few months things have been a little quiet on Gnocl development front. The summer has been very busy for me with most of my free time taken up with the preparation of some translation work for a forthcoming textbook on the history of east asian medicine. Needless to say, much of this has been produced using Tcl/Gnocl derived tools. The past couple of weekends have seen me address a number of problems and limitations that have arisen. Firstly the Gnocl website failed to load -- this has now been fixed and all runs normally. Next, I've worked on a couple of issues around the gnocl::eventBox and gnocl::entry widgets. With the enhancements to the gnocl::entryBox it is now possible to remove child widgets or allow their replacement during runtime. The gnocl::entry has seen the addition of the -innerBorder option, which controls the packing between the text and the entry containing frame. Some changes have taken place beneath the surface too. Previously it w...