Gnocl -the Tcl/Gtk Bindings

In a recent post to the gnocl groupmail DMcC mentioned that he'd like to develop an app using the gnocl::vte package. This has been in need of some TLC for some while and, as I was watching the Royal Wedding online today (congratulations to Wills and Kate!!!) I decided to revisit the code. As I expected, much was to be done! I've added quite a lot of code to the module and have put the stubs in place for handling properties and signal handling. I've also reworked the base widget creation and begun to add some commands. Another 4hrs work and it should be complete!  Here's my test script: #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" package require Gnocl package require GnoclVTE set vte [gnocl::vte ] $vte configure \     -allowBold 1 gnocl::window \     -setSize 0.5 \     -child $vte \     -onDelete exit $vte feed "mc\n" #---------------------- set but1 [gn...

Thanks to DMc for bug reports on the latest NB. Solved an issue arising from the gnocl::text search function, the interpreter would crash if the -tags option was not passed. This is now sorted and works well. The updated source and 32Bit linux builds are now available from SF. Here's a test script. #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" package require Gnocl set box(1) [gnocl::box -orientation vertical] set find [gnocl::entry] $find configure \     -primaryIcon "%#Clear" \     -secondaryIcon "%#Find" \     -variable findString \     -onIconPress {         switch %p {             primary {                 set findString ""                 $txt tag delete tag_find                 }             secondary {                 $txt tag delete tag_find                 $txt tag create tag_find -foreground red                 $txt search $findString -tags tag_find                 }             }         } set txt...

Some issues have arisen over the inclusion of the gnocl::sound command within the main gnocl module itself. The command relies upon the presence of the libcanberra libaries which provide the front end for Gnome audiothemes. As libcanberra may not be installed on all systems, the decision has been made to move the command to the gnoclGnome package on the basis that the command relies upon Gnome dependencies. Whilst gnocl::sound plays ogg audio files by default, those users who wish to play audio/video files are directed towards the multi-platform mplayer package.

Some of my apps with the following lines have been crashing. Looks like a bug has crept into the toolbar.c module. set toolBar [gnocl::toolBar -style icons] $toolBar add item -text "%#New" -tooltip $::TT(new) -onClicked fileNew Traced the problem. They were arising from the setUnderline function call. I wasn't, nor am I yet, certain what the purpose of this command is. Anyway, the function now checks for a null pointer rather than performing an assert. It works, so we'll stay with until such time as it flags up any other issues.

Some of my apps with this line are crashing. Looks like a bug has crept into the toolbar.c module. Problems arise using the following line of script: set toolBar [gnocl::toolBar -style icons] $toolBar add item -text "%#New" -tooltip $::TT(new) -onClicked fileNew

Just fixed a backward compatibility issue. Once more it is possible to simply specify either -text "%#New" or -icon "%#New" and obtain both a stock item and button label. Personally, I would opt for a combination of -text and -icon to ensure that I really get what I want.

Has some issues here. Krause's Gtk+ Development wasn't right. He suggested embedding as a replacement for a custom label widget -wrong! The right solution is to add new tool item which is, in fact, a container. Then a child widget can be added nice and easily. e.g. set ent [gnocl::entry] $toolBar add widget $ent This means that the core functionality has now been added to the module. All that remains is widget the widget variable stuff and then the tidying up! Following that, I can go back to the toolpalette module to work on the remaining drag-n-drop code.

This was easier than expected!

