gnocl::pixMap

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 to find some clear distinctions between graphics packages, the practicality of it isn't that simple. There are many package layers, some of whose compenent functions have counterparts elsewhere. The challenge then, lies in deciding which area of functionality is best included in which gnocl package.

Colour formatting on the Tcl Side

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.

gnocl::curve and gnocl::gamma

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!

New widget and pixbuf filters

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 tools coming into Gnocl. Which of course leads to the next thing to report, the inclusion of the pixBufFilters.c module.

Pixbuf filters

At the time of writing the pixbuf.c module itself had grown into some 2500 lines of code which, for me, is too much. I’m a minimalist. I prefer smaller, well-ordered discrete bites of code rather than sprawling heaps of code leviathans. The pixBufFilter.c module then is not intented to be a Imagemagick or Gimp replacement, but set of simple useful image manipulation and processing tools. At the moment the functionality is compiled into the gnocl core itself, but it would be more in keeping with the idea of the main Gnocl module to purely handler Gtk+ objects to later move the filter extensions into a separate package.

The list of filters in by no means complete. Those currently included in the code are:

brightness

color

gamma

grayscale

invert

contrast

Some more obscure Text widget commands

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 textBuffer. Finally, getRect returns the window position and size of the rendered region of the text. If a specified position is not in the textView, then a negative value will be returned.

I’ve always found the idea of matched data and display buffers (i.e. a viewport) to be a little hard to work with. When I have the time I’ll create an illustrative diagram.

NEW COMMANDS for gnocl::text - getIndex and lorem

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!]

Save pixBufs with compression etc..

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!).