Gnocl -the Tcl/Gtk Bindings

Well, this is the first screenshot of the new gnocl::splashScreen widget. Its effectively up and running and I only now need to add a little more code to refresh the progress bar. Although it's a test script, the sample layout is the one I use for my own pet project, Jiumoluo, a customised text translation tool. Here the demo script to show how it works: # basic Tcl/Gnocl Script #!/bin/sh \ exec tclsh "$0" "$@" package require Gnocl set logo1 [gnocl::pixBuf logo] set ss [gnocl::splashScreen ] $ss configure -backgroundColor red $ss configure -backgroundImage splashScreen.png $ss configure -onDestroy {     puts 1     puts 2     puts 3     } set x 12 set y 50 # cairo prefers colour, range 0 - 1.0 set WHITE {1 1 1} set RED {1 0 0} set GREEN {0 1 0} set BLUE {0 0 1} set CYAN {0 1 1} set MAGENTA {1 0 1} set YELLOW {1 1 0} $ss add appName "Jiumoluo" \     -font "Sans 30 Normal Bold" \     -co...

After a few days away from the blog its good to update some positive progress. I’ve now got most of the code working for the gnocl::splashScreen widget. By default I’ve included a background image, I need to test the code without one just in case it throws up some errors. Today I fixed the storage of label data, ie text, fonts, position and so on. At the moment the I’ve got the string and positioning working and tomorrow I’ll get the font and other settings working. I’m quite pleased with this one as I’ve always wanted a splashscreen widget to play with. Ok, I already have a scripted package to handle this but, its not quite the same is it?

Well, added a nice new feature to the gnocl::entry today – word completion. Whilst the manual pages on the topic is somewhat complex, and the whole completion contexts is a widget, the implementation is simply an ‘ attachment’ made to the GtkEntry on initialization. The wordlist by default is empty, and so items need adding to it. Here’s the test-script: # the next line restarts using tclsh \ exec tclsh "$0" "$@" package require Gnocl set ent1 [gnocl::entry ] gnocl::window -child $ent1 # simple alpha validation $ent1 configure -onKeyPress {     if {![string is alpha %K] } {         gnocl::signalStop %w %e     } } # press return $ent1 configure -onActivate {     puts %t } # add some items to the completion wordlist $ent1 wordList add [list red orange yellow green blue indigo violet] gnocl::mainLoop

Solved the issue over reordering of widgets within the z-stack of the gnocl::fixed container. Needed less work than I thought. Basically a remove and add operation. Took a look at the gtkfixed.c sourcecode and found the code elements that I was looking for. Now the stacking order can be adjusted directly, with toTop, toBottom, lower and raise. Is it necessary to have an option to specify a position in the stack? Something like: <widget-id> stackPos <widget-id> n

I gues that the gnocl::fixed widget is almost complete now. There is one last annoying issue that needs resolving but I can't see how using the Gtk/Gdk libraries and thats adjusting the z-depth of the widgets. They remain layered in the order in which they are applied to the stack. Its possible to raise/lower the window that contains the widgets but there's no apparent way of manipulating the stack itself. What might be needed in a func to specifically 'twiddle' around with the stack. Here's the script: # basic Tcl/Gnocl Script #!/bin/sh \ exec tclsh "$0" "$@" package require Gnocl set but(1) 10 set but(2) 30 set but(3) 50 set but(4) 70 set but1 [gnocl::button -text "APPLE"] set but2 [gnocl::button -text "BANANA"] set but3 [gnocl::button -text "CHERRY"] set but4 [gnocl::button -text "DAMSON"] set lab [gnocl::label ] set fx [gnocl::fixed ] gnocl::window -child $fx -width 200 -height 130 $fx add ...

Spent some more time today on the gnocl::splashScreen widget. I decided to add an option to allow the insertion of child widgets but how? I needed to have a container that behaved pretty much like the Tk place packing command. So, today I’ve spent some time adding another previously unimplemented Gtk+ object -GtkFixed. Got the innards working, and hope to complete it tomorrow.

Had something of a mixed, productive day. Decided last night to hack together a gnocl::splashScreen widget. I’ve had a Tcl side package for some time now but it would be nice to have one as part of the core Gnocl widget set. The idea is to have something less ‘forms’ like with overlapping text, graphics and progress bar. Apart from using a canvas, this can only be achieved using Cairo. In retrospect, this is probably a good project on which to come to get to know how Cairo is used. Something else that has result from looking at the splashscreen is the use of inline graphics. To this end I’ve hard coded the Gnocl logo into the pixBuf source and it can be accessed via the new gnocl::pixBuf logo command. Nice! Next step from this is to implement a package that will enable embedded application graphics for use in widgets!

