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:
[myprocs::myButton]
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
2015-05:
gnocl::notebook
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
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:
[myprocs::myButton]
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
2015-05:
gnocl::notebook
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
Comments
Regards
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
WJG