Gnocl -the Tcl/Gtk Bindings

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.

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 \    -c...

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

Today I sorted out the url forwarding for www.gnocl.org 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.

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.

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.

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 Gnocl.org 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 allo...

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 navigatio...

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..... http://sites.google.com/site/gnocltclgtk/

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

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 ]

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 ]

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 -re...

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

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 cour...

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 */ #include typedef struct { int index; char character; } Sample; int 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 ); }

I currently have the following structure; typedef struct GnoclOption_ { const char *optName; enum GnoclOptionType type; const char *propName; gnoclOptFunc *func; enum GnoclOptionStatus status; union   {   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 attemp...

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} \  ...

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.

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.

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.

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.

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 \ ...

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 ) ( color.red * f + 0.5 ) ) << 24 ) | /* R */ ( ( ( guint ) ( color.green * f + 0.5 ) ) << 16 ) | /* G */ ( ( ( guint ) ( color.blue * 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    turn    flip ...

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    class 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...

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: types description license | licence extension scaleble writable fileInfo Here's what they do: types     - returns a list of supported image file types. description     - returns a scription of the specified file type. license | licence     - returns abbreviated form of the licence terms under which the specified filetype is released. extension     - returns a list of extensions associated with the specified filetype, scalable     - ...

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.