At last! Revised all the widgets and commands modules to reflect the documentation changes using Doxygen. Whilst the online documentation is still the primary user documentation repository, I feel that there is a need to integrate all documenation together. I've now done this. All the sources were cluttered with notes, most of which were unecessary. These have gone, and the useful details on how the functions worked moved to a separate location ../doc_includes. A simple commented instruction to Doxyen tells the application to include the page in the docs. I'm still not certain if this is the best way to do things. I'm purely working under my own steam here as I know no one who uses Doxygen with whom I can exchange ideas. As a result. the gnocl.c module contains all the definitions for the extra pages. At some later point I'll look at creating a single, separate file that handle the construction of these extra pages.

Spent most of my free time today fiddling around with the Doxygen documentation settings and markup in the Gnocl source code. The number of times that I have done this? Why? But, now it all seems to be coming together. My original idea was to integrate the applications developer docs into a common resource alongside the package developer docs. At first I tried including the docs markup in the code, but it’s too bulky and its not much use for anyting else. Now that I’ve created pages for most of the apps developer docs, I can integrate these into the package developer docs. Its going well now. It’s all a matter of getting the page and subpage settings sorted out. So, far so good!

Although the gnocl::box is pretty well a fully developed module doing all sorts of magical things with the Gtk+ Hbox, VBox and Frame widgets, there are still one of two less obvious features that are still awaiting implementation. One of these I came across last night was to replace the default frame label widget with one our own creation. The implication here is that the app developer can take advantage of pango markup in the creation of the frame label. It means too, that all of the various functionality of the gnocl::label is available too. Naturally, some options more useful than others under these circumstances but it could lead to some interesting results! Here’s a snapshot:

Saw this really intreaging piece of animation/poetry on the Planet Gnome earlier today. Just thought that I had to keep a link to it. Typography from Ronnie Bruce on Vimeo .

After that I said last night about handling calendar details on the Tcl-side, I’ve changed my mind. Its not that much trouble to set-up hashlists to manage the various details. So, had to rework the code to allow for the creation of all the extra goodies. You watch, when all’s done, no one will use the thing!

Got most of the calendar functionality running now. The last remaining task is to finalize the ability to display details. I’ve managed to get hold of some C test applications which show how the job is done with hash tables. From the Gnocl perspective, I think that the management of the actual details should be handled on the Tcl side. After completing the code, I’ll put a demo script together to show how it all works in practice.

Spent most of this evening expanding the gnocl::calendar functionality. Got most of it working now and only need to sort out a couple of sub-commands and the cget function. -Oh, completed most of the documentation too!

More time today on pagesetup. Resolved some issues over the implementation of the cget and configure sub-commands. Also took a look at the possibility of using git to manage versions. As there’s only me actively working on any module source code, it seems like a fruitless exercise.

Did more work yesterday on the printsetup module. This has taken me more time than I expected for a couple of reasons. Firstly, the documentation surrounding the printing features is a little spartan. It needs time to sit and reflect upon what’s going on rather than having a simple ‘how-to’ set of instructions. I have a copy of Krause who does give a worked example, but it appears to me that the chapter on printing was not given the attention of other sections of his textbook. Secondly, for a number of reasons I’ve had little restorative sleep over the past few days and looking at the source code was a bit like trying to read sand! Yesterday was a better day, completed the conversion to using a param structure for the object registration. So far, so good. In operation this should allow two ways of setting up a printer, explicitly through the script or interactively through the a dialog. Something which did occur to me as a result of working on this was returning to the builder modu...

Added a few extra lines of code to the gnocl::pageSetup module today. As I was doing this I noticed something that I was doing for the first time – writing an implementation of the cget sub-command from scratch. Things are going well but I need to decide how to handle the -units option. This doesn’t correspond to any gtk property for this object. I guess that I might need to re-write the code to enable a ‘ params’ structure for the object. Just as well that there aren’t thousands of lines of code! This morning I also created the bare bones for a new gnome application, Yelp. The Gnome help viewer.

After spending the bank holiday weekend at my daughter's house in the cold and wind doing a whole pile of DIY (building a wall and painting) it's sure is nice to sit down oncemore in front of a whining, warm workstation.  The momentum is gathering now to get a release of Gnocl 0.9.95 running on windows. The modification of the makefiles and testing is being undertaken by Luis Alejandro Muzzachiodi and so far so good.  I’m now in the process of replicating his build on my old banger of a WindowsXP driven laptop. I’ve also downloaded the Gtk theme selector app from Sourceforge and, I must say, Gnocl can now look very windows like. The fileselector dialogs are not native but it wouldn’t be too difficult (I guess) to add support for native dialogs. I’ll post some comparative screenshots soon. Finally, I did a little more on the printer support libraries. Worked on the gnocl::pageSetup command. I think is pretty obvious from the name what this widget will do! ...

There's been some basic code including within gnocl for some time now that shows how the printing of ascii files can be done. The code is basic and does really allow for any settings configuration from the script side of things. It was ok for listings. This weekend I've taken a look at the GtkPrint API and have begun to add more functionality and power to what Gnocl print services has to offer. Its an interesting exercise really as the library calls still expect quite a bit to be completed by the application source prior to issuing the actual print job. This includes rendering pages. Again, working on different pieces of code sheds light onto other areas of the project that need some attention. One of these was documenting the gnocl:winfo command.