Hi Daniel,

testing *wish* like that should work. However, why or for which purpose do you want to use ensure-ltk? I usually split my code in two parts: functions that create the UI which assume that Wish is running, and start functions like "main" which only start wish and then call the UI creation functions. So if I need a different entry point to my program I just write a different startup function. Besides, you can have any number of wish processes running at the same time. So e.g. for a debugging tool, you can create a separate Wish with with-ltk.

On Sun, Jan 3, 2010 at 4:42 AM, Daniel Herring dherring@tentpost.com wrote:

On Fri, 1 Jan 2010, Daniel Herring wrote:

...

What's the proper idiom when writing a function that might start wish or might be called inside another with-ltk?

For example, (defun some-window ()   (ensure-ltk ()     ...))

Where some-window could be called from a REPL or from a tk callback? Is there already a way to do this in ltk, or should I define a macro something like the following seemingly broken code?

(defmacro ensure-ltk ((&rest options) &body body)   (let ((fname (gensym)))     `(labels ((,fname () ,@body))        (if (wish-stream *wish*)            (,fname)            (with-ltk ,options (,fname))))))

Here's my current macro.  Could it be added to ltk.lisp?

(defmacro ensure-ltk ((&rest options &key (debug 2)                              &allow-other-keys)                       &body body)   "Wrap BODY in with-ltk unless a connection already exists."   (declare (ignore debug))   (let ((fname (gensym)))     `(flet ((,fname () ,@body))        (if (wish-stream *wish*)            (,fname)            (with-ltk ,options (,fname))))))

It turns out that both ensure-ltk macros work.  However care must be exercised; my first use triggered Tk bug #219967.  My distilled Ltk sample appears below.

;;; CAUTION ;; http://sourceforge.net/tracker/index.php?func=detail&aid=219967&grou... ;; This can freeze a graphical window manager. ;; To run on linux and recover: ;; - log into a text console (e.g. Ctrl-Alt-F2) ;; - switch graphical (Ctrl-F7) and run the bomb ;; - switch back to text and `killall wish` ;; - watch `top` until things calm down (defun bomb ()   (with-ltk ()     (pack (make-instance 'treeview))     ;; commenting out the sleep might save your window manager     (sleep 1) ; just to let the treeview appear     (grid (make-instance 'label :master nil) 0 0)))

Even without this Tk bug, its probably a good idea to always pass a proper :master to other functions which create widgets...

Yes, you must not mix pack and grid. I think every Tk programmer does that exactly one time :). In practice that has not been an issue with me. Whenever the UI becomes so complex that I want to split it in several functions - that is for any nontrivial LTk program - I actually split it in several "widgets".

So I do something like: (untested code, might not compile)

(defclass my-widget (frame) ...)

(defmethod initialize-instance :after ((w my-widget) &key) ;; .. now create the whole part of the UI that my-widget covers ;; all such created UI elements have :master w )

and then just use it by instantiating it. In the current LTk branch, there is also the nice defwidget macro, which makes this even nicer...

So essentially, the layout of a container is only done within one function, that reduces the chance of mixing up pack and grid. So a main function could look like: (with-ltk () (let ((w1 (make-instance 'my-widget)) (w2 (make-instance 'another-widget)) (pack w1) (pack w2)))

Peter