Thursday, June 04, 2015

Summary of Recent Progress

The current nightly build sees a range of enacements to Gnocl as a whole. A number of issues have been addressed as itemized in the extract from the NEWS document below. This nightly update sees the -name option taking on a greater role in the control of widgets. Ordinarily used for specifying ojects in a Gtk CSS file, or in a builder/glade XML file, using the name option will cause the interpretor to create a command for the widget using the string specified by the -name option. Ordinarily a widget instance would be created as follows:

set myButton [gnocl::button -text "Hello World"]

And modified with:

$myButton configure -onClicked { puts %w }

But now,  the following will produce similar results.

gnocl::button -text "Hell World" -name myButton

Modification can also be handled too,

myButton configure -onClicked {puts %w}

This approach provides a neat and efficient way of creating widgets as objects within namespaces. Using the same example the following could be used:

gnocl::button -text "Hell World" -name myprocs::myButton

The creation of widget with command names in this way does not eliminate the process of registering widgets with a unique id. Using the same example, to access this simply use:


and the widget id will be returned.

Substitution strings also unclude the %g and %w parameters to extract the (glade) name and w(idget-id) of the object.

New Extract

        o added extra percentage subtitution strings to -onPageAdded, -onPageRemoved
                %l page label
    gnocl::comboBox/comboEntry added new sub-commands: get, set, prepend, append, insert and remove.
    gnocl::box/hBox/vBox fixed problem with cget -children
    gnocl::window, gnocl::expander, gnocl::fontSelection, gnocl::gammaCurve,
    gnocl::curve, gnocl::handleBox, gnocl::level, gnocl::popupEntry, gnocl::recentChooser
        o added -name


vallinayagam said...

Hi, I want to have gnocl compiled with gtk3. gtk3 provides the flexibility of having web-backend using broadway. Meaning the widgets are rendered in a browser. It is a easier way to have web based tcl app. The present gnocl is compiled with gtk2. Can you help me in that migration.


William J Giddings said...

Hi Valli

Gtk3+ offers a host of great new features which aren't available in Gtk2+ and so the transition is relevant. However, with a package such as Gnocl, recompilation of the sources with the Gtk3+ libraries is not a simple matter and will effect the code at all levels. As you probably know already, many of the Gtk+ legacy widgets are abscent from Gtk3+, and many of the api calls have been deprecated. Whilst a Gtk3+ compliant version of Gnocl is desirable, it is not currently at the top of the priority list. I'm sorry that I can't be of much more help at this point in time.

However, if you do feel brave enough to attempt the basics of the transition, then I would be happy to collaborate. Bear in mind though, Gnocl a binding to the whole GTK library plus much more, its a lot of work and the API documentation is, at best, basic, and at worst useless!

If you have a single application in mind rather than creating a complete language binding, then one solution would be to create a custom Tcl application package into which you could build in a TCL API to only those widgets you need. There are plenty of details on package building on the Tcler's wiki. Once you've created a loadable package, at that point you could introduce code from the Gnocl main modules and work around any differences between GTK3+ and GTK2+ as you go. One possible additional benefit would be that your code overhead could be streamlined and fitted to your application requirements.

Best Wishes