The toolbar API is, simpler and offers more that the earlier offerings. Much of the grouping operations, for instance, were handled on the the TCL side. The documentation is scant (understandable as there's a lot to put together) and there are no sample apps illustrating how things go together. So, I expected something more complex. In fact, the whole process is much simpler than I first supposed and all the main elements are now in place. I'll take a look at setting the variables for the toggle and radiobutton objects later this week as well as implementing the toolbar menu button. Here's the screenshot... And, here's my test script... #--------------- # test-toolPalette.tcl #--------------- # Author:   William J Giddings # Date:     08/04/11 #--------------- #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" #--------------- package require Gnocl set toolBar [gnocl::toolBar \     -orientation horizontal \  ...

Implementing support for the toolpalette has opened a big bag of worms. The current 0.9.95 code uses the toolbar API which was introduced with Gt+2.6 a long time ago. The toolpalette relies upon the newer 2.16 toolbar API which is completely different. The module itself is already a big one with well over 1800 lines of code (incl. comments). I've got the basic toolbuttons and spacers working which probably accounts for 98% of all toolbar objects. The API, however, does allow for the creation of checkboxes, radiobuttons and menus. I've done some work on these three groups but have come to something of an impasse at the moment. The 2.4 api allowed created grouping for radio buttons in a different way to the 2.16 version. This will take me some time to sort out. Of course, there will be knock-ons down the line, ie for the builder module. I shalln't upload NBs until this is resolved. However, I don't think that this will be too much of an issue.

The Gtk+ sources have a really ancient dial widget as part of the demos. So, I've just wrapped and packaged it into gnocl. It doesn't use Cairo and so its all jaggy around the edges. I'll give it some tlc later on. Implementing the DnD for the palette is more problematic. During runtime the libs are telling me that I can't mix new and deprecated code. I noted that the orientation function was old, so replaced that, but the error persists! So will I! This shall be done...

Implemented the orientation option. Runs ok. A couple of dumb oversights on my part resulted in the job taking a little longer than anticipated but, its now done. Taking a look at the D'n'D (Drag and Drop, not Dungeons and Dragons) options now. The idea is to implement exchange between a palette of toolbar items and an active toolbar. The C source code looks pretty complicated and I wouln't like to implement such features on a regular basis. But them isn't that the whole point of using Tcl? Develop the source code that does all the tough stuff one, and then add a command for it. In the Tcl community the mantra is 'Everything is a String'. This should read: In Tcl, every string is a mantra! Utter one little magic word and a whole pile of goodness occurs!

Just added a new item from Gtk+2.20 the Spinner. All that it does is makes the familiar 'clock' spin, perhaps as a lightweight alternative to a progress widget. Oh, yes. Also added a couple more options to the gnocl::text widget. I ought to update my development libraries to 2.24 to implement all the remaining Gtk+2 features.

Downloaded the Gtk+2.20 sources and took a peek at the demo code for the GtkToolPalette object. Methinks that this started life as part of Glade, where widgets contained in a palette can be dragged and dropped into UI containers. Now that I can see what the widgets for, I can decide what commands an options need implementing.

This, rather odd, widget was introduced with the release of Gtk+ 2.16 (so I believe). Its functionality is somewhere between a toolbar and collapsing frame with drag and drop. There are no samples out there for me to look at and the api docs aren't much use either in giving any idea of how the whole lot works together!

Got some more coding done this evening. The snippet from the test script show's where I'm at. The gnocl::print file operation is working all well and good, but the settings aren't being passed on at run time. But, I'll crack it -eventually! gnocl::print settings \     -orientation landscape \     -paperSize A4 \     -paperWidth 210mm \     -paperHeight 297mm \     -pageRange {1 2} \     -pages current \     -defaultSource envelope-manual \     -media stationery \     -baseFont [list "Droid Sans" 10 Bold] \     -dither rough proc doPrintFile {} {     puts [upvar level #0]     set fname test-print.tcl     gnocl::print file $fname \         -baseFont {"Andika Basic" 8} \         -linePadding 2 \ ...

Got basic listings running, enabling the setting of basic font and headers. The API is quite complicated as it aims to satisfy the various platforms that run Gtk+ which have their own print libraries. I think that the extent of what I'll do is to set some basic parameters such as margins, headers and footers. One other generalized route maybe to make the printing drawing context 'public', so that it can be draw to directly using cairo routines accessed through the gnocl::draw command. This is the test-code snippet that I'm working with: proc doPrintFile {} {     puts [upvar level #0]     set fname test-print.tcl     gnocl::print file $fname \         -baseFont [list "Courier" 8] \         -linePadding 2 \         -header $fname } At the moment, the source code itself has a whole pile of experimental stuff in there which will be thinned out in a short while.

Took a look the print module this morning. The API is woefully under-documented! Solved a print issue and extended print-setting options. Formatted printing is still a long way off as the current API required Cairo to draw to a printing context which is then sent to the printer. My hunch would be that if anyone coding in Gnocl really needed sophisticated printing support, then it would be more quickly processed using a custom C module. Alternatively, export data to an Abiwidget and print out from there.

Just added a whole raft of new options. Some (like -buffer) are still stubs. But, here's the list... -active -buffer -capsLockWarning -cursorPos -hasFrame -inputMethod -innerBorder -invisibleChar -setInvisibleChar -overwriteMode -activatePrimaryIcon -progressFraction -progressPulseStep -scrollOffset -activateSecondaryIcon -selectionBound -shadow -text -textLength -truncate -primaryIconSensitive -secondaryIconSensitive Still don't understand why so many are needed.

Just ready around the Gtk+ 2.20 docs. Looks like there's still quite a lot to do here to implement the post 2.16 enhancements. The background also acts like a progress bar in addition to the icons having their own signals, tooltips and DND functionality. Urgh! Looks like a lot of work for relatively little. But, it will be done!

Since the release of Gtk+ 2.16 the entry widget has had the possibility of displaying icons. I don't know why. Perhaps it was in order to introduce some of the minor enhancements available in the libsexy module into the core code itself. There are two types of icon: primary or secondary. The primary icon is displayed to the left of the entry field and the secondary to the right. I'm sure that it's a little more complex than this though! Just another example of 'mind-less' feature binding. Here's the script and screenshot #!/bin/sh #\ exec tclsh "$0" "$@" package require Gnocl set ent [gnocl::entry \      -primaryIcon "%#New"      -secondaryIcon "%#Save"] gnocl::window -child $ent