Saturday, February 27, 2010

pixBuff-id circle [-options]

This implementation of this command will be moved into a distinct package dedicated to Cairo specific operations in which direct drawing actions can take place upon any GdkDrawable surface.

Completed the code for arbitrary rotation of a gnocl::pixBuf.

Finished adding the arbitrary rotation command. I had some issues but this wasn't incorporating the code, that was achieved earlier, but it was over wether or not to replace the buffer for the rotate object with a new buffer, or simply to create a new rotated buffer. In the end I settled for the latter choice. This would allow for any simple undo/redo operation under script control. The rotation is achieved using code taken from the zfuncs library from Kornelix -thanks. There is one option in the code that does the actual turn, acolor. The code comments don't make it abundantly clear what is happening but I provided support for it anyway. Its a nice fast routine, a much better alternative than using Imagick. Apart from rotation of colour information, the function also creates an alpha channel. Here's a snippet from the test script:

set pb5 [gnocl::pixBuf load "vyrnwy.png"]

set pb6 [$pb5 rotate \
   -angle 30 \
   -aColor 255]

gnocl::window \
   -child [gnocl::image \
   -image "%?$pb6"] -onDelete {exit}


Just added a favicon to the website, simple enough process -nice.

Updating and so on..

Today I sorted out the url forwarding for and so all works
well in that dept. Put together a front page and created a new Gnocl
Google groups. Emailed a few people who have corresponded with me in the
post on technical issues so, lets hope it generates some interest.
After lunch I'll post a few notifications around.

Friday, February 26, 2010

Coding and Documenting...

I've got half a morning free today so I've decided to spend an hour or
two working on the gnocl::pixBuf module. This morning I decided not to
let the process of creating working documentation slip by. Ok, I've got
the source code fully annotated and marked up for documentation with
doxygen but that's gnocl package development and not applications
development documentation. In the past I looked at creating appdev docs
alongside within doxygen, I guess that it's possible to do but is too much of a
headache!As I always have Firefox open when I'm coding to use the Gtk/Gnocl
online docs, I've decided to keep a page open on Google Applications
Documents to create the pages for the programmers docs. Lets hope this
strategy works well.

Wednesday, February 24, 2010

Continue Docs Writing...

I’m quite pleased with the way in which the on-line docs are now shaping. I know that the trend might be for lots of colourful borders and so on but, lets face it, when you're reading a magazine or book, for a long period of time there’s nothing worse than the excessive use of colour blurring over the eyes due to the after images they produce. Besides, a bookish look, in my mind gives a more serious feel to the proceedings!

Today I uploaded some basic tutorials which were created a while ago and also did a few more uploading tests. I’ve finally come to the conclusion that cutting and pasting straight between OpenOffice and the Sites page editor is the quickest route. Sure, sites will discard a lot of the HMTL extra things that can be done, but which, perhaps ought not to be done anyway! Embedded imagery was carried over perfectly.

I also reworked the ‘ Getting-Started’ page by expanding the comments to describe more of what’s happening in the scripts.

Tuesday, February 23, 2010

On Line Docs Stage One -Completed

Well, the first stage is over. The existing docs have been uploaded, I've added some entries to the FAQs page and have registered the URL. I'm sure that it'll take a while for all the glitches to be ironed out and the final format settled upon but I think that its all coming together nicely. Its the last part of February now and I think that sometime around Easter will be a good, time to release announce new release of Gnocl,  ie 0.9.95.

One factor that has slowed me down somewhat it the issue over text formatting. Clearly the original documentation was 'generated' rather than hand coded, perhaps using doctools. But, I don't have time for all that sorta malarkey and have opted for the most direct way in, simple HTML WYSIWYG editing. I've settled on using Google sites 'cos I don't have to pay for the hosting and besides, all the other files that I use for screenshots etc are all stored there. Unfortunately, the text editor doesn't allow me to recreate the identiing of the original docs, but a solution seems to be at hand. I notice that site can insert external documents which are stored as Google Docs files. Although the docs text editor is the same (?) as the one used for sites, I can upload the correctly formatted documentation files using OpenOffice extensions -really, really useful. I loath HTML editors at the best of times and so finding a 'wp' approach is much more to my liking. It also means that I can download the online docs and use these to produce a printable manual. Nice.

