The whole idea behind creating the Gnocl package for Tcl was 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 understand 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.
Save this as script1.tcl
Then run, using
Assuming, that we've already successfully 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;
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.
This simple command look straghtforward to unserstand. Widget options are set in a way familiar to anyone with exposure to using console base application. 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:
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.
Here's the full listing:
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? in short, a toplvel window has only one child, the
choice of its child is important. In order to add more widget What we
need to add first is a container -- a gnocl:box. The next script
illustrates this point.
Here we can see that but2 was created and added directly to the box at initialisation. As the -children option can only take one value, we sent a list of values which, in this case are strings containing the names of the buttons just created. A third button, but3 is created later which can also be added. Here, we see another great feature of the the Tcl paradigm, the command. Here, 'add' simple instructs the box widget to act as the 'parent' of this new item. But, of course, each child can only have one parent!
So far, we have made some pretty large buttons. Resizing the window will, of course, resize the child widgets it contains; in gnocl-ish 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,
Running this script and resizing the window will show some interesting behaviours; but1 always remainds 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. As can be seen, the script can control just what proportion of the window display space will be occupied by a widget 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 thge way is a boolean, that means either a yes (1) or no (0) option.