Saturday, January 30, 2010

Conversion of Chinese Text from Lines to Columns

Ok, I admit it, anyone seriously involved in compositing Chinese texts using the 'old-system' of top-bottom, right to left method will, in all certainty, have a UI which allows such input. If we need to include such a layout with convetional widgets that are left to right, top to bottom, then this will not be easy to composite. Using the Tcl included in my last posting, I've modified the proc to allow a set of strings containing lines of Chinese texts to be converted to a tab seprated table of text whic can then be inserted into an ordinary text file. Needless to say, it cannot be sensibly edited. But, perhaps the next little programming task! Anyway, here the modified script. (Sorry, but Blogger doesn't seem to like the embedded Unicode Chinese Script).

#!/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" "$@"
#---------------

package require Gnocl

# args:
# data = list items to be formatted into colums
# nrow = maximum number of rows to produce
# pad = character used to fill matrix gaps
# returns
# list of formatted row strings
# note
# tcl only
proc tabulate_Chinese_Columns {data nrows {pad -} } {

set r 0 ;# row counter
set str {} ;# list contain final, formatted list, returned by proc
set m 0 ;# maximum string length, used for padding


# Chinese has no spaces, must split everyting first
set data [split $data {}]

# initialise an array to hold output strings
for {set i 0 } {$i < $nrows } {incr i} { set rows($i) {} }
# build up the output strings
for {set i 0} {$i < [llength $data] } {incr i} {
if {$rows($r) == {} } {
 set rows($r) "[lindex $data $i]"
} else {
set rows($r) "$rows($r)\t[lindex $data $i]"
}
incr r
if {$r == $nrows } {set r 0} }
# get the row size in columns length
for {set i 0 } {$i < $nrows } {incr i} {
set l [string length $rows($i)]
if {$l >= $m} { set m $l}
}

# pad shorter rows with character
for {set i 0 } {$i < $nrows } {incr i} {
set l [string length $rows($i)]
if {$l < $m} {
set rows($i) "$rows($i)\t$pad"
}
# invert if necessary
set rows($i) [string reverse $rows($i)]
}

# build list
for {set i 0 } {$i < $nrows } {incr i} {
lappend str $rows($i)
}

return $str
}


# the uniquitous demo script
set txt1 [gnocl::text ]
gnocl::window -child $txt1 -defaultWidth 200 -defaultHeight 300 -title "The Analects"

set str(1) "????????????????????????????????????????????????"
# Xue Er: The Master said,"Is it not pleasant to learn with a constant perseverance
# and application? Is it not delightful to have friends coming from distant
# quarters? Is he not a man of complete virtue, who feels no discomposure
# though men may take no note of him?"

set str(2) "??????????????????????????????????????????????????????????????"
# Xue Er: The philosopher You said, "They are few who, being filial and fraternal,
# are fond of offending against their superiors. There have been none, who,
# not liking to offend against their superiors, have been fond of stirring
# up confusion. The superior man bends his attention to what is radical.
# That being established, all practical courses naturally grow up.
# Filial piety and fraternal submission! - are they not the root
# of all benevolent actions?"

set str(3) "???????????????"
# Xue Er: The Master said, "Fine words and an insinuating appearance are
# seldom associated with true virtue."

lappend data3 $str(1) $str(2) $str(3)

foreach row [tabulate_Chinese_Columns $data3 20 ""] {
$txt1 insert end \t${row}\t\n
}

Friday, January 29, 2010

Scrip reworked in to a proc..

Last night posted a simple script to format a list of strings into rows, which when inserted into a text widget would produce a table of column ordered entries. Well, here's the modified code wrapped up into a suitable proc...

#!/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" "$@"
#---------------

package require Gnocl

# args:
# data = list items to be formatted into colums
# nrow = maximum number of rows to produce
# returns
# list of formatted row strings
# note
# tcl only
proc tabulate_Columns {data nrows} {

set r 0 ;# row counter
set str {} ;# list contain final, formatted list, returned by proc

# initialise an array to hold output strings
for {set i 0 } {$i < $nrows } {incr i} { set rows($i) {} }

# build up the output strings
for {set i 0} {$i < [llength $data] } {incr i} {
if {$rows($r) == {} } {
set rows($r) "[lindex $data $i]"
} else {
set rows($r) "$rows($r)\t[lindex $data $i]"
}
incr r
if {$r == $nrows } {set r 0}
}

# insert int the text
for {set i 0 } {$i < $nrows } {incr i} {
lappend str $rows($i)
}

return $str
}

