Gnocl -the Tcl/Gtk Bindings

The toolbar has received my attention this week. Apart from the menubutton item requiring inclusion, the core of this module relies upon library functions deprecated since Gtk 2.4! Don't worry about script incompatibilities however as these are not an issue. I'm currently re-working the innards of this module to bring it up to date and when its completed the changes will only externally appear as a set of increased commands and options.

Well, I've now completed the implementation of all the available signal bindings supported by the Abiwidget API. There are some notable lacunae (gaps) in the level of support offered by the API is itself. Certain features that I would have expected such as document clear (rather than open a new Abiword window), document set-up, text highlighting, and direct table cel addressing would have been most desirable. As would direct access to print functions too! But, lets hope that there's more to come in this area as the last update to the module appears (maybe I'm wrong) to have been completed in 2007. Anyway, here the latest screenshot showing entries and toggles providing feedback on the various settings of  the displayed text. I quite like Abiword and will be exploring how to use it within some of my text processing applications. There are some 'quirks' such as the undo/redo operations and the canvas can leave drag lines a little when scrolling, but hey, that&

After eating a great dinner cooked by my wife and watching tonight's episode of X-Factor, I came back to my machine and completed the first batch of signal bindings. These simply return boolean values - ideal for setting against variables to control button toggle  (i.e.. text formatting) or activation (i.e. undo/redo). -onBold -onItalic -onUnderline -onOverline -onTopline -onBottomline -onSuperscript -onSubscript -onCanUndo -onCanRedo -onIsDirty -onLeftAlign -onCenterAlign -onRightAlign -onJustifyAlign -onTextSelected -onImageSelected -onSelectionCleared -onEnterSelection -onLeaveSelection -onTableState The percentage substitution strings for these items current have two items %w (widget name) and %v value 0 or 1. It's probably an academic exercise only, but I think that I will add a further item. %t for signal/event type. But, that will have to wait till the morning. The code is available from the SourceForge nightly build.

The list below provides an overview of the current gnocl::abiwidget commands and any relevant subcommands. Looking at the abiwidget source code shows that there are no 'properties' as typically associated with Gtk+ widgets. This is understandable really as what appears to be here is access to the functionality branched into from the Abiword control loop. This is great as it results in speedy completion of this package. What is strikingly apparent is that there are (at least so far anyway) no options. Nor are there any styles. In practical terms this is a megawidget. Certain functionality is not directly obvious, print for example, but the default Abiword key bindings are still in place (Ctrl-P for instance will bring up the print dialog). Unless something else turns up when I read through the code, then such functionality might be evoked using a signal emit. Interestingly, I found no 'clear' function. Ctrl-N will result in a fully rendered Abiword window! The next st

What a productive day! Most of the gnocl::abiwidget code completed now and I'm quite pleased with myself, so far 950 lines of (apparently) bug free code. I wish that implementing other packages such as the pixbuf were as easy. In fact, most of the code is recycling a standard switch block but, there's lots of them and many are nested too. I've already uploaded a nightly build to Sourceforge. So, here's the latest development screenshot. I think that its full of many of those expected features.... nice....

Resolved last nights problems with the ol' makefile. What was the solution? Don't code after a full day (nay week) of brain-numbing academic research! Have a good nights sleep and hit the problem at again all refreshed! Well, here's the proof of the pudding, a screen grab of the gnocl::abiwidget in action although it doesnt do much yet ;-).

Isn't it great when things go well, and then really urgghghghghh! when they don't? Well, tonight has been one of those nights. From the outside one would assume that computing and programming is straight forward, like cooking a cake. Follow the recipe and, well., you get some sort of cake at the end. How unlike programming is! How can a nice simple make file, become a nightmare! Easily, it is a make file! Well, that's enough for t'night.... Resolved compilation issues with headers (always the first hassle) and now we're onto link problems. But, this will have to wait until some other time over the weekend.

During one of those little breaks between research and writing up I decided to take a look at building the Abiwidget test. I was expecting a whole pile of hassle and unresolved compile dependencies but no! Simply installed the development files from the OpenSuse repositories saved the demo app from the Abiword wiki, modified the make to reflect the inclusion of the 2.8 libraries and bam! After a brief compilation it all worked! In fact writing this blog post has taken more time! Tonight, I think that I'll wrap the widget creation code into a gnocl package. There's so much functionality here! If there's going to be a tricky part to this all it will be plug-in support.  

I've got the basics working for this command but have come to something of a dead-end for a while. This is largely due to not having enough information at hand on how to update the background. Also, I'm not longer certain whether or not a simple command is the right approach, perhaps the solution is to create another class of objects so that backgrounds can be created and manipulated like a widget. The jury is out on this one. The old subconscious mind needs to digest this one a little longer! So, back to gnocl::draw. This too, as it principally related to pixbuf object might well deserve  re-working to reflect this. In this case, the creation of a pixbuf will need to automatically create a cairo context during initialization. This would provide a considerable speed improvement but would also require the implementation of a pixbufParams structure.

Last night I decided that I wanted to have a desktop gadget that would give me a rolling-slideshow of some my favourite family photos. With the implementation of the gnocl::pixBuf command I hacked together something useful in about half an hour. I wanted a nice dissolve and so finished the previously existing composite stub. Here's the script: #--------------- # photoAlbumGadget.tcl #--------------- # Produce a desktop photo slideshow. #--------------- # William J Giddings # 05/09/2010 #--------------- #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" package require Gnocl #--------------- # #--------------- proc init {} {     set ::dt 3000     set ::size {200 150}     set ::i 0     set ::first 1     # create a list of images     set ::album [glob ./album/*] } #--------------- # #--------------- proc slideChange {} {     incr ::i     if {$::i == [llength $::album] } {set ::i 0}     $::pb delete     # show the first frame, and dissolve thereaf

Now that I've put to one side the silly idea of adding stockitems to cursor graphics, I returned to the job of looking at the gnocl::draw command. Ironed out a couple of issues but now having others! This time on tokenizing strings saved in global structs. The string containes a series of floats to implement line dashes. When the string is first passed from the interpretor it tokenizes well, no problems. Once its assigned to the global struct, yuk. It doens't work. Maybe its should be left as a string... mmm I'll try that now.

After spending too much time this afternoon trying to overcome what might be a Tcl side issue, I decided to abandon the creation of cursors from stock item icons. Ok, it was a daft idea. The code used to determine and load the right icon was sound, it's used in the creation all widgets that use markup strings, but for some reason it just kept crashing the interpreter. It was highly unlikely that such a feature would ever be used anyway. If someone needs to drag an icon around on screen, its best achieved repositioning an undecorated window. So, if anyone tries to create a weird cursor with something like: gnocl::pointer set -widget $win1 -image "%#New" -offset {25 25} then, be warned! It will result in an Error!

Now there's only the option to use a stock item as a cursor to be sorted. I'll complete that tomorrow.

After test loading some other sample pointers and graphics that from my test_scripts directory I now believe the issue to be one of the display colormap. Again, this is for tomorrow! 5 mins later.... No, it wasn't the colormap. A pointer needs a mask. So, I loaded my test pointer into Gimp, added an alpha channel and resaved. It worked fine! (My original test pointer was simply a coloured square). 

I've now got the basics of this working although the resulting pointer image isn't quite what I expected. An RGBA cursor can be set from a pixbuf, but my script if not crashing yet is giving the wrong image at the right size. Perhaps the mask settings need to be looked at. But, that's for tomorrow!