gnocl

WJG 2009-04-02: Full installation details are given in the README file. Some of the new resources on offer do have dependencies which are not fully outlined in the README, I will resolve this problem soon. In general, the *.so files are now included for those who don't want to compile the package. As a minimum, I would advise installing support for the gnome vte and sourceview widgets (which should be there in most distros anyway). If there is the need to compile, then install development packages for glib, gtk and gnome vte, canvas and sourceview. Naturally, if you are running a slimmed down OS there may be some unforseen inherent problems in supporting additional packages. It should be noted, however, that only those widgets and libaries included within the official Gtk/Gnome distributions will be included in the complete Gnocl package.

joh: I've taken the freedom to add some information

gnocl can be compiled with Gtk 2.x and optionally with Gnome support. In fact most of the currently supported widgets do not require Gnome, so one can use gnocl as a comfortable (high-level) way to write Gtk applications in Tcl (8.3 and newer).

Community

Gnocl Google Group

Reference

screenshots

Documentation

official documentation

official documentation (older?)

Gnocl Blog

Description

Gnocl is a Tcl extension (package) that implements gtk+/gnome, not to be a direct mapping from gtk 2.0, but to provide easy-to-use commands to build quickly gnome-compliant user interfaces (including canvas widget). It is loosely modeled after the great Tk package.

CT: One of the strengths of Tcl and indeed Tk is their ability to run on many platforms without much O/S specific alteration (and in many cases, none). Is gnocl going to be available and well supported on the Windows platforms and at least OSX? I would be very interested in supplanting Tk for gnocl if this will be the case in the near future. Thanks.

RLH Maybe we can keep the "Google Summer of Code" in mind for next year to get help in improving stuff (implementing new functionality, documentation, etc.).

WJG 2008-11-23: Excellent idea. There's a lot to be done. Sure, the core widget set is supported but what would be useful is extending support for other resources, perhaps OpenGL. Printer support is integral to Gtk+ 2.10 and is on my list of todos. Documentation is still piecemeal, whenever I work on a section of the source code then I document what I find. Peter Baum, the original developer of Gnocl did a brilliant job, but he clearly kept much of the package work-flow in mind rather than on paper. If there is anyone out there using Gnocl, let me know, the Sourceforge monitor does show a regular trickle of downloads but it sure would be helpful to know how many folks out there are using Gnocl and for what sort of purposes. From my point of view, I'm really keen to keep the 'ball rolling' and see a great future ahead for this little known package.

Gnocl for win32

peterc 2008-11-14: Note that you also need the following DLLs on the system: LIBGDK-WIN32-2.0-0.DLL, LIBGDK_PIXBUF-2.0-0.DLL, LIBGLIB-2.0-0.DLL, LIBGOBJECT-2.0-0.DLL and LIBGTK-WIN32-2.0-0.DLL (says Dependency Walker).

RHO 2009-08-19: These DLLs are part of the installation of The Gimp for Windows (http://www.gimp.org/ ).

WJG 2008-11-23: Y'know, I really ought to try out the windows version, just to see what it's like.

Gnocl for Maemo

Tcl/Tk with gnocle on NOKIA N800

Create apps that take advantage of the touchscreen-specialised interface (Hildon) on Nokia 770 and similar devices. Since the N810 got released these tablets are becoming more popular, and at least a few Tcl'ers have them so hopefully we can get some momentum behind Tcl programming for Maemo!

Q&A

anon: Hi, I just started giving gnocl a try and wonder how to bind a context popup menu to <Button-3>, on a text widget.

WJG 2007-09-09: One of the problems for Tk programmers moving over to Gnocl is attempting to program Gnocl code assuming that it will behave like Tk. Whilst Gnocl works very well alongside Tcl, it in fact provides a Tcl binding to GTK and expects the programmer to produce genuine GTK applications rather than forcing GTK to behave like Tk. The code that Dr. Baum produced is stable, and since I now use Linux rather than Windows I have begun to rewrite, not recode, my scripts to suit the GTK way of working. Statements such as <Button-3>, of course mean nothing to GNOCL, and the gnocl::text widget specifically offers no binding for any mouse button events. This doesn't mean that the events cannot be handled, the current release (0.9.91) does not support them as the GTK method would be to prefer the use of tool bars.

Working with Dr. Baum I have a modified version of gnocl that responds to mouse button events. The current version doesn't support <KeyPress> bindings either, although work on these are in progress.

From my point of view, I'm surprised that a greater interest in GNOCL hasn't come forth. The basic GTK widget set is excellent and in many cases better than the Tk offerings. And, believe it or not, gnocl scripts are easier to code. There are some things missing, especially in with regard to the gnocl::text widget, but then Dr. Baum didn't really need fancy edit functions at the time of the last release.

DKF: I suppose part of the problem is that many Tk users use the text widget for things like custom hypertext as well as plain editable text. After all, it does both well, though it needs a few extra bindings to really take advantage of the advanced stuff. From what you say, it seems to me that gnocl::text doesn't work that way (probably for reasons best known to the GTK/Gnome people) and so (extrapolating) managing expectations when going between will continue to be awkward.

I do wonder if they've "borrowed" the pack and grid layout manager guts though. If not, why not? (They hadn't when I last looked, but I freely admit that was back in 2002.) They're really worth stealing and we don't mind. :-) But that's probably a bit off-topic.

WJG: I agree that the Tk text widget has a greater default offering than the current gnocl::text feature set, but implementation of these features is not too complex a task. I believe that the standpoint taken of implementing GTK is right, enhancements to provide typically Tk ways of doing things can be accommodated using pure Tcl packages. There are better Tcl programmers out there but even I, after a few hours work, have got the bones of an "bind <event> script" package working. My own Tcl/Tk apps have relied heavily on the text widget and see some shortcomings in the base gnocl set; these include a full equivalent of the text dump command, undo and tag insert. Mind you, the current gnocl version is still only 0.9.91.

If all else fails, take the 'belt and bracers' route - a hybrid UI based upon a mixture of GTK and Tk widgets!

tb 2008-04-30: BTW: Are there plans to port Glade as well? - Would be very nice, if one could use this UI designer for Gnome!

Lectus: I second that! To be really useful Gnocl should be able to be used with glade and integrate well into the Gnome Desktop. That would dump C for most of applications that could be easily written in Tcl. Besides that I don't see much reason to move from Tk/Tile.

WJG 2008-07-31: This question was raised during my presentation at LugRadio Live2008. Personally, I see little benefit in using Glade in connection with Gnocl. It would simply complicate the scripting process. Unlike PyGtk. PerlGtk or RubyGTK, Gnocl does not provide a wrapper around Gtk Library functions nor provide the scripter the opportunity to avoid using C. If there is need to use C, build a library, create a new widget or something more useful; something that enriches the scripting environment not something that makes it complex. What might be useful is a native Tcl/Gnocl GUI Builder. (Any offers to make one?) But then again, why? When Gnocl is so easy to use.

What do you imply by 'integrate well into the Gnome desktop'? Gnocl calls Gtk functions, has support for Gnome features such as applets, works well with the clipboard, drag and drop and has full theme support. Gnocl-GNOME Printing support has yet to be added, but this issue has always been a headache for Tk users for years.