# the uniquitous demo script
set txt1 [gnocl::text]
gnocl::window -child $txt1 -defaultWidth 300 -defaultHeight 100

set data {a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z}

foreach row [tabulate_Columns $data 5] {
$txt1 insert end \t${row}\n
}

Thursday, January 28, 2010

Displaying a list in row ordered columns.

Had other things to do for the past couple of days so there's been no time for Gnocl developement. But, in response to a wiki request I came up with the following script to disaplay a list of variables in row ordered columns.

#!/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" "$@"
#---------------


package require Gnocl


set txt1 [gnocl::text]
gnocl::window -child $txt1 -defaultWidth 320 -defaultHeight 200


set data {a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z}


set rows(max) 6


set r 0 ;# row counter


# initialise array to hold output strings
for {set i 0 } {$i < $rows(max) } {incr i} { set rows($i) {} }


# build up the output strings
for {set i 0} {$i < [llength $data] } {incr i} {
set rows($r) "$rows($r)\t[lindex $data $i]"
incr r
if {$r == $rows(max) } {set r 0}
}


# insert int the text
for {set i 0 } {$i < $rows(max) } {incr i} {
$txt1 insert end $rows($i)\n
}

And here's what it produces:


Sunday, January 24, 2010

More Assistant stuff leading to code tweeking

Working on the implementation of the bindings often results in overlooking how the use of the various commands and options is accomplished, ie. coding problems are not identical to those of scripting. Some aspects of the gnocl package are not the outcome of the binding code but are inherited from the Gtk library itself, whether these be strengths or weaknesses. Looking to produce a module building system for Gnocl is a good return to scripting for me as it not only show just how good Gnocl is (even though I say it myself) but also where some of the underlying issuee remain. These issues can be both code and methodologies for getting complex scripts to work. Creating an installation script with gnocl::assistant is good because is a contemporary mixture of UI graphics and 'old-fashioned' menu screens.

Working on the project has given me the chance too to explore the use of a number of pure Tcl/Gnocl megawidgets that I created some time ago. They were built, supplied with a test script and left on the shelf. Resurrecting this package for this job has been useful, not simply because it has provided me with some nice off-the shelf widgets for forms creation, but also because it has highlighted the need to tweek the gnocl core sourcode to refine the gnocl::fileChooseButton command and also the need to create a purely Tcl/Gnocl gnocl::labelPathEntry megawidget. Here's a screenshot:



Also, yesterday I uploaded the latest snapshot of Version 0.9.94g to sourceforge and announced its release on Freshmeat.

Wednesday, January 20, 2010

gnocl::assistant new functionality and package development script

Haven't done much for the past couple of days, but today I spent a couple of hours working on the gnocl::assistant from two perspectives:

1) how to use the resources in order to effect a effective code flow for more that one pathway, and

2) expand and refine the functions available.

Well, success on both accounts. In order to set the right assistant flow, there needs to be regular re-configuration of the assistan widgets -onPrepare option.

At the moment I want to create an assistant to allow me to one of three types of module, then based upon that choice, the susquent questions, installaton directories and so on will naturally change. This process is working on the Tcl script side and aims at identifying which strategy works best. On the other hand, the C coding side it has largely been a process of cutting and pasting existing signal handling options into the package option array. There is one useful outcome of this, however, is the need to look at the innards of implementing a custon widget cget function. So far, so good. Once again, what I previously felt was a frustrating widget to work upon is now turning into both an interesting and engaging activity.

Sunday, January 17, 2010

Command module builder

After enjoying success with custom scripts to automate the creation of object and widget modules, I thought that I'd do the same for building new new Gnocl commands. Here there is no widget registration and so on but the familiar framework of commands, sub-commands and options needs to be there.
Again, so far so good. The first practical use of this will be to create a gnocl::pixMap command to handle off-screen rendering of images.
Reblog this post [with Zemanta]