Monday, February 22, 2010

Gnocl On-Line Docs

Well, I've spent the better part of the weekend working on the Gnocl docs. This should be enough to be going on with. The main structure is now there which is the main point. The docs are basically those pages shipped with tarballs at Sourceforge which, tyo be frank, haven't changed much since release 0.9.91. There were a lot of correction which needed to be done, typically repetitive spelling mistakes which I think was probably being due the originally original docs being made under a scripted process.

For reasons basically down to costs, I've created and posted the pages to a Googlesites. I needed something quick and easy to use and can be accessed from any one of the half-dozen or so pcs and laptops the live on our home network. Ok, it does load stylesheets but, does that matter? It just makes matters much too complicated.

At the moment there are about 130+ pages which are all accessible from the on-screen navigation panel. I've kept the colourful graphics down to a minimum preferring a more sombre book-like feel to the layouts. It's still early days at the moment and I expect that the size of the site will begin to expand gradually to include the new features implemented from Gnocl 0.9.92 and beyond.

Well, back to page formatting...

Saturday, February 20, 2010

User Documentation

The maintenance of the gnocl user documentation has taken a back seat
compared to development. A number of people of asked to help-out in
the past, but, there needs to be something useful to work with. The
documentation that ships with the source hasn't really progressed much
since version 0.9.91. A quick glimpse at the NEW file will indicate
just how much the package has progressed since 1997. Well, I'll now
start to set this straight. I decided to spend today uploading the
reformatted documentation to the web -there's so many files!

Check it out here.....

Friday, February 19, 2010

New Percent String Type: %?

The Gnocl savvy readers of this blog might notice something unusual about the percentstring below: its the "%?" this prefix denotes that the image source is, in fact, a gnocl::pixBuf.

set img1 [gnocl::image -image "%?$pb4"]

gnocl::image flip command

The night just simply gets more productive. Implemented 'flip' command for the gnocl::image widget. The test script tells all..

set pb4 [gnocl::pixBuf load "ball.svg" ]
set img1 [gnocl::image -image "%?$pb4"]

$img1 flip -orientation horizontal
$img1 flip -orientation vertical

catch { $img1 flip -orientation  ASAs } ;# this will generate an error

set but1 [gnocl::button \
   -text "Turn" \
   -onClicked { $img1 turn 90 } ]

set box1 [gnocl::box -orientation vertical]
   $box1 add $but1
   $box1 add $img1 -fill {1 1} -expand 1

set win1 [gnocl::window \
   -child $box1 \
   -widthRequest 200 \
   -heightRequest 200 \
   -allowShrink 0 \
   -allowGrow 0 ]

New Image Command: turn

Hitherto you could load an image file, resize it and that was it. Basically, the image file did little else. In one of my applications Scandocs which I use to create eBooks of various sorts, I wanted to view my double page scans the right way up. Hence this command. The timing of its creation pretty well coincides with the implementation of a similar command for the gnocl::pixBuf, and for one very good reason -they use the same library calls. Anyway, this is how it works:

set pb4 [gnocl::pixBuf load "wjg.jpg"]
set img1 [gnocl::image -image  "%?$pb4"]

set but1 [gnocl::button \
   -text "Turn" \
   -onClicked { $img1 turn 90 } ]

set box1 [gnocl::box -orientation vertical]
$box1 add $but1
$box1 add $img1 -fill {1 1} -expand 1

set win1 [gnocl::window \
   -child $box1 \
   -widthRequest 200 \
   -heightRequest 200 \
   -allowShrink 0 \
   -alllowGrow 0 ]

Framework for Scripted Addition of Widget Options -Job Done!

This morning I reviewed the code that I created for gnocl::drawingArea runtime addition of widget options. I’m quite pleased with the result. The changes made this morning included the creation of a new function to handle the changes to the drawingAreaOptions array. This function, simply called doOptionAdd contains the barest level of changes to implement new functionality. Putting the allocation in a separate function does have its advantages of course. The location of the original code was nested within a switch sequence and the implementation of these new options itself relies upon a switch statement. Needless to say that with all these switches , Idxs and curly braces code errors were popping up all of the time. The current solution is lean and more easily maintained/expanded.