From my perspective, tile has little to offer over pure Tk although I'm certain it has its uses. From a marketing point of view, perhaps Tile is a 'shot in the foot' as its gives the impression that Tk is outmoded (still works, but not fashionable). Lets face it, with or without Tile Tk no longer has the appeal of Gtk or Qt based GUIs on Linux boxes. Look at WxWidgets, for example. Another brilliant cross-platform widget set, that has no Tcl bindings and, well, puts Tk in the shade in all areas.

(PS. I'd be delighted to be proved wrong.)

Lectus: WJG, thanks for your answer. I've been looking into Gnocl examples and, like Tk, it's really easy to use even without GUI builder. But I still have 2 questions: where can I find documentation for it? And how does it look under Windows?

WJG 2008-09-20: Gnocl Version 0.9.92 is available for download

RLH 2008-11-24: Does Gnocl get all the printing facilities that Gnome/GTk+ has? Also, if Gnocl runs on Windows, does the printing work there as well?

WJG 2008-11-25: Support for the printing resources has yet to be implemented. And, Windows, it ought to!

db: Just speaking for me --- I am very interested in this project.

But, as an amateur programmer, what I need more than all of you is good documentation. In 1999, when starting my project MTE, I looked for all scripting languages providing Tk (i.e. Python, Perl, and Tcl). My decision fell on Tcl because of the (boring, thus excellent) documentation. (IN Perl and Python, the docs said: for more details, read Tcl/Tk docs. That's what I finally did.)

So, if gnocl has a comparable documentation, chances are well that also amateurs like me try it out!

WJG 2008-01-08: The online documentation for Gnocl is both clear and comprehensive and has lots of examples indicating how widgets are created. Also, there is an excellent set of demos which cover all the facets of the widget set and their configuration. Its simply the source code for the Gnocl package itself which is in the process of becoming documented. Give it a go, let me have your feedback. If there are any features that you would like considered for inclusion let me know and I'll see what can be done.

D. McC 2009-01-28: As I was just saying on another page ... I don't see anything in the Gnocl documentation about how to specify the size of a text widget--and, when I try, I get an error message saying "-height" and "-width" aren't among the configuration options for a Gnocl text widget. On re-reading this page, I note your suggestion about the "belt-and-bracers" approach: mixing Tk and Gnocl widgets, as you can mix Tk and Ttk widgets. The problem with that appears to be that you would have to use Tk or Ttk scrollbars with a Tk text widget (giving a pretty incongruous appearance), since there's no "gnocl::scrollbar" command; rather, you specify "-scrollbar" as a configuration option for the Gnocl text widget. Yes? No?

WJG 2009-01-28: True there are no -height and -width settings for the gnocl::text widget. This is because the GtkTextView has no height or width properties to set. A text widget is resized by its parent container, typically a gnocl::box or gnocl::window. As you mention, the -scrollbar option (one of always, never or automatic) determines when the scrollers appear. The gnocl::text widget really is a megawidget, providing a container for the text and scrollbars thereby saving pile of coding. The important thing to remember is that Gnocl is not Tk and some many things are done differently, naming conventions and ways of working are to provide a Tcl handle onto Gtk, rather than to emulate Tk using the Gtk libs. There is no gnocl::scrollBar because the its use is built-in, again saving the scripter time. The other widgets where is use of scollbars is built-in are gnocl::scrolledWindow and gnocl::tree. Finally, my orīginal idea behind the suggestion of using a "belt-and-bracers" approach is now historical. At the time, a lot of work needing doing on the gnocl::text widget which is now largely complete. Whereas the area lacking at the moment compared with Tk is support for an OpenGL widget. As the extension exists for Tk, it could be packed into a gnocl socket. It would be an interesting Wiki project. Any offers?

D. McC 2009 02-04: Sorry, I don't know enough about OpenGL widgets to do anything with them. In response to your invitation on the TileGTK page, though, here are a few things that I know how to do with Tk but not with Gnocl (if it's even possible).

* Make mini-toolbar buttons. In several of my apps, such as WISH Supernotepad, I use mini-toolbar buttons with text but no images, to take up the least possible amount of screen space. With Tk, it's easy to get buttons to be that small; you just specify zero or almost zero for -padx and -pady. Can you do that with Gnocl? If so, how?

* Elide text and make clickable links. In WISH Supernotepad and WISH User Help, I use the -elide feature of the Tk text widget to hide HTML-like tags and make clickable links, which take the user to the parts of a document that are specified by the links. I don't see that you can hide text or make clickable links with a Gnocl text widget. Yes? No?

* Bind mouse clicks on listbox lines to execute programs or procedures. In WISH Command Center, WISH File Rusher, and WISH Checkbook, I bind mouse clicks on listbox or ttk::treeview lines to execute programs or procedures. From reading the Gnocl "list" and "tree" documentation, I'm not sure whether you can do that or not, and I don't know how to do it if you can. Can you? If so, how?

* Precisely specify how much space each widget shall take up. In "Remaster Express," my first Gnocl app for Puppy Linux, I've got a window like this:

What I'd like to do is make the lower text widget only 8 lines high, to show the 7 lines of text and one blank line at the bottom--a snap in Tk (-height 8), but I don't see how to do it in Gnocl. (EDIT 2009 Feb 18: Now I do, and this screenshot shows it--but the old screenshot had the bottom text widget equal in height to the top one!) Here's the code ($box1 is the main program window, which gets changing contents at different steps of the Puppy custom live-CD remastering process; "writefile" is a little proc to turn three lines of code into one for writing a file):

set ::isobutt [gnocl::button -text {Change isolinux.cfg} -onClicked {
    set isodata [$isotext get {0 0} end]
    writefile $PUPBUILD/isolinux.cfg $isodata
    remaster_part7
}]
set ::noisobutt [gnocl::button -text {Don't Change} \
    -onClicked remaster_part7]
set ::abandon [gnocl::button -text Abandon -onClicked exit]
set ::isobox1 [gnocl::box -orientation horizontal -children [list\
    $::isobutt $::noisobutt $::abandon] -fill {1 1} -expand 1 \
    -borderWidth small]
set ::isotext [gnocl::text -scrollbar always]
$::isotext tag create mono -font $::monofont -fontSize 13
set ::isobox2 [gnocl::box -orientation vertical \
    -children $::isobox1 -fill {1 0.5} -expand 0]
$::isobox2 add $::isotext -fill {1 1} -expand 1
$box1 add $::isobox2 -fill {1 1} -expand 1

Thanks in advance for any information, help, or both you can give me!

WJG 2009-04-02: It is pretty safe to say that all the functions you are looking for are available in Gnocl. If you are using version 0.9.91 then seriously think of upgrading to 0.9.92 otherwise you'll not have access to the full range of text event bindings. My development version is 0.9.93a and it'll be a while until the next release -so make your contribution now! However, to answer your questions.

1) Mini toolbar buttons.

Assuming that you are using the gnocl::toolBar container there is a -style option. This can be set to use icons, text or both. Remember that you can also use the gnome theme's stock icons or create your own. Looking at the current source for the gnocl::toolbar itself, I wouldn't expect you to be able to set a -baseFont or -baseColor option. I will add this to my to-do list. I've not tried it myself, but add gnocl::button(s) into the gnocl::toolBar for which you can set the baseFont. Then the window manager will allocate size to the widget based upon the pango settings of the specified font rather than the system default.

Remember too that the Gnome desktop has its own 'styleguide' which may not exactly be what you're expecting when shifting over from Tk. If you do not want buttons to fill the gnocl::toolbar container then add them to a gnocl::box container using -fill {0 0} -expand 0 settings to position and cluster the buttons into the left corner. {0.5 0} will position the widget in the middle, and {1 0} totally to the right. This is because fill options are not-booleans but proportional markers that allow you to position items within their container (somewhat like Tk's place). See the Gnocl demos for a really thorough treatment of widget positioning.

2) Text.