Saturday, January 16, 2010

gnocl::text and the new gnocl::textBuffer object

Yesterday was a day mixed with annoyances - a whole pile of them and the coding was no exception. Next time, make sure the documentation referred to matches the version of installed on your system! I wasted a good couple of hours trying to implement support for the GtkTexBuffer "paste-done" event but no matter how I checked and re-wrote the code it would stil crash my scripts!!!! Why? This signal is implemented since Version 2.15 and I have version 2.14 installed! That's what happens when one fails to check which set of docs are bookmarked in the browser. Ok, I've just commented out the relevant code for now, just until I upgrade to Gtk+ 2.19 or whatever its up to now!
Today, however, I thought that I'd take a look at implementing a new module, gnocl::textBuffer using the prototype gnocl::assistant module builder mentioned earlier in this blog. Worked a treat, only needed a couple of tweeks and its working well.
This new module enables the script to create multiple text buffers to be created and registered with the interpreter. Nice! This value of this lies in decluttering the UI. Different docs currently open for editing can be accessed through a menu rather than using tabs or new edit windows. Really nice stuff. This has also required th addition of a new gnocl::text option '-buffer' which enables the script to interactively switch between buffers. This script shows how it works.

#---------------
# test-text-buffer.tcl
#---------------
# William J Giddings
# 16/Jan/2010
#---------------
#!/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" "$@"
#---------------

package require Gnocl

set box1 [gnocl::box -orientation vertical]
set box2 [gnocl::box ]
$box1 add $box2

set txt [gnocl::text \
-baseFont {Sans 14} \
-editable no \
-text "Come to me in the silence of the night\nChristina Rossetti (1830-1894)" \
-scrollbar always]

foreach {i j} {0 Title 1 Verse-1 2 Verse-2 3 Verse-3} {
set rad($i) [gnocl::radioButton \
-text $j \
-variable buff \
-onValue $i]
$rad($i) configure -onToggled { $txt configure -buffer $tbuf($buff) }
$box2 add [set rad($i)]
}

$box1 add $txt -fill {1 1} -expand 1

gnocl::window -child $box1 -defaultWidth 480 -defaultHeight 240 -onDestroy {exit}

set verse(0) [$txt get start end]

set verse(1) {Come to me in the silence of the night;
Come to me in the speaking silence of a dream;
Come with soft rounded cheeks and eyes as bright
As sunlight on a stream;
Come back in tears,
O memory, hope, love of finished years.}

set verse(2) {O dream how sweet, too sweet, too bitter sweet,
Whose wakening should have been in Paradise,
Where souls brimfull of love abide and meet;
Where thirsting longing eyes
Watch the slow door
That opening, letting in, lets out no more.}

set verse(3) {Yet come to me in dreams that I may live
My very life again cold in death:
Come back to me in dreams, that I may give
Pulse for pulse, breath for breath:
Speak low, lean low,
As long ago. my love, how long ago.}

set tbuf(0) [gnocl::textBuffer -text $verse(0)]
set tbuf(1) [gnocl::textBuffer -text $verse(1)]
set tbuf(2) [gnocl::textBuffer -text $verse(2)]
set tbuf(3) [gnocl::textBuffer -text $verse(3)]

gnocl::mainLoop

And here's a snapshot:



Reblog this post [with Zemanta]

Thursday, January 14, 2010

gnocl::label -text

Had to use the label widget today and thought that it would look nicer with a coloured background and white text. But, the label has no background attribute, it simple places text over its container. So, to get a solid fill the label widget needs to be placed inside an eventBox. Ok, we shalln't need the all the functionality of this container but its the right choice. Now for the foreground colour. Again more confusion. The GtkLabel, infact, has no style properties so the text foregroud can't be set explicity either. It has to be achieved using Pango Markup.


FInally, anyone whose used the label will have noticed that the pango markup application didn't work properly with the -text option. Don't worrry, now that's fixed and will be included in the next upload.

