WJG For the past ten years or so I've been a mixed Windows/Linux user. Jolted along by a presentation that I made at an OpenAdvantage [L1 ] seminar earlier this year, I decided to put Windows on the back-burner and spend my time running Linux. Putting OS considerations aside, I needed to think about re-working my custom apps running under Tcl/Tk on Windows. Windows and MacOS discourage us from fiddling about with the appearance of things, whereas Linux, well... Now, that I've settled into things and got Gnome looking the way I like it, I want my tcl apps to fall in line. Not an easy thing to do in Tk - under Linux as everything still looks like Motif. So the dilemma is GTk or Tk? Well -Gtk. But what about Tcl? If we refer to the Gtk+ developer site [L2 ] we do find bindings listed and, as seems par for everything else, Python is the preferred choice. But why should it be? The following piece of Python code puts a single button in the middle of a toplevel window. The link for PyGtk [L3 ].
#!/usr/bin/env python
# example helloworld.py
import pygtk
pygtk.require('2.0')
import gtk
class HelloWorld:
def hello(self, widget, data=None):
print "Hello World"
def delete_event(self, widget, event, data=None):
print "delete event occurred"
return False
def destroy(self, widget, data=None):
print "destroy signal occurred"
gtk.main_quit()
def __init__(self):
self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
self.window.connect("delete_event", self.delete_event)
self.window.connect("destroy", self.destroy)
self.window.set_border_width(10)
self.button = gtk.Button("Hello World")
self.button.connect("clicked", self.hello, None)
self.button.connect_object("clicked", gtk.Widget.destroy, self.window)
self.window.add(self.button)
self.button.show()
self.window.show()
def main(self):
gtk.main()
if __name__ == "__main__":
hello = HelloWorld()
hello.main()Here's the equivalent in Gnocl, effectively one line of code. In PyGtk, the coder still needs to manually made connections between events and handlers which Gnocl does automatically. Isn't the purpose of scripting to reduce code-recreation the minimum, not merely to make recreation easier?
#!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" package require Gnocl gnocl::window -child [gnocl::button -text "Hello World" -onButtonPress exit] -onDelete exit
Which one would you choose? Find the Gtk C code here [L4 ].
LV Another consideration - check out Tile, which, as Ttk, comes with Tk starting in Tcl/Tk 8.5. Perhaps it would be worthwhile seeing how to improve the Ttk-Gtk cooperation?
LBarret Tile is very promising but the argument for gnocl is pretty weak : mainly better syntatic sugar. Furthemore, this is vanilla GTk; many people use autoconnect mechanisms that make the difference less important. Comparing the other example seen on the gnocl mainpage may show that the difference is not that important.
WJG Thanks for the comments -but. I'm not dealing with issues regarding the Tk-Tile debate, but how to get the best out of easy scripting with Gtk. If I want to run my apps on Windows, I'd leave them the way they are, 'cause they look pretty good and the rendering of widgets is just fine to me. If I'm running Linux, then I want it to adhere to my desktop theme, whatever that might be. Tk doesn't do that, and neither, I suspect, will Tile. [ LV Actually, one of the major ideas behind Tile, in my understanding, is that it would in fact recognize theme changes, at least on MacOS X and Windows. I don't know what it does on Linux right now, but the framework should be in place to do it. However, you are not interested, so no need to go farther on that point.] Let's keep comments salient to the content of the page which is the ease of building Gtk based UI applications in a tcl script. I would have thought this a cause for celebration in itself. Check the code by using it and not just look the screen shots, try the real alternatives: building Gtk apps in C!
WJG Fellow Wiki users, have the courtesy not to swap code which has been placed on this page for a purpose. Someone changed the Python code to a clip which was not correct. I have restored it back to what it should be.
Nickname WJG, have the courtesy not to massively over-inflate code to prove a point. The Python code you posted contains additional behavior not found in the Gnocl code, and in addition is needlessly verbose.
WJG(31/10/07) Nickname, please read the posting. This isn't my code but that from the PyGtk website. Besides, apart from the code that you posted didn't work (not on my machine anyway) it's still more verbose than the gnocl code! So, reciprocate the courtesy. Leave postings be; if you wish to make a point with reasoned debate then add it, don't censure others! If I'm wrong, or there's a better view, fine I'll be the first to listen and fix any errors.
Here's a useful link on Wikiquette [L5 ]
For those who really need it, here's Nickame's posting...
peterc 2008-08-14: It's worth looking at the Tile-GTK theme [L6 ] by Georgios Petasis. Even the 0.1 screenshot at http://www.ellogon.org/~petasis/tcl/tile-gtk-dev-0.1.png looks pretty good. I'd really suggest sticking with Tile if at all possible.
DKF: One thing to note is that though Gtk (and Qt) apps are theoretically portable between X11, Windows and OSX, they really don't look good on non-X11. (For a number of years I was forced to use a Qt-based app for some work-critical things, and it clunked horribly on Win. With OSX, the difference is even starker; apps usually have to be rewritten to look and work right there because the GUI isn't CUA-derived.) By contrast, it's much easier to make a Tk app (especially with Ttk) look wholly native on Win and OSX.
WJG (16/08/04) DKF, I agree with you. Gtk doesn't have the native look on Windows but, Peterc misses the point, Gnocl isn't about beautifying Tk. Gnocl is about making Gtk/Gnome applications, not Tk applications. I've not tried tile-gtk, perhaps I will later. For Gnome aficionados, however, Gtk compliance means use of the Gtk widgets followed by the Gnome widget set. Personally I got into Tcl/Tk because I wanted to use the easiest way of writing X compliant Linux programs which in the late 1990s was Tk. I love Tk, but I think that its had its day. Gtk/Gnome appears to be more popular than Qt/KDE and so I want my Tcl apps to work directly with Gtk. This basically means Gnocl. I might be putting the cat amongst the pigeons now, but, I would even profess the view that the Gtk widget set is better than the Tk offering. As I've said, I've not tried tile-Gtk but do feel that if it looks like Gtk, then I would expect it to behave like Gtk. Frankly, I don't expect many converts to Gnocl, even when the next release is out (I'm currently putting the finishing touches to rel. 0.9.93) but then I don't encounter many converts to Tcl/Tk these days either. Perhaps one reason why Python and Ruby are gathering more interest than Tcl in the Linux world is due to the lack of a specific graphics package, something which gave Tcl/Tk the edge a generation ago. Ironically, Tk may work directly with X, but it has an unnatural feel to Linux users running Gnome.
#!/usr/bin/env python
# example helloworld.py
import gtk
window = gtk.Window ()
window.connect ('destroy', gtk.main_quit)
button = gtk.Button ('Hello World')
button.connect ('clicked', gtk.main_quit)
window.add (button)
window.show_all ()
gtk.main ()default WJG, the example may still be more verbose than the Gnocl example, but very less so. The original comparison is still quite unfair. FYI, I corrected (and shortened) the Python example above. Anyway, GUI design with code still sucks -- you need an interactive way to design UIs and Gnocl doesn't provide that. For scripting, you usually need only quite limited capabilities and there are more suitable toolkits for that.
Besides, I have problems with Gnocl seemingly doing certain things "automagically", like entering the GTK main loop. What if you want to nest the main loop?
WJG (13/08/08) I'm not so certain that 'GUI design with code still sucks'. My take on the matter is that interactive GUI design produces more code than necessary. At best it's a means of reducing the programmers exposure to verbose code or, more likely, is used to workaround a lack of solid GUI coding skill. Good GUI design comes from clearly thinking through the various controls necessary for an application and perhaps even sketching the intended layout. Working with interactive tools often leads to just fiddling around with widgets or trying to make something visually complex. But who am I to comment? Conversations with other developers leads me to form the opinion that too many programmers relish in the complexity of their code, even if the code is terse even for themselves to explain. To compare the Gnocl offering with the pyGTk script, is I now admit, an injustice -the Gnocl commands offer so much more! The forthcoming release of Gnocl, for instance, has a few nice enhancements. Here's one line of code for example.
set txt [ gnocl::text \
-baseColor xffffcd \
-baseFont { Sans 14 } \
-onButtonPress { bpProc %w %b %s } \
-onButtonRelease { brProc %w %b %s } \
-onKeyPress { kpProc %w %k %s } \
-onKeyRelease { krProc %w %k %s } ]Apart from automatic support for scrolling windows, event and signal management, the latest version supports tag events and extended default settings support and the familiar Tk style substitution strings. How many lines of PyGtk code do we need for this? Or, if you wish, how many lines of Glade XML code?. Which is easier to understand as a scripter? And, of course, the Gnocl code is totally reusable! A PyGtk app, is a PyGtk app. Gnocl is a scripting extension to Tcl just like Tk.
To be fair, the Gnocl C source code ought to be compared with the PyGtk script as its is at this level that the same Gtk library functions are called.
Gnocl is intended to simplify the process of developing Gtk applications. I'm sure that PyGtk does make the development of Gtk applications easier than pure Gtk C code, but then, its largely acting as some sort of glue; one still needs to know the innards of the Gtk Libraries to make sense of PyGtk. Gnocl, on the other hand, enables new or established Gtk developers to move straight into creating their new Gtk applications.
Finally, the mainloop. This can be called explicitly if needed with the gnocl::mainLoop command. But then, why would it need to be nested elsewhere?
RLH I would choose Gnocl because it uses Tcl. =)
WJG The right answer! I wish more people would give Gnocl a go. Tcl has much to offer the programmer but Python seems to be leading the popularity polls. Learning a scripting language takes time and the more diverse bindings that are available to it the more likely it is to attract interest from potential users. At the 2008 LugRadio Live conference in the UK I met quite a large number of young programmers (ie. under 30 and young enough to be my kids) who were now setting out on their careers. Most were involved in the use or development of web-based applications and all the talk was on Python and Python bindings. I'm not saying that Python (or Pythong as it was called by most that weekend) is a lesser language no, what I am saying is that users of Tcl should be more proactive in supporting diversity. Rather than coming up with another megawidget set based around the same old Tk offerings, spend some time writing something new. The package I work on developing and evangelise is Gnocl, the Tcl/Gtk bindings, but has anyone worked to put a Tcl/Qt binding together yet? The choice for choosing Python cannot be that its 'easier' or a less complex option. In fact, I met a number of coders who were using PyGtk bindings for their applications who appeared produced a lot of code to generate their GUIs. Gnocl, by comparison would have required only a few lines. By adopting the Tcl command/option route means that the serious job of 'wiring up' the signals and their event handlers has all been done, its waiting there to be used -there is no need to resort to Tcl scripting the C equivalent because the bindings are merely a wrap around the C library routines. And, of course, there's the mandatory eye-candy and UI conformity. Because this is not the concern of the Gnocl scripter, but the Gtk package, it's always as good as it gets.
RLH I am playing around with it in a VM using Xubuntu. Gnocl is pretty nice. I may at some point get involved with the project as well.