Elide. This is equivalent to the gnocl::text tag option -invisible, it is a boolean and defaults to 0. Set it to 1 to hide tagged text. Gtk handles tag events differently when compared to other objects. Here use the -onEvent option.

3) List events.

This is one of the widgets that needs a re-write of the manual page. Again, all the button events are supported but listed on the Tree manual page.

4) Widget sizing.

We corresponded on this matter earlier, usually you can request a widget size. However, if the windows manager does not give you the size you expect, try this workaround. In the script which creates the UI first fill the object with some data, then add it to the container. The manager will then know how much size to allocate to the widget before rendering the whole window to the display.

I hope that these notes answer your questions keep your interest in Gnocl alive. The package is exciting, is has a lot to offer such as full drag and drop and rich text cut-n-paste. Remember there are other features that are available that Tk doesn't interface, such as the Gnome desktop applet bar. Gnocl is for creating authentic Gtk/Gnome applications and aimed at dramatically reducing your coding overhead. But then I think you probably know this. After all, you have chosen to use Gnocl rather than PyGtk or some similar binding.

D. McC 2009-02-14: Hey, this isn't too bad at all once you get used to it. In some ways (though not all), it's actually easier than Tk. Here are links to an announcement and screenshots (in the Puppy Linux Discussion Forum) of my first completed Gnocl app, "Remaster Express," for Puppy Linux custom live-CD remastering.

http://www.murga-linux.com/puppy/viewtopic.php?t=38388 (screenshots)

http://www.murga-linux.com/puppy/viewtopic.php?t=38707 (announcement)

I did figure out how to get the lower text widget in one of the windows to be only about 8 lines high (see above), and it was pretty easy once I got the basic idea and engaged in only a small amount of trial and error:

set isotext [gnocl::text -scrollbar always]
$isotext tag create mono -font $::monofont -fontSize 13
$isotext insert end $isolin -tags mono ; # Content of text file
set ::isotable [gnocl::table -homogeneous 1]
$::isotable add $isobox1 0 0 ; # Box with buttons
$::isotable add $isotext 0 1 -rowSpan 4 ; # Text widget is 4 times as high as box with buttons
$box1 add $::isotable ; # Add to existing widgets in main window

I think I'll try Gnocl again before too long--especially if I can get a Slackware-style binary tarball for Gnocl 0.9.92, which can easily be turned into a ".PET" package for Puppy Linux.

WJG 2009-02-15: I'm so pleased that all went to plan and how you've found Gnocl so easy to use. Gnocl has so much to offer the Linux developer, direct access to Gtk! Keep those apps rolling in! How about giving Planet Gnome [L1 ] a simple write-up on how you've used Gnocl in creating this Puppy maintenance tool. This really is the sort of news item that gets posted there besides this it would increase the profile of Tcl too which, judging by the state of affairs at the moment, would be most welcome.

D. McC 2009-Feb-20: I might look into writing a little something for Planet Gnome after Puppy 4.2 is released, if Remaster Express is included, as it looks like it probably will be. Right now, though--as I was just saying--I'd like to get a Slackware-style binary tarball for Gnocl 0.9.92, which can easily be turned into a ".PET" package for Puppy Linux. If you can come up with one (compiled for 32-bit x86 systems) or let me know how to come up with one fairly quickly, it could probably get into Puppy 4.2 as a version upgrade from Gnocl 0.9.91, which has been built into the Puppy 4.2 alphas and now beta 1. Yes? Please?

I tell you what, in exchange for the Slackware-style tarball, I'll get you a complete new set of screenshots for the Gnocl documentation featuring good-looking GTK+ 2.0 themes, to replace the outdated ones in the Gnocl 0.9.91 documentation (unless you've already replaced them in the 0.9.92 documentation). How does this look for a sample?

WJG 2009-02-09: Slackware Tarball... I'll see what I can do. And yes thank you, it would great to get some new screen shots. Indeed, if anyone out there is interested some help on bringing the user docs up to date would be useful too!. And.. and.. a few more test users would be warmly welcomed too! D McC, yes I really like the screenshot, as this is what themes is all about: making your own mark, making it feel comfortable for yourself, the right colours, backgrounds witty icons and so on. Great stuff! Hey, are you interested in this feature, its one in the pipeline for the 0.9.93 release... toplevels with holes in them! Courtesy of clipping masks. Its a bit of a curiosity, programming Marmite [L2 ], but I'm sure that someone's bound to want it!

By the way, the window decorations can be turned off too!

D. McC 2009-02-20: OK, I've started making the screenshots; I'll finish up by tomorrow, I hope. I'm interested in improving the documentation, but I'll need Gnocl 0.9.92 to make sure I catch all the latest features. :o) All that's needed for the Slackware tarball is three files (for Puppy, at least, the documentation goes into a separate package.) If you can get the 0.9.92 versions of these to me, I can do the rest (well, unless 0.9.92 needs more files than 0.9.91):

/usr/lib/tcl8./gnocl.so

/usr/lib/tcl8./gnoclCanvas.so

/usr/lib/tcl8./pkgIndex.tcl

As for the toplevel with holes in it ... um, it looks fascinating, but I'm having a bit of trouble figuring out what it's good for!

WJG 2009-02-20: I thought that you might ask that question. Clip masked toplevel windows can help make desktop gadgets like a clocks, controller panels for media players or even flashy looking splash screens. Having a big holes drilled through widgets is a little odd, I agree.

Here's a screenshot of a desktop clock that I've hacked together using some clipart for the dial and some reworked clockcode from the wiki. With the exception of the outline of the clipping mask, everything is anti-aliased and running smoothly. Makes me want to create a suite of Gnocl desktop Gadgets!

D. McC 2009-02-20: I went home from work with a cold this afternoon, but fortunately I wasn't too sick to sit around and engage in the restful activity of making screenshots. I got almost all of them done, together with a few pages of Gnocl 0.9.92 documentation I changed as follows:

x351.html had "tabuttonble" instead of "table"--fixed

r3834.html now has "-scrollbar always" in text widget

r4533.html now has fraction 0.68 to show percentage through translucent progressbar

Here they are--let me know if you think any of them need any changes:

http://puppylinux.asia/members/pa_mcclamrock/gnocl_changes_Feb_2009.tar.gz

(EDIT 2009 Feb 21) Oops, I just noticed I left out a few lines of code for the toolBar widget; it's supposed to have an entry box and a "Find" button. Here's the whole thing:

