Gnocl -the Tcl/Gtk Bindings

The distinction between a GdkPixBuf and the GdkPixMap/GdkBitmap is not to easy to appreciate -at the beginning at least. Its easy to assume that they are the something of the same thing but this isn't quite so. The GdkPixBuf is basically a means of loading imagery into memory where as the PixMap and BitMap objects allow direct drawing. Ok, the pixBuf can be drawn onto a pixel at a time and its contents filled but that's about it. The notion is to handle chunks of data at a more basic level rather than working with the niceties. Would it be more reasonable then, to move some of the image manipulations functionality found the gnocl::pixBuf module to a new module, gnocl::pixMap along with the drawing funcs etc? Both are 'off screen' yet the PixMap object can obtain the drawing surface of specific on-screen objects. This approach would leave the pixbuf module for the sole process of working with the buffer in terms of composting and input/output. Whilst it would be nice t...

The Tcl formt command can be used to easily convert decimal rgb colour coordinates into hexadecimal. set color [format #%02x%02x%02x $r $g $b] Ok, from the Gnocl view point the goal is also to allow decimal values to be passed as colours, but, of course its useful to have a Tcl way of solving the problem, especially when developing the bare bones of a new widget binding which hasn't yet had all the colour manipulation functions wired into place.

Because I was feeling a little annoyed with myself after coming to a sleepy, unproductive halt over the weekend hacking away at the filters; I decided to have a look at extending the current support for the GtkCurve and GtkGamma widgets. Am I less annoyed? Not really, I’m at one of those times when the old mental agility is at a low. Got some code changes, added a few typos rather than bugs, but oh no! Keep hitting problems again. I think I’ll give Gnocl a rest for a few days, just to let the old brain recharge itself!

No new posting to the Blogsite have been made over that past few days, not because of inactivity but due to quite the opposite -too much! My daily coding sessions between Thursday and Saturday this week have have resulted in the addition of one new widget type and a bagful of image processing filters. This is what has been added: gnocl::colorWheel Gnocl already has bindings to the GtkColorSelectionDialog which includes the familiar HSV colour selection wheel. This is what it looks like: The colour ring itself is a widget in its own right simply called: GtkHSV. The inclusion of this binding was really straightforward as the widget itself has only minimal signals and not specific properties (but of all, the object is easily configured in Gnocl). Whilst it may be a specialist item such as the various deprecated GIMP specific widgets, the decision to include it in the forthcoming release was rather impulsive and largely as the result of the range of pixbuf processing t...

This morning I added a few extra commands to the text widget which, are somewhat odd, I admit, but does provide further widget introspection for those who might need it. text-id getCoords start text-id getCoords cursor text-id getCoords {1 0} text-id getIndex {15 15} text-id getRect These commands are derived from the GtkTextView widget rather than GtkTextBuffer and GtkTextIter and so are more focussed on how text is rendered to the display rather than the text content itself. Internally, the Gtk+ keeps track of what is kept in the current text display buffer. Looking at the above examples one can see that getCoord takes as its argument either a text index, ie line 1, row 1 (of the text buffer) or one of several positioning keywords. What is returned is the window x,y pixel coordinates for that position. The opposite effect is produced by getIndex, here 15 15 is the pixel x,y coords whose content we want to determine in terms of its corresponding position in the textB...

In response to a support enquiry I received a few days ago, I’ve just added a new widget command for gnocl::text that returns the line and character position under  specified window coordinates. Here’s how it can be used:  set txt [gnocl::text -wrapMode word -baseFont {ILShakeFest 12} ] $txt lorem gnocl::window -child $txt -widthRequest 320 -heightRequest 200 $txt configure -onButtonPress {    puts "x = %x y = %y ; index = [%w getIndex %x %y]" } Also, because I’m getting annoyed always having to cut-n-paste text clips into a text widget for preview purposes, I’ve decided to add a further command: lorem. This will insert a paragraph of the well-recognised typesetter dummy text. Add to it an antique typeface and it looks totally wacky and completely illegible! Here’s a screenshot. (NB: I Wouldn't recommend ILShakeFest as a system font!]

The Gtk+ libraries upon which the pixBuf save command is implement are in to forms, one that does a ‘plain vanilla’ save and one which receives a list of parameters whose names and values change in relation to the file type being saved out to. Saving with compression, for instance, can result in a marked reduction in file size so this feature needed to be available from the scripting point of view. The following lines of Tcl/Gnocl code illustrate the usage: $pb2 save -fileName test2.tif -fileType tiff $pb2 save -fileName test3.jpg -fileType jpeg $pb2 save -fileName test4.jpg -fileType jpeg -parameters [list quality=50] Here the option -fileType is specified as there is no internal checking of file extensions. (Put this on the todo list!).

When I was looking over my buffer code this morning I felt that something was not quite right. Ok, the code was fine. I did ‘what it says on the tin’, but there was something wrong. After I realised what it was, ie creating a pixbuf like this: set pb1 [gnocl::pixBuf new {640 480 8 0} ] I re-worked the buffer code the result of which alows the creation of this: set pb1 [gnocl::pixBuf new \    -width 640 -height 480 \    -bitsPerSample 8 \    -alpha 1 \    -colorSpace RGB] Much more Gnoclish! The former wasn’t wrong, there is only one command to create a buffer, and once set it cannot be re-configured like widgets. Ok, so now all is fine. Or is it? We now have an anachronistic info command, the one I blogged about this morning. Well, scrap that. Use cget instead! Ah, yes, its all coming together. Perhaps a bit of ‘weeding’ late this afternoon. In the garden? Nay, to the source code, I need to weed out all the unwanted bits of comm...

Yesterday I put together some code to list the registered widgets and this morning I implemented the equivalent to display pixbufs. After assembling all the code together, it all looked a little clumsy, with two commands performing the same fundamental operations. So, I re-thought what was going on and created a new command, ‘inventory’ which then enables the script to specify registered types which, in this case, are ‘widget’ and ‘pixbuf’. This works fine. The general structure means that a framework exists for deeper gnocl introspection. Whilst putting a test script together I noticed that another simple function was missing, the ability to get details regarding any existing pixBuf. So, I added a pixBuf ‘info’ sub-command. This is what one gets when development is ‘evolutionary’ rather than ‘ planned’. Here's an illustrative script sample: for {set i 1} {$i <12} {incr i} {     gnocl::window -title "win $i"     gnocl::pixBuf new {100 10...

I expect that no one has experimented with this anyway besides, it would have given an error. This was a binding to a Gdk library function that returned a list of GdkWindows and not GtkWindows. This information is not much use to the Gnocl scripter and so it has been removed.

Simply put, this command will return a list of all widgets known to the Tcl/Gnocl interpreter. Looking at the resultant code, it looks as though a gnocl::pixBufList is a logical progression as both types of object are registered in their own hash-lists.

Completed this section of the code. It works well and lots of error trapping. In fact this would account for about 95% of the code for the options. There are other ways that this could be done within a script, builder created widgets should be given aliases and these can than be manipulated in the usual way. What is good here though, is the idea of creating widget instances. With the pure scripting route only one set of widgets are built. Using the builder route, multiple instances of widgets from a XML description file could be used. Keeping track of them, however, is a different matter!

A few days have now passed since I was working on the pixBuf gradient fills. Clearly adding code of my own is a pointless exercise. Cairo does all this sort of thing and its and integral layer of the Gtk+ rendering pipeline. So, indulgence over. Leave it all for gnocl::cairo sometime during the summer.

The aim behind creating Gnocl is to facilitate the creation of complex layouts. This assumes that the appropriate level or error checking will be made internally and decisions made on how best to proceed based upon the values passed from from the calling script. The answer then is to modify the current buider.c code to detect whether single item or multiple object lists have been received and then to determine which packing call to use, that is either gtk_box_pack_end () or gtk_container_add (). The sequence of items in the list will, by default, be assumed to be the right packing order.

I’ve now got the code running to pack objects (i.e. widgets) defined in a builder XML file into a specified, pre-existing container. Containers as such only have one child object, whereas other objects such as tables and boxes. In general the only container which accommodates a single child is a toplevel window. The code as it stand will allow the script to pass a list of objects to be packed, but at it stands, only one, item will be successfully packed using the current code. Although in practice, the recipient container will be a box, so, should I replace the container test to and throw an error if it cannot accept a list of children, or, should the size of the array be tested and then the appropriate Gtk call made to perform the packing process for adding a child to a container, or packing into boxes. If the latter, then what level of support should be given for the padding, fill and expand properties?

I’m getting more feedback regarding development issues now that the Discussion Group and Web site are now on line. This is great! It means that not only are others using Gnocl, but in many cases looking at the source itself -just as the packages are intended. Got one this evening regarding the loading of builder UI xml files. This was  pretty good error spotting! The error, though not fatal on my system, was to load an entire UI description file using a command basically intended to load named UI objects (and their child sub-tree) into a named, pre-existing container. Why was this left there? After working quite intensely on Glade over the Yuletide I needed a change (hence the move onto the gnocl::pixbuf package). The point at which I left it was at this exact stage. So, the task for the next day or so is the implementation of a new set of options for the buffer load command. This will be along the lines: gnocl::builder buffer <buffer> -object <list> -containe...

A bit fiddly this one. Nested loops, checks and operations all that sort of thing! Had very little time to work on the project today, answered some group messages, did a little bit of tidying up on the website.

Just installed all the necessary requirements to get Gnocl running on MS-Windows, and all works well. I would post a screen grab of the GnoclEditor script running but my laptop key mapping isn’t having any of it! Haven’t run the combination for long yet and so I think that are there might things to iron out but, it looks promising. This time, however, the tables are reversed for Tk/Gnocl. Gtk still retains something of its native look at the moment, whereas the Tk looks native on Windows. The fonts are larger and the Icons are the familiar Crystal icon set. Still, early days. I need to completely install a development environment on my laptop and attempt to recompile the code. After that, I’ll put the package up for adoption.

Ever since I got into graphics in the early eighties I’ve always wanted to have the excuse to put together code for gradient fills and working on gnocl::pixBuf gives me just that. At the moment, the fills are generated on the Tcl script side of things, but later on I hope to produce a module for image manipulation and processing on the gnocl::pixBuf and will convert these routines to C equivalents when the time comes to it. Here’s the screenshot... Get the script here: [1]

Just finished the function to obtain specific pixel values. This is really useful now as it means that pixbuf can now be accessed for some controlled drawing operations. Usage:  pixBuf-id getPixel {x y} Returns: RGBA 

Ok, its pretty clear that I'm a Penguin. I love Linux, Gnome and the principles of OpenSource. But, and its only a small, yet annoying’ but’ typical of any loving relationship, that there are little things not done that we take for granted will be done . Sounds familiar? The Gdk libraries contain some really useful tools, so why some of the simpler things are omited? For example, there is a gdk_pixBuf_fill command, for clearing the screen to a single colour by painting each pixel individually, yet there is no library command for painting a single pixel itself! Not an insurmountable problem, but a capability that one would expect to be there. The assumption is, perhaps, that any drawing operations will be done to GdkDrawables, i.e. anything in a window rendered to the screen. GtkPixBufs are ‘off-screen’, the buffers that can be draw and worked with independently or prior to any rendering operation. My guess too is that if a programmer needs to draw to a buffer, its better done b...

On a roller today! Added two more pixBuf commands: saturation and pixelate. The test script tells all: set pb1 [gnocl::pixBuf load "vyrnwy_small.png"] set pb2 [$pb1 saturation 0.0] set pb3 [$pb1 saturation 5.0] set pb4 [$pb1 pixelate]   set box [gnocl::box -orientation vertical]   gnocl::window -child $box   $box add [gnocl::image -image "%?$pb1"] $box add [gnocl::image -image "%?$pb2"] $box add [gnocl::image -image "%?$pb3"] $box add [gnocl::image -image "%?$pb4"] Here’s the screenshots to shows the result:

Just implemented the cget command for pixBufs. It usage takes the form:      pixBuf-id cget [-option] These being the options that can be queried.      -bitsPerSample      -colorSpace         -hasAlpha      -height      -nChannels      -pixels      -rowStride      -width These correspond to the GdkPixBuf ‘ properties’ as described in the docs. A further option      -key is taken from the library docs relating to the function that ‘get’ the values of these properties. Semantically, if there is a cget, then ought to be a configure equivalent. Also, a new buffer should also be created using the familiar syntax.      gnocl::pixBuf -width 100 -height 100 -bitsPerSample 8 -hasAlpha 1 Currently, this is initiated with:   ...

The gnocl canvas has no direct support for arc, is that odd? Not really, examination of the source for the Gnome Canvas shows that the ellipse is in fact a bezier circle. So, not only is this an approximation to a circle but the creation of arcs is going to be a nightmare. Ok, I've seen it done on Graphics apps such as animation systems using nurbs modelling, but we want to avoid curves as much as possible! What is needed is a simple solution on the scripting side. Build a list of coordinates that generate a circle or arc and pass these to the gnocl::canvas object line command. This will create a suitable polyline. Here's a sample script that I've just puts together which does the job. Notice too, that the segments count for the arc is dependent upon the angle sweep. This could be modified to take into account the radius of the curve of the object if needed. Here's a screenshot: And here's the script: #!/bin/sh # the next line restarts using tcls...

Ok, its early days, but the interest, or curiosity at least I guess, is gathering around the use of the Gnocl Google group pages as well as the on-line docs themeselves. Already got postings regarding feed back and support on the canvas widget. Its good to be of help. The GSOC announcement came via the Tcl Wiki and newgroup today which was kindly forwarded by Bob, proposed Gnocl as a possible focus for some coding over the summer. There's lots to choose from. The completion of the GtkPrint bindings or some work on the Abiwidget would be my own personal choice, but then there are some many interesting packages to work with. Didn't make any Blog posts yesterday, I was spent the extra minutes studying the GdkPixbuf docs for features to support. One item to add to the todo list is are more options for the gnocl::canvas. Parametrically, an ellipse in a squashed circle, but interactively there are some differences. Indeed, many CAD systems have different ways of defining a circ...

After a couple of days break, its back to gnocl::pixBuf. Today's implemented feature is grabbing a copy of the widget's graphics. For this to work, of course, the item needs to be rendered. Here's the test snippet, clicking a button will result in its picture being 'grabbed'. set but1 [gnocl::button -text "Hello World" ] set win1gnocl::window -child $but1] $but1 configure \      -onClicked {          set pb1 [gnocl::pixBuf get drawable $win1]          $pb1 save fileName.png}