Gnocl -the Tcl/Gtk Bindings

Ok, I admit it, anyone seriously involved in compositing Chinese texts using the 'old-system' of top-bottom, right to left method will, in all certainty, have a UI which allows such input. If we need to include such a layout with convetional widgets that are left to right, top to bottom, then this will not be easy to composite. Using the Tcl included in my last posting, I've modified the proc to allow a set of strings containing lines of Chinese texts to be converted to a tab seprated table of text whic can then be inserted into an ordinary text file. Needless to say, it cannot be sensibly edited. But, perhaps the next little programming task! Anyway, here the modified script. (Sorry, but Blogger doesn't seem to like the embedded Unicode Chinese Script). #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" #--------------- package require Gnocl # args: # data = list items to be formatted into colums # nrow = maximum number of row...

Last night posted a simple script to format a list of strings into rows, which when inserted into a text widget would produce a table of column ordered entries. Well, here's the modified code wrapped up into a suitable proc... #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" #--------------- package require Gnocl # args: # data = list items to be formatted into colums # nrow = maximum number of rows to produce # returns # list of formatted row strings # note # tcl only proc tabulate_Columns {data nrows} { set r 0 ;# row counter set str {} ;# list contain final, formatted list, returned by proc # initialise an array to hold output strings for {set i 0 } {$i < $nrows } {incr i} { set rows($i) {} } # build up the output strings for {set i 0} {$i < [llength $data] } {incr i} { if {$rows($r) == {} } { set rows($r) "[lindex $data $i]" } else { set rows($r) "$rows($r)\t[lindex $data $i]" } incr r if {$r == ...

Had other things to do for the past couple of days so there's been no time for Gnocl developement. But, in response to a wiki request I came up with the following script to disaplay a list of variables in row ordered columns. #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" #--------------- package require Gnocl set txt1 [gnocl::text] gnocl::window -child $txt1 -defaultWidth 320 -defaultHeight 200 set data {a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z} set rows(max) 6 set r 0 ;# row counter # initialise array to hold output strings for {set i 0 } {$i < $rows(max) } {incr i} { set rows($i) {} } # build up the output strings for {set i 0} {$i < [llength $data] } {incr i} { set rows($r) "$rows($r)\t[lindex $data $i]" incr r if {$r == $rows(max) } {set r 0} } # insert int the text for {set i 0 } {$i < $rows(max) } {incr i} { $txt...

Working on the implementation of the bindings often results in overlooking how the use of the various commands and options is accomplished, ie. coding problems are not identical to those of scripting. Some aspects of the gnocl package are not the outcome of the binding code but are inherited from the Gtk library itself, whether these be strengths or weaknesses. Looking to produce a module building system for Gnocl is a good return to scripting for me as it not only show just how good Gnocl is (even though I say it myself) but also where some of the underlying issuee remain. These issues can be both code and methodologies for getting complex scripts to work. Creating an installation script with gnocl::assistant is good because is a contemporary mixture of UI graphics and 'old-fashioned' menu screens. Working on the project has given me the chance too to explore the use of a number of pure Tcl/Gnocl megawidgets that I created some time ago. They were built, supplied with a test...

Haven't done much for the past couple of days, but today I spent a couple of hours working on the gnocl::assistant from two perspectives: 1) how to use the resources in order to effect a effective code flow for more that one pathway, and 2) expand and refine the functions available. Well, success on both accounts. In order to set the right assistant flow, there needs to be regular re-configuration of the assistan widgets -onPrepare option. At the moment I want to create an assistant to allow me to one of three types of module, then based upon that choice, the susquent questions, installaton directories and so on will naturally change. This process is working on the Tcl script side and aims at identifying which strategy works best. On the other hand, the C coding side it has largely been a process of cutting and pasting existing signal handling options into the package option array. There is one useful outcome of this, however, is the need to look at the innards of implement...

After enjoying success with custom scripts to automate the creation of object and widget modules, I thought that I'd do the same for building new new Gnocl commands. Here there is no widget registration and so on but the familiar framework of commands, sub-commands and options needs to be there. Again, so far so good. The first practical use of this will be to create a gnocl::pixMap command to handle off-screen rendering of images.

Yesterday was a day mixed with annoyances - a whole pile of them and the coding was no exception. Next time, make sure the documentation referred to matches the version of installed on your system! I wasted a good couple of hours trying to implement support for the GtkTexBuffer "paste-done" event but no matter how I checked and re-wrote the code it would stil crash my scripts!!!! Why? This signal is implemented since Version 2.15 and I have version 2.14 installed! That's what happens when one fails to check which set of docs are bookmarked in the browser. Ok, I've just commented out the relevant code for now, just until I upgrade to Gtk+ 2.19 or whatever its up to now! Today, however, I thought that I'd take a look at implementing a new module, gnocl::textBuffer using the prototype gnocl::assistant module builder mentioned earlier in this blog. Worked a treat, only needed a couple of tweeks and its working well. This new module enables the script to create multi...

Had to use the label widget today and thought that it would look nicer with a coloured background and white text. But, the label has no background attribute, it simple places text over its container. So, to get a solid fill the label widget needs to be placed inside an eventBox. Ok, we shalln't need the all the functionality of this container but its the right choice. Now for the foreground colour . Again more confusion. The GtkLabel, infact, has no style properties so the text foregroud can't be set explicity either. It has to be achieved using Pango Markup. FInally, anyone whose used the label will have noticed that the pango markup application didn't work properly with the -text option. Don't worrry, now that's fixed and will be included in the next upload. Here's a sample script from the Tcler's wiki #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" package require Gnocl set etitle "Tcl/Gnocl 8....