The only screenshot that should be in here but isn't, I think, is for appletFactory, and it isn't here because of this error message:

% package require gnoclGnome

'''can't find package gnoclGnome'''

I got this error message with both the Gnocl 0.9.91 and 0.9.92 packages that have been prepared for Puppy Linux. It would be really nice if a Gnocl 0.9.92 package that doesn't give this error message could be included in the forthcoming Puppy 4.2. Also, from what I can figure out so far from the documentation, it appears that the text widget in Gnocl 0.9.92, but not 0.9.91, would support clickable links. If so, I should be able to re-do the user help windows for my apps in Gnocl, and see about doing the same with at least some of the apps themselves--if I can just get a stable, complete Gnocl 0.9.92 package installed on my computer!

Unfortunately, I have approximately zero experience at successfully compiling programs from source code. (I have a bit of experience at unsuccessfully trying to compile them, but I'm pretty sure that doesn't count!) Could you please, please find the time to compile Gnocl 0.9.92 in a form that can then be packaged for inclusion in Puppy 4.2? If so, many thanks in advance!

RLH: I thought it was: package require Gnocl

D. McC 2009-02-23: You need "package require Gnocl" for anything in Gnocl to work. Additionally, according to the documentation, you need "package require gnoclGnome" for the appletFactory feature of Gnocl to work. Interestingly, with the Puppy Linux Gnocl package I'm using, you also get an error message if you capitalize the initial G in "GnoclGnome," but it's a different error message:

% package require GnoclGnome
couldn't load file "/usr/lib/tcl8.5/gnocl-0.9.91/gnoclGnome.so": /usr/lib/tcl8.5/gnocl-0.9.91/gnoclGnome.so: cannot open shared object file: No such file or directory

So it appears that there's supposed to be an additional shared object, gnoclGnome.so, which has been left out of the Puppy package.

WJG 2009-02-23: To get everything, download from here [L3 ].

D. McC 2009-02-23: OK, I did, and the compiling procedure looked easier than the ones I didn't succeed at before, so I gave it a try--with partial success. I got gnocl.so and gnoclCanvas.so all right; these were the only two shared objects in the Gnocl 0.9.91 package for Puppy Linux, so I packaged the 0.9.92 versions up with a pkgIndex.tcl file, tested the package to make sure it worked, and posted it for proposed inclusion as a version upgrade in Puppy 4.2.

I got error messages when I tried to compile gnoclGconf and gnoclGnome, though. They're pretty long; let me know whether you want to see them and, if so, how and where you want to see them.

WJG 2009-02-24: To successfully compile the gnome extensions you'll need to install the gnome-libs-devel package from your installation sources. Good luck with Puppy -woof, woof! (or is it yap, yap?)

D. McC 2009-02-28: It's "woof, woof"--much more dignified than "yap, yap"! :o) I'm pleased to see that Gnocl 0.9.92 is included in Puppy 4.2RC1, which just came out a couple of days ago.

D. McC 2009-03-03: OK, I'm now trying to rewrite WISH User Help in Gnocl, and I've got one big question: How do you search for text in a Gnocl text widget? I'm not seeing anything about this in the Gnocl 0.9.92 documentation.

WJG 2009-03-03: Y'know, I really ought to make the new release available soon, this is a 0.9.93 feature. RLH Yes, you should! :-)

D. McC 2009-03-03: Are you looking for any alpha or beta testers?

WJG But, it can still be done on the Tcl side with a little cunning... [L4 ]

D. McC By the time I get done with all the rewriting that doesn't require text searching, you'll probably be done with Gnocl 0.9.93. :o) Plus, that way, I'll be better equipped to say whether there are any more features that need to be added.

WJG 2009-03-05: I've just uploaded my zip of my current development directory to Sourceforge [L5 ] give it a go. Read the NEWS file first for an overview of changes. For more details, refer to my developer docs.

D. McC 2009-03-06: OK, I've got it, and the binaries work without me needing to compile anything (thanks!)--except I've found a couple of features that should work according to the Gnocl 0.9.92 documentation, but don't. In a gnocl::list widget, using Gnocl 0.9.93a, I couldn't set "-autoResize" and I couldn't find out "-fontSize" for a column:

 Error in startup script: bad option "-autoResize": must be -width, -clickable, -maxWidth, -minWidth, -reorderable, -resizable, -sizing, -titleAlign, -title, -visible, -onEdited, -onCellData, -align, -visible, -xPad, -yPad, -renderWidth, -renderHeight, -value, -background, -foreground, -editable, -font, -fontFamily, -fontRise, -fontScale, -fontSize, -fontStretch, -fontStyle, -fontVariant, -fontWeight, -strikethrough, or -underline
    while executing
 "$listeau($act) columnConfigure 0 -minWidth 92 -autoResize 0"
    (procedure "list_setup" line 166)
    invoked from within
 "list_setup"
    (file "./gwishcheck" line 326)

 Error in startup script: bad option "-fontSize": must be -width, -clickable, -maxWidth, -minWidth, -reorderable, -resizable, -sizing, -titleAlign, -title, or -visible
    while executing
 "$listeau($act) columnCget 0 -fontSize"
    (procedure "list_setup" line 177)
    invoked from within
 "list_setup"
    (file "./gwishcheck" line 328)

As for things that aren't actually bugs, but merely the absence of ascertainable features . . . well, this page is getting a bit long already, so I think I'll start a new page entitled Gnocl Q's and A's.

WJG 2009-03-25: Gnocl 0.9.94 Now ready for download from Sourceforge [L6 ]

D. McC 2009 Mar 26: Thanks! Hey, what happened to 0.9.93? Is this already the stable release of 0.9.94, not just an alpha or beta?

WJG (25-Mar-09) There were so many changes recently in the code and the documentation that shifting the digit would make the emphasis more clear. The Gnocl source has always been stable and the increments simply reflect the extending level of Gtk support. Now only one core widget, the assistant needs to be implemented and the forthcoming releases will focus on building up the range of widget options and commands. The remaining, GIMP specific widgets are tagged for deprecation so these are not so important. The only are of instability that I'm aware of is the gnocl::applet which suffers some memory leakage in later releases of Gtk. The matter is still under investigation but was not a problem in earlier releases of Gnocl/Gtk. The 'biggy' looming on the horizon is completion of the support for glade and builder files. I'm not keen on Glade, but others like it. Also in the pipework is support for modifying the widget styles (not properties) on the fly. New modules for consideration is image and bitmap manipulation using the Gtk image manipulation libraries.

WJG How are things with Puppy? By the way, don't forget to rebuild the documentation!

PS: There are some as yet undocumented features, gnocl::tree now supports -ruleHint (ie.alternating stripy rows) and toggling -treeLines. Try sorting that lot out in C or Python! And, of course, if anyone wants to contribute to the project let me know. There's only so much I can do in the course of a day and there is still much to do!