The todo list attached to today’s work includes the following proposals. The addition of the following sub-commands:

remove -remove the option from the options array (incl. script)
available -return a list of currently configured options
suspend -remove option from the event mask only
resume -add the option to the event mask

So far the implemented options have been signals, ie -onMotion etc., so the next logical step is looking at setting properties.

Oh, and finally, I update the NEWS file. Since beginning this blog it had become neglected somewhat!

Thursday, February 18, 2010

gnocl::drawingArea - Dynamic Allocation of Widget Options

The gnocl::drawingArea as a base widget is pretty useless yet it actually forms the basis of many custom Gtk widgets created in C. Part of developing the gnocl::pixBuf code is writing to the gnocl::drawArea and so now is as good as any time to add some features to it. But what? Let the scripter decide! The basic widget class has no default signals or properties so this is the starting point. Let the scripter decide. Once the basic had been set up the task was relatively easy. The snippet below from the test code show how event handling works.

set da1 [gnocl::drawingArea  -tooltip "HELLO" ]

$da1 option add -onMotion
$da1 option add -onEnter
$da1 option add -onButtonPress
$da1 option add -onButtonRelease
$da1 option add -onButtonMotion

$da1 configure -onMotion {puts "%x %y WHEE..."}
$da1 configure -onEnter {puts "%x %y Hello Moto"}
$da1 configure -onButtonPress {puts "%x %y Press.."}
$da1 configure -onButtonRelease {puts "%x %y Release.."}
$da1 configure -onButtonMotion {puts "%x %y MOOOOOOOOOOOOOOOOOTION.."}

Gnocl now does make some additional defaults of its own to make the code implementation harmoize with the other widgets. This show hows its done:

static gint _n = 4; /* counter,number of implements widget options */

static GnoclOption drawingAreaOptions[] =
    /* common widget options */
    { "-tooltip", GNOCL_OBJ, "", gnoclOptTooltip },
    { "-data", GNOCL_OBJ, "", gnoclOptData },
    { "-name", GNOCL_STRING, "name" },
    { "-onShowHelp", GNOCL_OBJ, "", gnoclOptOnShowHelp },
    /* widget specific options */
    { "", 0, "", NULL },
    { "", 0, "", NULL },
    { "", 0, "", NULL },
    { "", 0, "", NULL },
    { NULL },

As can be seen, the options array is statically defined with some extra spaces for run-time additions. At the moment there are only a few blanks, but this can modified later. Initially I thought of dyanamically reallocating memory for the array but this simple method seems the most straightforward solution.

End of my malloc and realloc woes...

Just finished testing the dynamic allocation of memory for the array of structures contain widget configuration options. Althought the code is correct, initialization errors occur. My suspicion now is that the const and enum variable types contained within the structure typef are not compatible with malloc operations. (I've quickly scouted through K&R and found no reference to the allocation of these types, maybe these are in the compiler specifications.)

The solution that I opted to follow then, is to statically create 'empty' entries in the option structure array and to assign values as necessary during run time. My initial tests show that the 'empty' entries cause no operational problems to my code for the creation of the gnocl::drawArea widget. At first glance it may appear that such a static allocation of memory is wasteful, but then if this was true it would be an argument against the static allocation of memory for any of the gnocl widgets which of course, it isn't.

The positive side is, however, that the run-time creation of new options for the gnocl::drawingArea provides the basis for a megawidget development context within Gnocl itself -neat.

So, on reflection, whilst I'm staying with the code I originally had I now know why this is, understand more of the underpinning memory issues surrounding the creation of statically built arrays, constants and enumerators and, of course how to dynamically create and resize structure arrays.

Memory allocation location is the cause of the errors..

Just got some usefull feedback from Tadej at Gtk+ Forums. As he points out:

'Arrays are allocated on a stack and their size is generally fixed. Alloc family of function on the other hand allocates memory from the heap.'

This would explain the issue over the incompatible types reported in the error messages. The code snippet Tad also posted gies the relevant key points. Array management in Tcl is so much easier!

/* gcc -Wall -g -o realloc_tadej realloc_tadej.c */


typedef struct
int index;
char character;

main( int argc,
char **argv )
int i;
Sample *tmp;

tmp = malloc( sizeof( Sample ) * 3 );
for( i = 0; i < 3; i++ )
tmp[i].index = i + 1;
tmp[i].character = i + 'a';

tmp = realloc( tmp, sizeof( Sample ) * 4 );
tmp[3].index = 4;
tmp[3].character = 'd';

return( 0 );

Wednesday, February 17, 2010

realloc / g_realloc woes..

I currently have the following structure;

typedef struct GnoclOption_
const char *optName;
enum GnoclOptionType type;
const char *propName;
gnoclOptFunc *func;
enum GnoclOptionStatus status;
  gboolean b;
  gint i;
  gdouble d;
  gchar *str;
  Tcl_Obj *obj;
  } val;
} GnoclOption;

