Lively TclTk

Lively-Kernel meets Tcl/Tk?

My latest install of Tcl/Tk 8.5 from Activestate left a link in Windows to Tk demos.  One is named "A Celebration of Rube Goldberg" and should impress Self-as-JavaScript  fans of Sun LivelyKernel or Avocado.

Regardless of the grief in getting Tcl with OO out of 8.6 beta, the demos are a great presentation.  I continue to use Html Viewer 3 (Tcl/Tk's hv3 browser) as a light-weight browser when my laptop's sole-core is over-loaded with a few of today's greedy app's wildly swapping in and out (and no, the worst offender happens not to be from Microsoft.)

Btw, Squeak Smalltalk is working to get their base image down to about 10Mb.  Remember when shared DLL's were to keep us all happy below 640K ?  Gates' Hades, Hades' Gates.

PS: I have added a label/tag for Pharo Smalltalk - now the preferred ST for Seaside?

PPS: here is the Avocado blog: there.

---

Python + Tkinter and Python + Gtk

Remembering that Python was intended as a scripting language, compare these two HelloWorld from Python.

First, Tkinter for Tk as in Tcl/Tk

from Tkinter import *
root = Tk()

class HelloWorld:

def __init__(self):
  widget = Button(root, text = 'Hello World', command = self.quit)
  widget.pack()

def quit(self):

  print "Hello World"

  import sys

  sys.exit()

HelloWorld()
root.mainloop()

Now to compare the same minimal HelloWorld with Gtk.  First, install Gtk+  ( and on Windows XP  that means get all of the dependencies - the DLL's - on the path.)

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):
   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()

Whatever the merits of Gtk+ as a cross-platform C GUI framework for general purpose languages, something looks to have gone wrong with the Python library PyGtk.

Even with Tk itself, something comparable occurs when using Tk from Haskell versus using Tk from OCaml.  Probably  expect was the Tcl "killer app" but Tk is what most developers know of Tcl today.  Tk was also an early mainstay of Ruby.  Here is the HelloWorld demo using Gtk+ from the Ruby-Gnome team:

# Copyright (c) 2002,2003 Ruby-GNOME2 Project Team
require 'gtk2'

button = Gtk::Button.new("Hello World")
button.signal_connect("clicked") {
    puts "Hello World"
}

window = Gtk::Window.new
window.signal_connect("delete_event") {
    puts "delete event occurred"
#true
   false
}

window.signal_connect("destroy") {
   puts "destroy event occurred"
   Gtk.main_quit
}

window.border_width = 10
window.add(button)
window.show_all

Gtk.main

Now this is a little better, but compared to Ruby + Tk we are at almost double the lines of code.

To see a really elegant use of Tk, see the QTk framework for Oz, the language.  I'm fiddling with a QCurl variant for Oz just now.  I added some notes on OCaml and labltk over at wikia.com

Tcl browser plugin v3 (from ActiveState)

There are some discrepancies in info about embedding Tcl/Tk since the change to plugin v3.

I tested against up-to-date Chrome, Opera, Safari, IE8, FireFox 3.5 and Amaya

My result is that given some script XYZ.tcl ONLY the following worked across all:

<OBJECT
ID="PluginHostCtrl"
CLASSID="CLSID:14E78123-A693-4F27-B6EE-DDDE18F93D3A"
WIDTH="400"
HEIGHT="220"
>
<PARAM name="type" value="application/x-tcl"/>
<PARAM name="pluginspage" value="http://www.tcl.tk/software/plugin/"/>
<PARAM name="src" value="XYZ.tcl"/>
</OBJECT>

Getting the plugin recognized by each browser was slightly problematic: IE 8 appeared to just ignore the XPI.

XOTclIDE: the IDE that is almost Smalltalk

I copied XOTclIDE82.kit into my \kits directory for ActiveState Tcl/Tk for Windows.
A double click on the kit ( I already had Tclkit in the PATH for Tcl\bin ) and I was politely asked whether to launch Simple or with Version Control. Simple was fine for now.

The result was a Transcript, a ClassBrowser and I was one click from a WorkSpace.

If you have ever used Smalltalk, this will sound very familiar.

And if you have never used Tcl with the GUI Tk you deserve to take an hour or two and see what simple GUI-driven control of admin tasks can be like.

XOTcl is extended MIT OTcl. There had been a few GUI extensions to Tcl rather as there have been for Python. But these extensions are principled: they do not simply provide a wrapper to a GUI library. The Mozart-Oz system is very much built on principle and exploits Tcl/Tk in its QTk, but lacks an IDE (SICStus Prolog also has a Tcl interface.). Tcl upvar and uplevel are not a replacement for the Mozart implementation of Oz, so my question becomes: does this rich environment impede or foster useful Tcl scripting?

An IDE as rich as that found with most Smalltalk implementations tends to be only as useful as its GUI layout tools and/or GUI specification framework. If it is awkward to tie event handlers and callbacks to widgets and worse to edit or maintain them, then little is gained by having object inspectors and dynamic workspaces. Tcl/Tk itself is marvelously simple (Jython comes to mind by way of comparison - or Rebol or Curl RTE's.)

The XOTcl documentation presents a very flexible, dynamic object framework, but the XOTcl components are file-based Tcl packages which must be registered with Tcl. Tcl is about component integration, but it's own integration of packages is a weak point, which is not to say that packaging and load dependencies cannot also be a headache in Smalltalk.

If I find the learning curve not too steep ( if Curl, the MIT web content language, has a gentle curve then Rebol is like learning to surf: anyone can paddle out ... ) then I will add a header page at eclectic-pencil and see if I can't put up a few useful markers across the terrain.

If you have a favorite language with no non-commercial IDE and are not in love with Eclipse, XOTclIDE does show what a mature IDE can offer a developer in a dynamic language. The only development environment to interest me as much as this was the outline-browser of Strongtalk.

PS Eclipse, of course, evolved from IBM VisualAge Smalltalk ...

QTk scripting in Oz/Mozart

The relative neglect of oz/mozart compared to say, Scala, has an explanation.

Part of it must lie in the needless snags along the learning curve. Steep is fine; jagged bits, less so.

There is no learning Oz/Mozart without embracing their emacs mode. And tolerating their tutorial.

Do not begin with applications. An application will require at least one 'functor'.

Ignore the bits that say you are compiling. You are not. No tutorial code will compile. Just do as you are told (follow the instructions) and 'feed' in a line. Or 'feed' in a region. Or 'feed' in a buffer.

What they mean is pass a line, a selection or the file through the interpreter only.

Think of it as scripting in Oz/Mozart. Now you can open a window with widgets using an few lines of Qtk.

No language which interfaces to Tk should be hampered by such a tutorial or such documentation; the usual answer is to buy the somewhat pricey MIT book by Peter van Roy.

Try to understand that the people who are assessing the need to revise the on-line documentation already know oz/Mozart inside-out and cannot 'see' the bits that say 'compile' when nothing compiled at all. They think you know what they mean by 'pickle' and that you get the 'functor' jibe at Prolog. A module is a module. Sometimes in some language a class is just a module. And writing a fine tutorial is an art. If you can get the video intro to Revolution/Transcript/MetaCard to run under Windows using the required QT codec, you may actually see what I mean.

But hey, you could not script the Oz/Qtk way in C. The fact that it looks easier in Jython may be that you know java and python. But it is easier in Tcl/Tk wish. So the point must be what can be achieved in oz/Mozart and that may be as much as can be achieved with Scala and then some.

Watch this blog for a link to a tutorial and a concordance/commentary to their friendly-looking documentation. And just accept that all you need to know is in the oz/Mozart maillist.

Somewhere in oz, climbing a cliff on the way to the corner store.

Note: do try the QTk Prototyper.  The tutorial leaves out one essential: declare the Prototyper, as in

 declare Prototyper

[Prototyper]={Module.link ["x-oz://system/wp/Prototyper.ozf"]}

{Prototyper.run}