D. McC 2009-03-27: "How are things with Puppy?" -- Puppy Linux 4.2, featuring (among other things) Tcl and Tk 8.5.6, Gnocl 0.9.92, and two actual Gnocl scripts I wrote (Remaster Express, about 70 KB, and a little 850-byte screenshot-taking script), is now up to RC4 and supposedly almost ready for final release. I asked if it was too late to get Gnocl 0.9.94 in as a version upgrade, and it was. I'll compile it, package it up, and announce it in the Puppy Forum (http://www.murga-linux.com/puppy/ ) fairly soon after I get done with last-minute changes to Remaster Express. With any luck, it should be possible to get it into the version of Puppy after 4.2.

"By the way, don't forget to rebuild the documentation!" -- Will do. (The Gnocl 0.9.92 documentation, including the colorful screenshots from my Puppy system, is now an official Puppy package available for download from the Puppy repositories at ibiblio.org and elsewhere.)

"if anyone wants to contribute to the project let me know" -- Don't ask me to contribute any C code (I'm just a hobbyist who can't write code in any language but the easiest, Tcl), but I'd like to help improve the documentation. Here are the steps I foresee: (1) Install Gnocl 0.9.94. (2) Use it to rewrite my Tcl/Tk apps with Gnocl/GTK+ widgets instead of Tk ones. (3) On the basis of this experience, add some clarification and examples to the documentation.

"There's only so much I can do in the course of a day ..." -- Oh, is there? (LOL) Um, me too--but I've actually got a working Gnocl version, not just a GUI mock-up, of at least one of my apps (WISH Command Center) almost done. Here it is, with the Clearlooks-Aquaviva GTK+ theme (another of my contributions to Puppy 4.2). (The logo still says "Tcl/Tk," but those in the know will recognize the GTK+ widgets; I don't think you can put checkboxes in a Tk listbox or Ttk treeview widget.)

D. McC 2009-03-27: As for rebuilding the documentation . . . OK, I downloaded Gnocl 0.9.94, unzipped it, read that I needed doxygen to generate the documentation, got the Slackware 12.2 doxygen package, converted it to a .PET package for Puppy, installed it and Qt which it requires, ran the doxywizard GUI . . . and was a bit unsure what to do with it. I'm supposed to "specify the working directory from which doxygen will run"--is this just the directory doxygen is installed to, or what? Then I'm supposed to "specify the directory to scan for source code"--is this the entire /src subdirectory of my gnocl-0.9.94 directory? Please excuse the rudimentary nature of my questions, but (as you can easily see) I've never used doxygen before!

WJG 2009-03-28: Ok. The documentation basically relates to the C-code itself and the details on the various options and commands moved into text files the ~doc/usage directory but still accessible from the new docs. Once you've installed doxygen return to the src directory and run 'make doc' and doxygen will do the rest. As the doxygen is set up create diagrams for the dependecies and function calls it will take a few minutes to complete the first run. Beware though! The job of documenting the code is not systematic, but simply based upon how and when I do maintenance and development work on the separate modules. I see the need for Tcl/Gnocl only documentation but for me I cannot see a complete separation from the C code as from my viewpoint Gnocl is a Gtk development tool. The use of Gnocl with Tcl makes the whole process simpler.

D. McC 2009-03-28: And now for a bit of a problem with Gnocl 0.9.94 itself: As I did for 0.9.92, I built a basic Puppy package for Gnocl 0.9.94 using the gnocl.so and gnoclCanvas.so binaries that came with the /src directory; I added the new gnoclVTE.so and modified pkgIndex.tcl accordingly. When I tried "package require Gnocl" after installing this package, I got the following error message:

couldn't load file "/usr/lib/tcl8.5/gnocl-0.9.94/gnocl.so": libvte.so.9: cannot open shared object file: No such file or directory

I couldn't find libvte.so.9 either in /src or in /src/vte, so I can't just add it to the package. What do I need to do?

WJG 2009-03-28: The hazards of expanding support for other Gnome resources. What you need to do is to install the developer package for the Gnome virtual terminal emulator. Here's the wiki page with an example [L7 ]. Useful eh?

D. McC 2009 Mar 29: Probably so, but it's not useful to have the basic "package require Gnocl" command evoke a non-negotiable demand for a library that isn't included in gnocl.so. I'd like to try out gnoclVTE and see what it can do, but I'm pretty sure the final Puppy package for Gnocl 0.9.94 should include only gnocl.so, gnoclCanvas.so, and pkgIndex.tcl, as the 0.9.92 package included in Puppy 4.2 does. (The documentation and demos for 0.9.94, as for 0.9.92, would be in a separate package available for download.)

The reason for this is that Puppy is a small Linux distribution, with a big emphasis on "small." One of the "selling points" for keeping Gnocl in future Puppy versions should be that it doesn't take up a lot of space but you can use it to write small scripts with good-looking GUIs that can do a lot, and even replace larger compiled programs. For this, Gnocl and gnoclCanvas need to be self-contained. More generally, it seems to me that Gnocl is designed to be modular, such that you can use the modules needed for a particular script and leave the others out (except the Gnocl core). So, although "package require gnoclVTE" may evoke a demand for libvte.so.9, "package require Gnocl" (IMHO) should not.