During compilation, arrays of structures are made. The following is the simplest example:

static GnoclOption drawingAreaOptions[] =
{ "-tooltip", GNOCL_OBJ, "", gnoclOptTooltip },
{ NULL }, 

Usually these are fixed, the dimension of the array defined in the code itself. The GtkDrawingArea widget has no default signals as the process is left to the coder. I want to pass this feature onto the Tcl/Gnocl scripter, so I need to expand the above static declaration as needed.

For instance, I might want to append

{“-motion”, GNOCL_OBJ,””,gnoclOptOnMotion}

to the array. I know that I should use realloc or g_realloc to achieve this task, but my attempts fail. This is the snippet in my source that I’m working on:

/* get the total number of items in the array */
gint n = sizeof (drawingAreaOptions) / sizeof(GnoclOption);
/* allocate more memory to the array to hold one more entry */
drawingAreaOptions = g_realloc( &drawingAreaOptions, (gint) (n+1 * sizeof(struct GnoclOption_)));
drawingAreaOptions[n].optName = “-motion”;
drawingAreaOptions[n].type = GNOCL_OBJ;
drawingAreaOptions[n].propName = "";
drawingAreaOptions[n].func = gnoclOptOnMotion;

When compiled, I get the following error: “incompatible types in assignment”.

What’s going wrong?

Tuesday, February 16, 2010

Drawing a gnocl::pixbuf to a GdkDrawable (eg gnocl::drawingArea)

