[ltk-user] Just one frame?

[Peter Herth]

On 4/26/07, Johnny Zackrisson <jz at student.chalmers.se> wrote:
>
> Here is a simple example:
>
> ;-- snip
> (start-wish)
>
> (with-ltk (:stream (wish-stream *wish*))
>   (let* ((a (make-instance 'frame :width 60 :height 60 :border 2))
>         (b (make-instance 'frame :width 100 :height 230))
>         (c (make-instance 'button :text "Press blah.."))
>         (d (make-instance 'label :master a :text "foo"))
>         (e (make-instance 'label :master b :text "bar")))
>     (pack a)
>     (pack b)
>     (pack c)
>     (pack d)
>     (pack e)))
>
> (with-ltk (:stream (wish-stream *wish*))
>   (let ((f (make-instance 'label :text "zot")))
>     (pack f)))
> ; -- snip
>
> the second call to the "with-ltk" macro wont work. the point
> here is i want to be able to continue hacking around at the repl,
> doing other things, and then later on perhaps add another entity
> to the gui.

Things become much clearer now :). with-ltk is thought for applications
which should run as one application, but not for tinkering in the REPL,
so just do the start-wish and none of the with-ltk's. Then you can do
exactly as you want. If you want events processed, just call mainloop
from the repl and break and exit it (without quitting wish) to return to
the REPL. Alternatively, keep calling (process-events) which directly
returns after processing all pending events.

>
> what if i wanted to add the "f" label to the "b" frame; am i forced
> to use globally declared variables for the initial frame, or is
> there other ways to deal with such a situation? (observe that the
> "f" label call is done /after/ the first packing).

Well that has nothing to do with LTk, you need to "see" the variables
you want to use... so you need to be in the scope of the variable, for
the REPL this means that they need to be global.

>
> furthermore, is it also possible to attach handlers to objects
> (say buttons or a keyboard event) in such a way that it
> automatically dispatches a separate thread and excecute the handler
> assigned to that thread, without interrupting the rest of
> the lisp system (ie, the repl will be interactive, as well as other
> concurrently running threads).

Well, if your lisp has threads, spawn mainloop in a thread. Or use
serve-event. But with threads a word of caution: LTk hasn't been
stress-tested with respect to multi-threading yet (proper threading
support is still in the planning phase), so use it at you own risk :)


>
> another example would be: how would you design a lisp-repl in a tk
> frame, sending the lisp code to the lisp-environment for execution
> and then return the answer of course, or even add tk objects from
> within that tk-repl?
>
That is easy to do with LTk as it is: just get the code from the Tk
entry widget,
read and eval it, and output the result to the Tk GUI. However, it might be a
good idea to run the GUI in a different process than the lisp code to execute,
as when the lisp process locks up, or enters the debugger, the GUI still runs
happily...

Peter