( ZB Can't see a reason for such expectation. Gnocl just has its own dependencies, exactly as any other software has, when compiled to use shared libraries. )

The bottom line is that I really need a gnocl.so that doesn't demand libvte.so.9, and I would strongly recommend that you recompile the binary after excising the demand for that (and any other external libraries) from the source code. My second choice (an inferior one) would be to excise the demand and recompile the binary myself, but for that I'd have to know where in the many source-code files the demand arises. Also, if you did it yourself, you could be sure you wouldn't have to explain again to someone else why you can't just download the Gnocl package and use the included gnocl.so binary as is. Please help!

WJG 2009-03-29: Some good points. Making a slimmed down version distribution for Puppy is no major problem. I'll simply package together the binaries and the scripting documentation. Along with a simple shell installation script.

D. McC 2009-03-29: Thanks! A Slackware-style (or similar) binary tarball would be really easy to convert into one or more Puppy packages. Then, when I can run "package require Gnocl" (0.9.94) without getting an error message, I'll be able to see whether I can actually rewrite all or most of my Tk apps with Gnocl. It looks pretty promising, from a first glance at the new features!

WJG 2009-03-29: Minimal installation package now available from Sourceforge [L8 ] in .tar format.

D. McC 2009-03-29: Thanks--I installed it, but I still got the same error message:

couldn't load file "/usr/lib/tcl8.5/gnocl-0.9.94/gnocl.so": libvte.so.9: cannot open shared object file: No such file or directory

It appears that not all references to libvte.so.9 were removed before gnocl.so was compiled. Please try again--I'd really like to see Gnocl 0.9.94 in action!

ZB: You just need to install VTE (experimental terminal emulator widget) in your system. What a problem?

D. McC 2009-03-31: I already explained "what a problem." Even gnoclCanvas is optional, not required. VTE should be the same. Had you seen any of the disputes about whether Tcl, Tk, and Gnocl should even be included in Puppy Linux at all, you might agree.

ZB ...so it's not about libvte.so.9, if you don't want VTE module at all; then all you need to do is just to set "USE_VTE := no" in the Makefile. That's all. Or maybe you just need two separate binary gnocl packages: "full version" for yourself, and "light" for including in Puppy.

D. McC 2009-03-31: I cd'd to my gnocl-0.9.94/src directory, set USE_VTE := no in the Makefile, ran "make gnocl" (which was all I needed to do to compile Gnocl 0.9.92), and got a long sequence of error messages, of which these are samples:

# make gnocl
Package vte was not found in the pkg-config search path.
Perhaps you should add the directory containing `vte.pc'
to the PKG_CONFIG_PATH environment variable
No package 'vte' found
cc -c  -Wall -pedantic -fPIC -DVERSION=\"0.9.94\" -DUSE_TCL_STUBS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0   -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/X11R7/include   -I/usr/include/tcl8.5 -I/usr/local/include/gtksourceview-2.0 -I/usr/include/libglade-2.0/ -I/usr/local/include/gtkhtml / -o gnocl.o gnocl.c
In file included from gnocl.c:274:
gnocl.h:28:17: error: tcl.h: No such file or directory
gnocl.h:30:1: warning: C++ style comments are not allowed in ISO C90
gnocl.h:30:1: warning: (this will be reported only once per input file)
In file included from gnocl.c:274:
gnocl.h:58: error: expected ')' before '*' token
gnocl.h:59: error: expected ')' before '*' token

[ . . . ]

gnocl.c:846: warning: excess elements in struct initializer
gnocl.c:846: warning: (near initialization for 'commands[68]')
gnocl.c:849: error: 'gnoclAboutDialogCmd' undeclared here (not in a function)
gnocl.c:850: warning: excess elements in struct initializer
gnocl.c:850: warning: (near initialization for 'commands[69]')
gnocl.c:858: warning: excess elements in struct initializer
gnocl.c:858: warning: (near initialization for 'commands[70]')
gnocl.c:881: error: expected ')' before 'clientData'
gnocl.c:924: error: expected specifier-qualifier-list before 'Tcl_Event'
gnocl.c:926: warning: struct has no members
gnocl.c:950: error: expected ')' before '*' token
gnocl.c:967: error: expected ')' before 'clientData'
gnocl.c: In function 'tclTimerFunc':
gnocl.c:1088: warning: implicit declaration of function 'Tcl_DoOneEvent'
gnocl.c:1088: error: 'TCL_DONT_WAIT' undeclared (first use in this function)
gnocl.c: At top level:
gnocl.c:1102: error: expected ')' before 'data'
gnocl.c:1156: error: expected ')' before '*' token
gnocl.c:1199: error: expected ')' before '*' token
gnocl.c:1212: error: expected ')' before '*' token
gnocl.c:1223: error: expected ')' before '*' token
make: *** [gnocl.o] Error 1

"That's all"?!

WJG 2009-04-03: As a rule of thumb, whenever I see a long list of errors like this then I know that some necessary dependecy is missing. So, look for an answer right at the top of the list. And, I can see that as the file tcl.h is missing, the tcl-devel package needs installing from the distro repositories.

ZB: I've prepared for William a new version of Makefile, but probably he just need a while to make his final tests. But I'm pretty sure, he'll upload new package to SF very soon.

Meanwhile you can take the tarball directly from my FTP: ftp://ftp.ispid.com.pl/free/gnocl-0.9.94.tar.gz

It has been tested by me, and the compilation - if your system will satisfy dependencies - should be done without any problems. Of course, use switches in the Makefile to in/ex-clude modules. Then just "make install".

(Tried to sent the above at your e-mail address, but got "Access denied - contact [email protected]")

D. McC 2009-04-01: Thanks, I downloaded the tarball, unpacked it, edited the Makefile, and ran "make gnocl" (not "make install," because I need to create a Puppy package and make sure it installs correctly)--but I still got the same kind of error messages as before (no fooling!). If you can successfully compile gnocl.so and gnoclCanvas.so binaries that will work on 32-bit x86 Linux systems without dependence on any external libraries, is there any chance that you might just do it and put them on your FTP site, so I can get going with Gnocl 0.9.94 without further delay? If so, thanks in advance!

ZB: OK, try this one: ftp://ftp.ispid.com.pl/free/dmcc.tar.gz - unpack and replace your older 0.9.92 modules with these (not sure, is gnoclSourceView.so really needed, but it has been made, so I've included this one too).

D. McC 2009-04-01: Thanks--I unpacked it and put it in a gnocl-0.9.94 subdirectory of /usr/lib/tcl8.5, but the gnocl.so in here still doesn't appear to have been recompiled to remove all demands for libvte.so.9:

% package require Gnocl
couldn't load file "/usr/lib/tcl8.5/gnocl-0.9.94/gnocl.so": libvte.so.9: cannot open shared object file: No such file or directory

ZB: OK, have another one: ftp://ftp.ispid.com.pl/free/dmcc2.tar.gz - this time I "manually" changed the Makefile. Pay attention, that it's totally untested - but even in case of problems it won't blow your machine, anyway.

D. McC 2009-04-02: No, it didn't do that, and it even gave me a different error message than before. Now it wants "libgio-2.0.so.0":

% package require Gnocl
couldn't load file "/usr/lib/tcl8.5/gnocl-0.9.94/gnocl.so": libgio-2.0.so.0: cannot open shared object file: No such file or directory

ZB: It seems, unfortunately, that your system is not satisfying dependencies of Gnocl. You cannot expect it'll be working without needed libraries.

WJG 2009-04-03: libgio-2.0.so.0 is a dependency of the gtk2-devel package. Check to see if this is installed.

D. McC 2009-04-02: Gnocl 0.9.92, now built into Puppy Linux 4.2, works just fine. All I'm asking for is a Gnocl 0.9.94 package that will do the same. The inclusion of Gnocl in Puppy is a great opportunity for Gnocl to become better known and more widely used, but the opportunity will tend to fizzle out if Gnocl 0.9.94 won't work without dependencies that Puppy doesn't have.

ZB Frankly: I'm not sure, what exactly made the difference - but pay attention, that 0.9.94 means "newer version", that can have somewhat higher demandings, because it has more to offer. Besides: it's working at least in William's system (SuSE) and that of mine (Gobo) - so I really can't see a reason why it shouldn't be working in Puppy. All you've got to do is to compile the package, having installed needed s.c. "development libraries". It seems, that differences between our distros are too big to allow "direct transfer" of compiled Gnocl's binaries ("libgio" is part of "GLib" library, needed by GTK+ 2.4.14, so it's not possible to cut it out).

D. McC 2009-04-02: Puppy 4.2 has GTK+ 2.4.12. If all I need to do is to await the arrival of GTK+ 2.4.14 or greater in an alpha release of the next version, with all needed dependencies including libgio, I can live with that. I'll check at that time and make sure the unfortunately excessive Puppy craze for cutting things out hasn't extended to libgio. (Puppy 4.2 does have a glib-2.14.2 package, but it doesn't include libgio.)

Meanwhile, I've got plenty of things I can do (or try) with Gnocl 0.9.92, and just today I figured out a way to make clickable links to various user help pages with only standard Gnocl 0.9.92 commands. I would strongly suggest, though, that the best chance of getting Gnocl 0.9.94 into a future version of Puppy will be to reduce the number and size of dependencies for the basic Gnocl package as far as feasible.

ZB: Maybe the dependency can be satisfied by installing GLib in addition (I cannot guarantee, since you have a bit older GTK+)? Just try to google for "puppy linux Glib" - surely someone prepared such package... mine is GLib 2.18.2. (a bit later: ...and indeed: http://www.puppylinux.asia/tpp/ttuuxxx/puppy420/RC3/glib-2.20.0-i386.pet username: puppy password: linux)

WJG 2009-04-03: I think that the underlying issue here is that I'm trying to expand Gnocl support to included the lastest options available from the Gtk and Gnome libraries, and of course, there are inherent problems with this. For most user/developers this issue is Distro/Version specific. Differing distro and releases have their own level of support for the various Gtk/Gnome libraries. For instance, I develop under OpenSuse 11.1 which uses Gtk 2.14.4, but of course the lastest stable release of Gtk is 2.16. This is binary compatible with 2.14 and has some good enhancements, some of which are really easy to implement in the Gnocl source but will adding these features cause dependency problems for others? [L9 ]. One thing is for sure, these matters try our patience, not with the code, but with ourselves! Ah, the Zen and the Art of Programming! I will include a list of the build dependecies in the README file.

D. McC 2009-04-03: "trying to expand Gnocl support to included the latest options available from the Gtk and Gnome libraries": Great idea if you can do it in a fully modular way, such that those who want or need the latest options can easily select them, and those who don't can just as easily reject them. The best way to do this, I would strongly suggest, is to make sure you have a gnocl.so for 0.9.94 that will run with no external dependencies other than the obvious Tcl and GTK+ 2.x (if possible), as gnocl.so for 0.9.92 does; then bring in the demands for dependencies only as needed for each additional module, e.g., libvte.so.9 for VTE. If you absolutely must have some external dependencies (e.g., libgio?) to get the core features of Gnocl 0.9.94, please say so, and I'll see what I can do about getting the absolutely essential dependencies into the next version of Puppy Linux.

D. McC 2009-04-03: UPDATE: Guess what! Looking around the Puppy Forum, I found a thread entitled "Glib 2.20.0 Puppy 4.0+ Full Version" (http://www.murga-linux.com/puppy/viewtopic.php?t=39736 ). It seems that Gnocl isn't the only thing adversely affected by the lack of libgio (and other libraries) in the cut-down Glib package built into Puppy 4.2. So, a very active Puppy developer packaged up the whole thing, which I've now downloaded and installed (see ZB's message above for the download link, though not the favorable comments on how well the "full version" package works, which I found very helpful). Then I reinstalled Gnocl 0.9.94 from ZB's "dmcc2.tar.gz" and ... drum roll ...

% package require Gnocl
0.9.94

Success! Now to go full speed ahead (so to speak, as far as my very limited spare time allows), and see how many of my apps I can rewrite with Gnocl. Thanks again to WJG and ZB for providing binaries to the "compiling-challenged," including me!

ZB: You're welcome, glad to read it. :) WJG Give that man a round of applause, wuf-wuf.

[RLH] - This has been quiet. Did the project stall?

WJG 2009-09-29: No, gnocl development is still active. Extending support for key and desirable features takes a lot time and, to be honest, I have other things to do. Gtk+ development is still moving along and the recent release of Gtk has a new widget in the set that needs implementing.

Sorry if I sound like a broken gramophone, there are 2 hurdles to progress. I love Tcl and have been writing lots of project based tools using it but it seems, to me at least, that there is a waning interest in Tcl and a waning interest amongst Tcl users in graphic frontends other than Tk! Apart from the Gtk+ libraries there are so many exiting Gtk/Gnome resources out there. Unlike the other language bindings to Gtk, Gnocl is not a wrapper. Support for new resources needs largely unique code to create a custom fit between Tcl and Gtk which is time consuming. There is interest in using but not developing new features. The bottom line of this is that development is needs driven, if I need it then I'll work on it. Some work has been contributed by others, such as tidying makefiles and the Gnocl Applet, but this has been bug-fixing rather than active development. Extra project contributors would be welcome!

At the moment the task right at the top of the list of 'things to todo' is a complete re-organisation of the source and makefile to facilitate the development of gnocl, canvas, gnome etc., as separate stand-alone projects. This means that should anyone else want, lets say, to build upon the stubs poppler support for the display of PDFs, they can do it as a new, unique project. There are lots of stubs at the moment, the basic code templates that need working upon. If anyone wants to work on any of these, I'd be grateful for the extra hands. Perhaps I should issue an invite for project help on SourceForge?

RLH: I hope that you are going to continue. I am not a C coder and barely a Tcl one. However, I think Gnocl is a great alternative to Tk and it should continue on. If I can help, in other ways please let me know.

WJG 2009-09-29: Thanks, I might take you up on that offer! !

APN: WJG, I very much hope you keep at it without getting discouraged. From personal experience, I can say it takes a while for even free stuff to get traction and draw interest. BTW, does the toolkit come with cross-platform printing support? That would immediately make it a serious alternative to Tk for me.

WJG 2009-09-29: The Gnocl code for printing support is stillmuch a stub which needs a lot of detail adding to it. Its not a question whether Gnocl has it, but is there Gtk support for it. There certainly is under Linux and I believe that there is support under Windoze too. MacOSx, I'm not certain. Take a peek at the Gtk homepage for more [L10 ].

ZB: So you need truly experienced C-programmers, with good knowledge of TCL-library...

ZB: Hi there, good to hear from you. The 'templates' for adding new objects are already there and, suprisingly, there's little need to refer to any Tcl source documentation! The major task is getting to know the Gtk/Gnome and other libraries for which the docs are either not complete, or written in 'Panglish' [L11 ] rather than 'English'. For the greater part of the code base, the structure is there there, some details that are lacking. Also, where does one stop? Should a Gnocl widget implementation be the bare minimum or add rich features? Personally I like the idea of 'rich' rather than 'basic'. Are you interested in working on a specific part of the code? Or would like to implement, or already have, implemented a resource which could be shared?

ZB: OK, I'll contact you via e-mail. I've got a feeling, that every time-critical feature - for example: collision-check for the canvas objects - should be rather implemented in C, as ready-to-use feature. All the less time-critical ones can be left to TCL-programmer.

WJG 2009-10-27: I've just uploaded a modified release of 0.9.94 of Gnocl which basically addresses some long-standing issues over memory loss in running Gnome applets. Having said this, however, there's probably something of interest in there for Gtk enthusiasts. Here's a summary of changes:

new widgets: (partial implementation) gnocl::ruler, gnocl::calendar, gnocl::curve, gnocl::gammaCurve, gnocl::assistant

new commands: gnocl::signalStop, gnocl::beep, gnocl::grab

gnocl::comboEntry new options: -entryWidth, -widthChars

gnocl::entry new options: -align

gnocl::menu command popup enhanced to support exact positioning with x y.

gnocl::window new options: -onFocusOut -onFocusIn -onActivateDefault -onActivateFocus -onFrameEvent -onKeysChanged -onSetFocus

gnocl::text new commands: save = serialize, load = deserialize (i.e. load/save rich formatted text)

gnocl::entry new command: setPosition (problematic); new options: -onInsertText, -onKeyPress, -onKeyRelease

gnocl::winfo new command: geometry

gnocl::text new option: -spellCheck (requires GtkSpell)

jys 2009-12-06 08:20:06

Have been playing around with Gnocl today. It's very nifty, though unfortunately it feels like it still needs a lot more polish and coverage of GTK widgets. Some frustrations I've come across so far:

Lack of documentation for aboutDialog and statusIcon (which I guess are incomplete anyway).
No DnD-able tree widget?
When I have a boolean column in a tree, trying to toggle it doesn't do anything. (This gets spat out to stderr: Gtk-CRITICAL **: gtk_list_store_set_valist: assertion `GTK_IS_LIST_STORE (list_store)' failed)
Percent string thing feels really clunky. Would prefer -markup/-stock/-underline/etc. options instead.
Would be nice if Tk's image code was ported and integrated into Gnocl, including compatibility with img.

That all being said . . . OMG shiny!! x3 This is pretty awesome, and it breathes some new life into writing Tcl-based GUI apps. I'm very interested to see where development for this goes. (I wouldn't even mind contributing myself, although I barely know much C.)

