Gnocl -the Tcl/Gtk Bindings

With the half an hour dedicated to Gnocl today I've completed the code to get a pixbuf of the pointer. Here's the test code... set pb1 [gnocl::pixBuf get pointer $win1] I've gathered the necessary lib funcs together to implement the pointer set command now. The syntax for this will look something along the lines of: gnocl::pointer set -widget $but1 -image "%/qwerty.png" Those users who browse the source code might note that there is an undocumented -cursor option for the gnocl::window widget. The chances are that no one has spotted this and built the feature into their scripts. In fact using it as an option at creation is a problem as because the widget is not drawn to screen, it actually has no gdk window assigned to it and will, therefore, throw up an error and terminate the script. It would have made more sense to have cursor sub-command. But, seeing as cursors belong to gdk windows and not gtk windows this is somewhat pointless. In fact, all widgets t...

Because I don't have much time to work on Gnocl today I thought that I'd tackle something simple, something that could he hacked in half an hour. Hence a new command - gnocl::pointer . This command enables the mouse pointer to be manipulated from a script so that its coordinates can be explicitly set or incremented. It will also mean that custom pointer can be set too.  Here are the options so far from my test script which I think speak for themselves. gnocl::pointer warp -x 100 gnocl::pointer warp -offset {-200 100} gnocl::pointer warp -x 100 -y 400 The control code has also been put in place for a new and quite odd sub-command for gnocl::pixBuf, get pointer <widget-id>. Odd, I know, but perhaps someone sometime in the future will want to make custom cursors which are modifications of the basic set, perhaps adding co-ordinates as in some design packages or a question mark for a help or query system. Adding such features are a breeze in Tcl and, after that's the phil...

As mentioned yesterday I set aside some time today to look at setting a number of global variables to contain parameters for line and fill colours plus a few other settings. So far so good but at the end of day the gnocl::draw set will cause a crash. This isn't too much of a problem to solve! I'm looking at how to split a variable length list of values into components using the strtok library function. The reason for this that  Cairo requires details of line types (i.e. 'dashes') to be presented as an array of doubles. Whilst I can easily store the list as a string as part of a global structure, parsing the list and creating an array and assigning values during run time is a new area to me. But, should have it all sorted by the end of play tomorrow evening. Here's a taster of the gnocl::draw set sub-command at work:     gnocl::draw set -lineColor {1 0 1 1} -fillColor {0 1 0 0.5} -lineWidth 5     gnocl::draw set -dash {50 10 10 10}   

Apart from wasting some time today to debug what eventually proved to be nothing other than a simple typo, the day's coding has been somewhat effective. I've focussed on implementing gradients. An earlier posting showed this done using pure Tcl, but, this is too slow for practical purposed. The Cairo routines are blindingly fast. Here's what the current comment looks like: gnocl::draw gradient $pb -type linear -from {10 10} -to {90 90} -startColor {1 0 1 1 } -endColor {1 0 0 1 } -startOffset 0 -endOffset 0.5 gnocl::draw gradient $pb -type radial -center1 {50 50} -center2 { 60 60 }  -startColor {1 0 1 1 } -endColor {1 0 0 1 } -startOffset 0 -endOffset 0.5 Needles to say, these are all completely experimental at the moment and once the service funcs are in place the syntax might need re-considering. The gradient, for instance can support multple colours which might result in providing a list of colours, eg: -colors [list {1 0 1 1 1} {1 0 1 1 0.5} {1 0 1 1 1} ] Each float with...

When I was on holiday I was determined that I would complete the Cairo drawing functionality soon after returning home. Well, I've now got a whole pile of drawing functions implemented. At the moment these only write to a pixbuf, but it should be reasonably straightforward to allow drawing to GtkDrawables too. Here's the test script just to show how it works... # basic Tcl/Gnocl Script #!/bin/sh \ exec tclsh "$0" "$@" package require Gnocl proc snap {w} {     set pb [gnocl::pixBuf snapshot $w]     #gnocl::draw circle $pb -center {50 50} -radius {20}     #gnocl::draw line $pb -from {10 10} -to {50 50}     #gnocl::draw text $pb -position {5 100} -text "Gnocl 0.9.95"     #gnocl::draw arc $pb -center {50 50} -radius 20 -startAngle 0 -endAngle 135 -fill 1 -negative 1     #gnocl::draw square $pb -center {50 50} -length 20 -fill 1     #gnocl::draw square $pb -center {50 100} -length 20     #gnocl::draw rectangle $pb -center {50 100} -width 50 -height 25 -...

Just as Tk has some built-in bitmaps, it might be useful to allow Gnoclto have such functionality. Whilst its easy enough to load graphics from file into both images and pixbufs, there may be times when a developerwant to 'hard-code' something into the the package. Is not a trivialprocess to add such items, the creation of the header is straightforward, but the new options need to be added manually into thegnocl::pixBuf source itself. At present there are only two internal graphics, the Gnocl logo and a pointer. Suggestions are invited as to what other built-in necessary graphics might be required.

I'm not certain if anyone reads the blog but I know that there are followers of the the newsgroup. I've just configured blogger to automatically email new blog post to the group. I hope that this will invite a little more interest in the core development. Personally, I don't read other people's blogs but I do check out groups and I expect that others are the same.

Been working on the prototypes of these two new command options over the past couple of days and have almost come to an end. The idea is to be able to capture a screen or window under script control. I At the back of my mind I had a list of functions that might be useful to someone creating a screencam type movie file but I think that such a project would require the creation of a custom package rather than something more general purpose as gnocl is intended to be. But, the functionality will be there, plus its allowed me more opportunity to tinker around with Cairo.  

Got back from the family holiday in Egypt earlier today and spent a while today working on the implementation of pixbuf drawing routines using cairo and answering various emails from gnocl contributors. The day ended with the addition of two new commands to the gnocl::piuxBuf module: gnocl::screenshot and gnocl::snapshot. The first command will capture the root window display and save it to a new pixbuf whereas gnocl::snapshot will capture the contents of the toplevel window simply by naming any widget in the window tree. This contrasts with the gnocl::pixuf get drawable instruction which, even if applied to a toplevel window, it will never capture the decorative frame. One use for these functions could be in the creation of desktop movies for tutorials, training etc. These do not capture the position of the mouse pointer,  but this can be composited easily. In fact it would be more desirable to have a larger than life mouse pointer for such purposes, perhaps one with animated effects ...

The remaining teething problems in implementing this option have been ironed out and it works quite well. The idea is that when a notebook page is dropped on the root screen, a window containing a new newbook will automatically be created to 'catch' the dropped page. The tricky part of things was registering the new widgets with the Tcl interpretor. This was resolved by adding registration specific code in the callback handler itself. I can now put my feet up for a couple of weeks and take a well deserved rest from Gnocl and everything else!