Here's a sample script from the Tcler's wiki

 #!/bin/sh
 # the next line restarts using tclsh \
 exec tclsh "$0" "$@"

 package require Gnocl

 set etitle "Tcl/Gnocl 8.5"

 proc setString {angle} {
         return  "Angle = $angle degs"
        }

 set angle 330
 set string [setString $angle]

 set lab [gnocl::label -textVariable string \
                       -baseFont {Sans 30} \
                       -angle $angle] 
 set but [gnocl::button \
         -icon "%#Refresh" \
         -onClicked {
                 incr angle 15
                 if {$angle == "360" } {set angle 0}
                 set string [setString $angle]
                 $lab configure -angle $angle
        }]

 set box [gnocl::box -orientation vertical]
 $box add $but
 $box add $lab -fill {1 1} -expand 1

 set win [gnocl::window -title $etitle \
                        -child $box \
                        -onDelete {exit} ]
 gnocl::mainLoop 
 
And here's a screenshot:
 

 
 





Reblog this post [with Zemanta]

Wednesday, January 13, 2010

New Option - gnocl::text -text

Job done. Why include this switch? Suppose a script has the following line of code, perhaps as part of a feeback process in which the text widget is only needed for feedback purposes:

set msg [glob [pwd]/*.*]
set win [gnoc::window]
gnocl::window -child $win
$win insert end $msg

Why not simply the process? to just:

set msg [glob [pwd]/*.*]
gnocl::window -child [gnocl::text -text $msg]

In fact, when there's no need to use rich text formatting this is really useful as the underlying Gtk+ library function will delete the buffer contents too!




Reblog this post [with Zemanta]

gnoc::assistant -day 3

Continued working on the module creation assistant today. So that existing module aren't overwritten or widgets not identified for support, I've looked at ways of inspecting the current Gtk+ devel installation to see what widgets are available seeing as Gtk lacks the introspection to return a list of registered widgets. The likely root seems to be reading what include files are present. If this doesn't work then the list will need to be hard-coded into the script itself. It might also mean, of course, adding new, brief modules to the core to cater for differences in basic objects, ie. GtkPaned (a Gtk Object) becomes GtkHPaned and GtkVPaned (specific widget implementations).

Another thing I'll work on today is adding a -text option to the gnocl::text widget which will place some initial text in a widget rather than adding an extra line or two of script.

Tuesday, January 12, 2010

gnocl::assistant -day 2

Unusually for me I finished yesterday's programming stint on a high.

I've got the gnocl::assistant running sweetly and so I want to put to good use helping me! How many times have I sat down and build new widget modules from scratch or re-worked bindings of the same class (eg buttons) when I know the whole process can be semi-automated?

Well, early today I put together a bare bones template for implementing new widget bindings. After this was completed, I brought the C module into a Tcl script as a string and set up a series of [string map] operations to modify the code to set up core functions and options with binding related names. The script will also backup and then modify the gnocl master Makefile to build and link the new module into the package. Oh, the joys to Tcl programming! Following that I put the basics together for the assistant script which is starting to look pretty good. Can't wait to finish it, a sort of late Christmas present for myself!
Reblog this post [with Zemanta]

Monday, January 11, 2010

gnocl::assistant -day 1

It was during May of last year that I shipped the first implementation of the gnocl::assistant widget. Whilst I got most of the features running, the widget kept crashing and never actually ran the setup scripts passed to it which left me feeling somewhat dissatisfied. Of all the Gtk+ offerings this was the one I disliked most, but ironically was on my list of important widgets to implement.

Today I sat down and revisited the source code of the widget and resolved the problems in the signal handling which was throwing up those nasty bugs. I also changed the syntax for adding new pages. This means that by default title will be given to a new page unless expreslly specified using the -title option.

Saturday, January 09, 2010

Developments with OpenGL widget

The last c ouple of days has seen me giving more time to looking at the fledgling gnocl::openGl widget. But, strictly speaking, there is no Gtk+ or Gnome OpenGL widget. What is available is the gtkglext library which will ** render ** OpenGL procedures to a GtkDrawingArea. This is reminiscent of the GtkSpellCheck extension to the GtkTextView widget. Its an add-on, not a widget. The practical implementation then is how to deal with two contexts: a GtKDrawingArea created in a Glade file and one scripted directly in Gnocl itself.

Wednesday, January 06, 2010

gnocl::openGL widget

Just re-worked the base application. Simpler sourcefile, removed unecessary headers. Uploaded to Sourceforge.

Easier Package Creation

This morning, in spite of having very little sleep last night due to insomnia, I sat down and, using the new gnocl package templates, hacked together gnocl webkit support in less than two hours. Ok, this is bare-bones stuff, just the widget creation and loading of a first URL. But hey, it worked a treat. The first release was uploaded to Sourceforge before lunch!

Monday, January 04, 2010

Gnocl Tutorial #1 -The Basics

The whole idea behind developing the Gnocl Tcl package is to make to process of developing Gtk+/Compliant applications easy to develop. Ordinarily, creating a Gtk+ application requires not only a good understanding of the C programming language and its build tools, but also practical familiarity with the innards of the various Gtk+
libaries.

The Tcl scipting language was designed to isolate (or spare) the scripter from the daunting task of negotiating the vast array of build libraries and needed to get event the most simplest of task-driven applications to work, gnocl does the same. Unlike other bindings such as PyGtk which places a 'wrapper' around Gtk libraries making them accesible to the script, such an approach still requires the scripter to understandin the innards of the Gtk libraries. For the newcomer, the big-jump into
developing useful code is less than programming directly in C, but still a lengthy task when compare to the directness of the Gnocl approach.

So, how does Gnocl work? The idea is to maintain the tool-command paradigm that forms the heart of Tcl and it companion package, Tk. Here a glimpse at a first application would be useful. As were running under some form of *nix, we need to open a script file and enter the following lines.

#!/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" "$@"

package require Gnocl

Save this as script1.tcl. At the command prompt, change the persmissions of the file to get the schell to run the script as an executable. To do this, simply run:

chmod +x *.tcl

Then run, using

./script1.tcl

Assuming, that we've already successully installed Tcl and the Gnocl packages, this will produce absolutely nothing on screen! In fact, this is good. It tells that all the packages are properly installed. Now add the following line of code, save and re-run.

gnocl::window

Voila! The window is now open. This one line of script provides the scripter with a whole raft of pre-porgrammed options. Ranging from event handling, style settings and even compositing to screen with a bitmask. This, is he beauty of the Tcl approach. Lets now create a button. We can add the following line, just above the gnocl::window command.

set but1 [gnocl::button -text "Hello World!" -onClicked {puts "Hello World"} ]

This simple command look straightforward to understand. Widget options are set in a way familiar to anyone with exposure to using console based applications. The global variable 'but1' needs to be set, so that the script can directly handle the new widget. To tell the system to add the button as the 'child' of the window 'parent', modify the gnocl::window line to read:

gnocl::window -child $but1

But, just for fun, also add the following extra options to set the title of the window, change its size and what to do when the close button is clicked.

gnocl::window \
    -child $but1 \
    -title "My First Gnocl App" \
    -onDestroy {exit} \
    -widthRequest 320 \
    -heightRequest 200 

Here's the full listing:

# script1.tcl
#!/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" "$@"

package require Gnocl

set but1 [gnocl::button \
    -text "Hello World!" \
    -onClicked {puts "Hello World"} ]

gnocl::window \
    -child $but1 \
    -title "My First Gnocl App" \
    -onDestroy {exit} \
    -widthRequest 320 \
    -heightRequest 200

As can be seen, a single line of script can be quite long and dificult to read. Unlike other scripting languages which are quite 'fixed' in their formatting, Tcl is flexible. To break commands over multiple lines simple add '\'. This will tell the Tcl interpreter that that next line is still a part of the current command.

This is about the simplest application that can be made. But, what if we want to add more widgets? A toplevel window has only one child, the choice of its child is important. In order to add more widget What we need to first add a container -- a gnocl::box. The next script illustrates this point.

# script2.tcl
#!/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" "$@"

package require Gnocl

set but1 [gnocl::button \
    -text "Hello World!" \
    -onClicked {puts "Hello World"} ]

set but2 [gnocl::button \
    -text "Good Morning!" \
    -onClicked {puts "Good Morning"} ]

set box [gnocl::box -children "$but1 $but2" ]

set but3 [gnocl::button \
    -text "Good Afternoon!" \
    -onClicked {puts "Good Afternoon"} ]

$box add $but3

gnocl::window \
    -child $box \
    -title "My First Gnocl App" \
    -onDestroy {exit} \
    -widthRequest 320 \
    -heightRequest 200

Here we can see that but2 was created and added directly to the box at initialisation. As the -children option can take more than one value, we sent a list of values which, in this case are strings containing the names of the buttons previously created. A third button, but3 is created later which then added to the list of children.

So far, we have made some pretty large buttons. Resizing the window will, of course, resize the child widgets it contains; in gnocl-ese the widgets are 'filling' their parent, and 'expanding' as the toplevel window that contains them all is resized. As  might be expected, both '-fill' and '-expand' are switchable options. To best demonstrate this feature, lets work with an alternative version of script2.tcl,

# script3.tcl
#!/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" "$@"

package require Gnocl

set but1 [gnocl::button \
    -text "Hello World!" \
    -onClicked {puts "Hello World"} ]

set but2 [gnocl::button \
    -text "Good Morning!" \
    -onClicked {puts "Good Morning"} ]

set but3 [gnocl::button \
    -text "Good Afternoon!" \
    -onClicked {puts "Good Afternoon"} ]

set box [gnocl::box ]

$box add $but1 -fill {0 0} -expand 0
$box add $but2 -fill {1 1} -expand 1
$box add $but3 -fill {0 0.5} -expand 1

gnocl::window \
    -child $box \
    -title "My First Gnocl App" \
    -onDestroy {exit} \
    -widthRequest 320 \
    -heightRequest 200

Running this script and resizing the window will show some interesting behaviours; but1 always remains the same size, but2 will expand to fill whatever space is available, whereas but3 does not change its width but only its height to fill half (i.e 0.5) of its available space. Clearly, the script is controlling what proportion of the window display space will be occupied by a widget. This is achieved by providing a 'fill factor' between 1 and zero. In most instances, however, these will typically be either 0 or 1. The -expand switch, by the way is a boolean, that means either a yes (1) or no (0) option.


Reblog this post [with Zemanta]

Canvas SVG Loading and Save Functionality

The canvas implementation dates back to version 0.9.92 at the lastest and has all the basic functionality for creating vector objects. Would would be useful is the inclusion of some form of persistence, ideally in the form of an SVG loader saver. After Googling around for a while it seems that there's nothing out there which I can easily wrap into the package. The next best solutiuon would be to use a Tcl script to read and write SVGs.

New Year's Resolution

Well, everyone is supposed to have a new year's resolution and believe me I have a few. One of these is to bring the Gnocl project to a full 1.0.0 release this year! Needless to say, the project is growing as there are so many useful Gtk+/Gnome extensions to grab and divert one's attention when confronted with the need to resolve a nasty problem.
Putting that aside, the Yuletide break has provided me with almost a solid month of programming time to which has been devoted to a number of tasks:

1. Improving Gnocl support for Glade files.
2. Extending support to GtkBuilder xml files.
3. Modfying the code base to enable handle functions to be accessed from the builder module.
4. Implement gnocl support for all Gtk+ widgets.

The latter has been necessary because the early approach was to make Gtk+ programming as simple as possible. This meant, for instance, there was no scrollbar widget. The gnocl::text widget for instance, is in fact a megawidget placed inside a GtkScrolledWindow with matching GtkScrollBars. Boxes, too, needed extending. Ok, its a simple matter where Gnocl dermines wether or not to create a GtkHBox or GtkVBox. The properties being the same. Builder/Glade will create these unique objects and so gnocl needs to know how to handle these. At the moment, the implementation is about 80% complete. The most notable 'things to do' include sorting out the toolbar, the tree and listview. For the meantime the workaround would simply be to create the place holder and add these items from the Tcl side.
Other work undertaken over the Hols has been to reorganise the file structure of the project. Having all modules under one umbrella makefile was problematic to say the least. So, I bit the bullet and split away the various elements ie. canvas, sourceview etc into their own project directories. In one way this removes compilation and linkage depency problems although the makefiles needed reworking. The newer makefiles also enable the better managment of sub-project development as the handle compilation, installation of dependencies and upload to sourceforge.
A few bugs have been resolved too, especially the failure to close the gnocl::aboutDialog widget.
Today, I've just uploaded the latest update release of the gnocl::canvas widget.