RLH: Talk to the author to see if you can help. Indeed I think this is the best toolkit away from Tk.

WJG 2009-12-08: Thanks for taking the time to explore Gnocl and, of course, for the positive feedback. Let me deal with some of the point you have raised.

1) Documentation. Gnocl needs a lot of work to bring the documentation up to date both in terms of content and appearance.

2) Drag-N-Drop tree widget. I'll have to take a look at this. The tree widget has only received some cosmetic ehancements which, from a C-side alone are 'a' rotter to implement as these are **not** standard options but accessed through widget styles obtained from the user theme settings.

3) Bug in toggling a boolean column. If you have a sample script that you're working on that displays this problem, perhaps you could post it to the wiki and then I can resolve the issue by either a script workaround or an enhancement to the package core-code.

3) Percent strings aren't that diffiuclt really, just rememenr "%#" for stock icon and "%/" for disk-based icons.

4) Image processing. Yes, Gtk+ has its own library of image handling tools. I'm not certain what Tk has to offer these days but its worth looking at. This, would probably be a new package in itself.

Extra hands are always welcome. The quickest way to get up to speed, now that most of code is in place, is to find a Gtk+ entension, a simple one,and then I can point the way through creating a tcl/gnocl binding for it. My advise is to only select libraries written in C, not C++.

