Gnocl -the Tcl/Gtk Bindings

Whilst a splash screen widget has been in the core for some time now, the code has became unreliable and so some fixing was in order. The revised module, rather than using cairo to draw screen elements, uses items placed directly in GtkFixed container to create a gnocl megawidget. This has not only proved more easy to code, but also operates more smoothly. Updates available in the nightly build.

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

The legacy code to create a gnocl::dialog has always been problematic. The way the code was originally devised was to build up a set of control buttons using what Gtk libs describe as "activation widgets", that is: custom made widgets added to the bottom row of buttons. Apart from this approach going against the Gnome user interface guidelines, it always results in an application crash. Looking at other dialogs in the library indicates why. The idea is that the dialog 'runs' within its own loop which is only exited when a response button is activated. The dialog either gathers or gives information and then returns to the calling script a response decision obtained the user. Using activation widgets that call the -onResponse signal break this process. If programmers have used the activation widgets for something more complex then those widgets ought to be packed as children into the main body of the dialog. I've now resolved this problem by completely re-writing t

Setting individual rollover colours for tags seems a little more trouble some than I first imagined. After adding a whole pile of code that wasn't going anywhere it was time to rethink! Occam's Razor time. Whenever a solution is becoming overly complex to the point that it begins to fail, then the solution is wrong. After a while I thought that if rollovers were implemented in Gtk2+ how would it be listed in the docs? Ah! Styles -- a little voice said behind me. But, as no such style exists (if it does let me know), it seems right to add two pseudo styles: "rollover-fg" and "rollover-bg". These can be set using the familiar: gnocl::setStyles GtkTextView "rollover-bg" blue What is needed now is to remove the earlier tag options to set these colours.

The text rollover effects are well implemented now in the core C code. At present changing the colours for a rollover event in any single text widget will affect all text widgets. So, the next step is to enable unique fg/bg colour combinations. When using the rollover -tag setting some caution must be used as if any single rollover tag is used repeatedly in a text, then all those separated blocks of text marked with the tag will be highlighted.

Haven't posted much to the blog recently. This isn't because things are quiet on the Tcl/Gnocl side, I've just been doing more applications coding. Today's posting is a result of this. I already use a bunch of gnocl megawidgets but there always seems to be slight differences between each module. I thought that I'd settle this once and for all by creatings a boiler plate module which can then be adapted to suit. Because I shift between the gnocl C sources and Tcl, I thought it wise to follow a similar design approach in both. Individual procedures handle the construction, configuration and command handling for each widget instance and error checking is implemented too. #--------------- # widget.tcl #--------------- # Boilerplate object builder package for gnocl derive megawidgets. # Based upon approach used in Gnocl source code. # William J Giddings, 28-Mar-14. #--------------- # Substitute keyword _widget_ for unique object type identifier. #--------------- # !/

Not working on any academic research over the past few days has given me time to focus on completing the implementation of a simple pango/html rich text edit widget. GtkHtml was one route to take but this is being phased out in favour of WebkitGtk (besides, GtkHtml documentation of any work simply doesn't exist). After hacking together an editor using the webKitGtk, which itself is something of a work around, I modified the existing gnocl webkit package to offer all the basic functionality of a simple html doc editor. But, this required implementing Javascript calls in C procs which were then called through a Tcl front end! Apart from the package taking a second or two to load, I found that webkitGtk will tend to crash after a while. Not much use to me! My aim is to create markup strings which can also be used for display within Gtk+ widgets during run-time, i.e. marked up labels or list entries. As a glance through previous blog postings will show, I had already put together some

Given some extra time to the implementation of the gnocl::toolBar items. Whilst is is possible to pack buttons, toggles and radio buttons into the toolbar, the custom items offer better formatting and are stylistically 'correct'. As the resulting module source code was stretching into thousands of lines, the toolbar.c module was split and the code for creating the 'items' shifted into separate files. Here's summary of the recent changes: 2014-01:     gnocl::toolbar         o separated source code for the creation of toolbar items into             individual modules.         o -onToggled functionality now working properly for relevant             items.     gnocl::radioButton         o added %p substitution strings     gnocl::toggleButton         o added %p %d subtitution strings         o new option -data Updated code available from sourceforge.