After the frustration of not (yet ?) getting Cairo to draw to the a gnocl::pixbuf, I thought that I'd take a go at drawing such a buffer to a drawable object. Well, this proved a little frustrating too and I'm relieved to have solved this problem (for me there has to be an achievement by the end of the day, I just can't relax with a problem unsolved). But, of course, the drawing only lasts until such time as the drawable is remapped. Anyway, the connections are made and its pretty well up to the script how the refresh process is handled. This is the Tcl code snippet:

set da1 [gnocl::drawingArea ]
set win1 [gnocl::window \
   -child $da1 \
   -widthRequest 200 \
   -heightRequest 200 \
   -allowShrink 0 \
   -allowGrow 0]
update ;# ensure that the widgets are drawn first

set pb4 [gnocl::pixBuf load "wjg.jpg"]
$pb4 rotate 45

$pb4 draw $da1 \
   -srcXY {0 0} \
   -destXY {0 0} \
   -ditherXY {0 0} \
   -width 100 \
   -height 100

This is the output:

This is the C code to handle the drawing process:

case DrawIdx:
/* draw the pixbuf to a GdkDrawable: ie. a drawing area */
GtkWidget *widget;
GdkDrawable *dest;
gint src_x, src_y;
gint dest_x, dest_y;
gint width, height;
gint x_dither, y_dither;

/* initialize the values with defaults */
src_x = 0;
src_y = 0;
dest_x = 10;
dest_y = 10;

x_dither = 0;
y_dither = 0;

/* what size of the buffer has to be drawn */
width = gdk_pixbuf_get_width ( pixbuf );
height = gdk_pixbuf_get_height ( pixbuf );

widget = gnoclGetWidgetFromName ( Tcl_GetString ( objv[2] ), interp );

if ( widget == NULL )
return TCL_ERROR;

dest = GDK_DRAWABLE ( widget->window );

/* change values based upon switches passed */

gdk_draw_pixbuf (
    gdk_gc_new ( widget->window ),
    src_x, src_y,
    dest_x, dest_y,
    x_dither, y_dither );

Cairo operations on Pixbufs and writing pixbufs to drawables.

I thought that I'd have wrapped up the basics by lunchtime, but now, its time for tea and the problem is still not resolved. I've got the core of the pixbuf operations working and have now come to realize that this is pretty well a 'package' in its own rights. I see that GtkPixmaps are more closely associated with GtkWidgets and need accessed in order to perform Cairo operations.
My general hunch is that in order to perform manipulate imagery I need to determine just how I to approach each side of the task and to determin what set of lib functions are best suited for purpose.
I need to produce some utility functions that will enable me to rapidly move pixbufs into to pixmaps and then into widget for display purposes. The code that I've add to the gnocl::pixbuf source to address is expiremental at the moment and most certainly will need to be tidied up.

Monday, February 15, 2010

Image Rotatation

Done some more work this evening on implementing the arbitrary value and other settings for the widget rotation command. All is working well.
What I have noticed however, is that the code for completing the rotation produces a much better quality outcome for large images. I'm not certain why -perhaps it something to do with pixel sampling. I shalln't worry about this too much as who really needs to free rotate really small items anyway? I will explore the use of cairo a little later on, probably when implementing the overwriting of text onto pixbufs.

SVG Compositing

Had another go at compositing an SVG onto a plain pixbuf. This time with more success. Here's the outcome:

I read something in the online docs about edge pixels being repeated 'to infinity'. This might be what's going on in some of my earlier tests. It's not that there's a bug, I'm misinterpreting the results.

SVG rotation

There might be another way of handing this. Perhaps its possibe to simply 'grab' a copy of the resultant pixmap of this graphic. Then it can be treated like any other. But then, this is how I expect Gdk to handle the SVG graphic in the first place.

gnocl::pixBuf #4

This morning got the composite function working. The relevant snippet from the test script shows how it is to be used. The values passed to the actual library call are dummies at the moment and so the numeric values are just to aid the development process.

# composite images

set dest [gnocl::pixBuf new {100 100 8} \
   -alpha {255 255 255} \
   -foregroundColor red \
   -backgroundColor white \
   -baseFont {Sans 10} \
   -name LXY \
   -data {Jane & Georgia} ]

$dest fill red

set src [gnocl::pixBuf new {50 50 8} \
   -alpha {255 255 255} \
   -foregroundColor blue \
   -backgroundColor white \
   -baseFont {Sans 10} \
   -name LXY \
   -data {Jane & Georgia} ]

$src fill white

$dest composite $src \
   -destX 1 \
   -destY 2 \
   -destWidth 3 \
   -destHeight 4 \
   -offsetX 5 \
   -offsetY 6 \
   -scaleX 7 \
   -scaleY 8 \
   -interpType 9 \
   -alpha 10

$dest save testSave.png

This is what is produced:

Issues arising from this is that svg files, perhaps due to these being vector files, are not handled well by the gdk library calls. Perhaps this is why the Cairo is suggested as the best choice. The free rotation of the svg didn't work at all, besides which, the current algorithm used results in a very clear sawtooth edge around the resultant operation.

Sunday, February 14, 2010

gnocl::pixBuf #3

Another busy and productive day. With the help fo Tadej at GtkForum I solved the problem of setting the fill colour values. The resulting function used to convert the colour values to the right format is:

static guint32 convertRGBtoPixel ( gchar *clr )
GdkColor color;
guint32 pixel;
/* Conversion factor from 16-bit color to 8-bit color (0xff / 0xffff) */
const gdouble f = 0.00389105;
/* create the colour from the supplied string, added by WJG */
gdk_color_parse ( clr, &color );
/* fill with colour */
pixel = ( ( ( guint ) ( * f + 0.5 ) ) << 24 ) | /* R */
( ( ( guint ) ( * f + 0.5 ) ) << 16 ) | /* G */
( ( ( guint ) ( * f + 0.5 ) ) << 8 ) | /* B */
( 0xff << 0 ); /* A */
return pixel;

Of all the obscure things that I've had to work through, the above bitshuffling and base alterations leaves me dumfounded. 

The key functionality added today then includes:

pixbuf commands

Which will sorta have the following options:

   turn <(int) 0 | 90 | 270 | 180 | -90 | -180 | -270>
   flip -orientation <(str) horizontal (default) | vertical>
   rotate -angle <(dbl) angle> -backgroundColor <(str) colour>

The code for producing the arbitrary rotation is taken from zfuncs. The edge appears aliased and there may be better implementations but this should be sufficient for screen opts.

Other things that I acquired was a pdf of Phillips (1994) Image Processing in C. Gosh it is old. There's a Tcl/Tk front end to the library. Tell it was the published in the days before Python, Ruby and the rise of Perl. Tcl/Tk was 'hot' in those days. Today.....

Also got a nice new desktop today, an Acer Aspire X1301. Its largely to replace my old tower box which, with its many whiring fans sounds like a washing machine on full spin. The new machine, apart from being much higher spec is almost silent -magic! I haven't tried it myself yet but my daughter Georgie has been using it for most of the evening. She unpacked it, set it up and completed the OS installation. Not bad for a nine year old!

Saturday, February 13, 2010

gnocl::pixBuf #2

Spent some time, too much time, today and yesterday working on this module. Its not so much the final C code that takes the time but getting to grip with how Gtk+ does things (or rather doesn't do them). The lack of clear, working examples is a bind although the contributions made to the Gtk Forum wiki are great help. The past couple of days has seen me working on getting the framework in place to construct pixbuf commands. These are the one's that I've been working on.

pixbuf commands
   save filename 
   fill colour

The key code itself it running well and is bug-free but I haven't yet quite cracked how to complete the fill command. Here's the relevant snippet from my test script:

$pb1 fill red
$pb1 fill  #aaabbbcccddd
$pb1 fill green
$pb1 fill blue
$pb1 fill white
$pb1 fill black

$pb1 fill  #fff000000fff
$pb1 fill  #000fff000fff

All the named colours are working well, ie not causing errors, but the resultant saved files are not of the right colours. It must be something to do with converting colours to a guint32 number. Tadej at Gtk Forum recommends others to use Cairo to complete such drawing operations, perhaps that's the route I might eventually take. Peter Baum produced a few support functions for colour manipulaiton which are found in the parseoptions.c module. These, however, don't handle the guint32 format. I've had enough of it for today and so will leave it for the next time.

Thursday, February 11, 2010

gnocl::pixBuf #1

Had a busy day, decided to relax with a bit of gnocl coding. The last post was about a basic spec for the next pixbuf module and, sure enough, that's what I worked on today. The original bones for the module were put together using the code development wizard which will ship with the next release. This worked compiled fine and so I set about adding some of the simpler functationality based aroung obtaining file information. The resultant commands added today were:

license | licence





Here's what they do:

    - returns a list of supported image file types.
    - returns a scription of the specified file type.
license | licence
    - returns abbreviated form of the licence terms under which the specified filetype is released.
    - returns a list of extensions associated with the specified filetype,
    - returns boolean specifying whether the file type is scalable (ie v ector).
    - returns boolean specifying whether the system is capable of saving a pixbuf in the specified file format.
    - returns a list of key information obtained after parsing the specfied file. The information is in the form {width height name}.

Saturday, February 06, 2010


Put the basic spec together to day for a new module 'pixbuf' which would allow the manipulation of off-screen drawables using the core Gtk/Gdk libraries. Rather than starting off myself, I thought that I'd post this to the Tcler's wiki to see if there's any interest for others users to contribute to this package. Such input might be the addition of ideas as to what the features list might be or even to add code themselves! Well, lets see how its goes.