RLH: The email address for you at the top of this page bounces. Is it correct?

WJG: Gosh, that's a dead one, sorry. I've updated the entry to something that works. Please try again.

WJG: On re-examining the source code I noticed that I've already added support for Drag-and-Drop within a Gtk+ treeview -how forgetful of me!. But, confusingly, this is not known as known as Drag-and-Drop (which is between widgets) but 'reordering'. To enable the feature use -reorderable 1, to switch it one or 0 to it off (default). Here's the updated wiki page [L12 ].

Josee: Oh cool, there is DnD! Didn't realise there's some actual Gnocl documentation on this wiki, though, (also cool and handy). Another quick question; is it possible (IOW does GTK even allow you) to combine a checkbox and label in a single column, or to automatically wrap column values to multiple lines? (I see newlines work, but that wouldn't be ideal for a program I'm developing).

Here's a simple script that triggers the boolean triggering bug on my machine (both keyword and numeric boolean values fail):

 package require Gnocl 0.9.94
 ::gnocl::window -child [::gnocl::tree -types [list boolean string] -children [list [list true true] [list 0 false]]] -defaultWidth 100 -defaultHeight 100

This is with GTK+ 2.16.6 (and Tcl 8.5.7) running on a Gentoo machine.

Of course, percent strings aren't hard to get the hang of (except annoyance when some widgets take markup strings, and others don't). What I mean to say is that they feel inelegent, and not very 'Tcl-ish' to me. Like, a small good example is how instead of coding -text "%_E_xample" in Tk, you'd write -text "Example" -underline 1. -stock Quit would also look nicer (and make more sense) than -text %#Quit.

As for the image stuff, what Tk has isn't very powerful; I just like how it allows me to manipulate and use images as objects and thought that kind of functionality would be handy in Gnocl, too. Thinking back, the idea of porting Tk's own image code seems kinda stupid, I'd imagine that'd be pretty hard-wired into Tk. A GTK-based equivalent would be neat, though. (Hm~, maybe a project idea for me?)

WJG 2009-12-14: Using the code snippet that you posted I too get the same errors. Interestingly the code runs perfectly well if the parent widget type is change to gnocl::list rather than being a gnocl::tree. Thanks for the bug report and I'll take a look at it. There is no apparent way of embedding widgets directly into cells.

In terms of developing a gnoclPixmap (using terminology inhereted from the Gdk libraries) you would need to decided just what has to be done as many of the operations that you may need are already supported. There are the gnoc::image widget and gnocl::drawingArea widget which allow direct manipulation of the widget graphic. Indeed, any gnocl widget that is of the GtkDrawable type can be directly manipulated in some way or another. Its a matter of deciding what to do. If you want clever image manipulation, then ImageMagick may be the answer for which there is already a Tcl binding.

Creating a -stock option for buttons, menus etc. is a possibility. I'll look into that too.

In terms of contributing to the project, take a first loook at the drawingArea.c file. As can be seen, its pretty basic as it stands but shows how gdk library calls are made to draw to pixels. The widget itself, of course, does not need to be 'shown' at any time, and its quite feasible to create a gnocl command to specifically copy the drawable content of one widget to another.

Finally, I spent most of the weekend putting together a 'boiler plate' package which can be used to build new gnocl extensions. This provides the necessary base code to handle new widget options, commands, the creation of developer docs, formatting, and distributions. This has some way to go at the moment and will be available in the next release of gnocl which I hope to make available very early in the new year.

Lectus 2011-04-26 18:37:27:

Hey! I have a few questions regarding Gnocl use on Windows:

For example, if I write an app in Gnocl what DLLs do I need to ship on Windows to make it work? Do my clients need the full GTK+ runtime environment? Can I just copy the required DLLs and create an installer? Is it possible to create an starpack with these DLLs included? Where can I download the latest Windows release?

Thanks

WJG 2011-04-27: Hi. There are now dlls available for Gnocl 0.9.95 running on windows which are available from the Sourceforce repositories. These are prepared by other members of the Gnocl users community and, if you post a your questions to the Google gnocl newgroup [L13 ] then I'm sure that they'd be keen and eager to answer and windows related issues.

APN: Where are the support DLL's ? Sorry, but just could not find them on SF. As I had posted earlier, only libglade is included there in http://sourceforge.net/projects/gnocl/files/Gnocl-Windows/0.9.95/ which what the Windows binary link on www.gnocl.org points to. Other support DLL's are still missing as listed below. Not sure if that is what was intended. Details posted on the newsgroup as you suggested.

WJG 2011-04-27: The other packages are, for the most part, bindings to Gnome Desktop resources. If there are other items that you need, ie. canvas. Post a request to the newsgroup, I expect that some unannounced work has already been done.

gnocl

Attributes

See Also

Development

Download

Build/Install