Job done. Why include this switch? Suppose a script has the following line of code, perhaps as part of a feeback process in which the text widget is only needed for feedback purposes: set msg [glob [pwd]/*.*] set win [gnoc::window] gnocl::window -child $win $win insert end $msg Why not simply the process? to just: set msg [glob [pwd]/*.*] gnocl::window -child [gnocl::text -text $msg] In fact, when there's no need to use rich text formatting this is really useful as the underlying Gtk+ library function will delete the buffer contents too!

Continued working on the module creation assistant today. So that existing module aren't overwritten or widgets not identified for support, I've looked at ways of inspecting the current Gtk+ devel installation to see what widgets are available seeing as Gtk lacks the introspection to return a list of registered widgets. The likely root seems to be reading what include files are present. If this doesn't work then the list will need to be hard-coded into the script itself. It might also mean, of course, adding new, brief modules to the core to cater for differences in basic objects, ie. GtkPaned (a Gtk Object) becomes GtkHPaned and GtkVPaned (specific widget implementations). Another thing I'll work on today is adding a -text option to the gnocl::text widget which will place some initial text in a widget rather than adding an extra line or two of script.

Unusually for me I finished yesterday's programming stint on a high. I've got the gnocl::assistant running sweetly and so I want to put to good use helping me! How many times have I sat down and build new widget modules from scratch or re-worked bindings of the same class (eg buttons) when I know the whole process can be semi-automated? Well, early today I put together a bare bones template for implementing new widget bindings. After this was completed, I brought the C module into a Tcl script as a string and set up a series of [string map] operations to modify the code to set up core functions and options with binding related names. The script will also backup and then modify the gnocl master Makefile to build and link the new module into the package. Oh, the joys to Tcl programming! Following that I put the basics together for the assistant script which is starting to look pretty good. Can't wait to finish it, a sort of late Christmas present for myself!

It was during May of last year that I shipped the first implementation of the gnocl::assistant widget. Whilst I got most of the features running, the widget kept crashing and never actually ran the setup scripts passed to it which left me feeling somewhat dissatisfied. Of all the Gtk+ offerings this was the one I disliked most, but ironically was on my list of important widgets to implement. Today I sat down and revisited the source code of the widget and resolved the problems in the signal handling which was throwing up those nasty bugs. I also changed the syntax for adding new pages. This means that by default title will be given to a new page unless expreslly specified using the -title option.

The last c ouple of days has seen me giving more time to looking at the fledgling gnocl::openGl widget. But, strictly speaking, there is no Gtk+ or Gnome OpenGL widget. What is available is the gtkglext library which will ** render ** OpenGL procedures to a GtkDrawingArea. This is reminiscent of the GtkSpellCheck extension to the GtkTextView widget. Its an add-on, not a widget. The practical implementation then is how to deal with two contexts: a GtKDrawingArea created in a Glade file and one scripted directly in Gnocl itself.

Just re-worked the base application. Simpler sourcefile, removed unecessary headers. Uploaded to Sourceforge.

This morning, in spite of having very little sleep last night due to insomnia, I sat down and, using the new gnocl package templates, hacked together gnocl webkit support in less than two hours. Ok, this is bare-bones stuff, just the widget creation and loading of a first URL. But hey, it worked a treat. The first release was uploaded to Sourceforge before lunch!

T he whole idea behind developing the Gnocl Tcl package is to make to process of developing Gtk+/Compliant applications easy to develop. Ordinarily, creating a Gtk+ application requires not only a good understanding of the C programming language and its build tools, but also practical familiarity with the innards of the various Gtk+ libaries. The Tcl scipting language was designed to isolate (or spare) the scripter from the daunting task of negotiating the vast array of build libraries and needed to get event the most simplest of task-driven applications to work, gnocl does the same. Unlike other bindings such as PyGtk which places a 'wrapper' around Gtk libraries making them accesible to the script, such an approach still requires the scripter to understandin the innards of the Gtk libraries. For the newcomer, the big-jump into developing useful code is less than programming directly in C, but still a lengthy task when compare to the directness of the Gnocl approach. So,...

The canvas implementation dates back to version 0.9.92 at the lastest and has all the basic functionality for creating vector objects. Would would be useful is the inclusion of some form of persistence, ideally in the form of an SVG loader saver. After Googling around for a while it seems that there's nothing out there which I can easily wrap into the package. The next best solutiuon would be to use a Tcl script to read and write SVGs.

Well, everyone is supposed to have a new year's resolution and believe me I have a few. One of these is to bring the Gnocl project to a full 1.0.0 release this year! Needless to say, the project is growing as there are so many useful Gtk+/Gnome extensions to grab and divert one's attention when confronted with the need to resolve a nasty problem. Putting that aside, the Yuletide break has provided me with almost a solid month of programming time to which has been devoted to a number of tasks: 1. Improving Gnocl support for Glade files. 2. Extending support to GtkBuilder xml files. 3. Modfying the code base to enable handle functions to be accessed from the builder module. 4. Implement gnocl support for all Gtk+ widgets. The latter has been necessary because the early approach was to make Gtk+ programming as simple as possible. This meant, for instance, there was no scrollbar widget. The gnocl::text widget for instance, is in fact a megawidget placed inside a GtkScro...