GUI event loops 
Author Message
 GUI event loops

I'm doing some work on using the GTK+ GUI library in lisp. Regarding
this, does anyone have suggestions as to what is the natural way to
express event loops in lisp? Or rather, the bindings between events
and lisp code.

Currently, I have events bound to symbols, such that whenever an event
occurs, that symbol's function-cell is called. But I'm not quite
satisfied with this approach, as it is very static and the resulting
code becomes numerous DEFUNs without the typical funtional flow.

It strikes me that these kinds of event bindings are perhaps not too
different from lexical variable bindings, so maybe I should look at
something like EVENT-LET.

Anyways, I'd like to hear if people with more experience with LISP
GUIs have some thoughts to share.

If you are interested in lisp/GTK/Glade, you can find my code here:
<URL:http//www.cs.uit.no/~frodef/sw/cl-glade/>. It currently only
supports Allegro CL 5, as I can't get CMUCL's or CLISP's FFIs to work.

Thanks,
--
Frode Vatvedt Fjeld



Thu, 25 Apr 2002 03:00:00 GMT  
 GUI event loops

Frode Vatvedt Fjeld asks:

  [W]hat is the natural way to express event loops in lisp? Or rather, the
  bindings between events and lisp code.  Currently, I have events bound to
  symbols, such that whenever an event occurs, that symbol's function-cell
  is called. But I'm not quite satisfied with this approach, as it is very
  static and the resulting code becomes numerous DEFUNs without the typical
  funtional flow.

If I were designing this, I would probably define event structures
(DEFSTRUCT) to store useful information about each event.  That way, you can
associate one or more actions (function calls) with an event -- say, having
both a begin-event and an end-event call for drags.  You can also use other
slots for items you'd also like to associate with events, perhaps including
equivalencies (keyboard, mouse, menu, etc.).   If you wanted non-trivial
inheritance among events, you might also consider using CLOS objects as your
events.  If you did that, you could also design generic functions with
methods for various kinds of events, and do event dispatch by calling the
generic function on the event object.

Try looking at the CLIM specs.  You probably don't want to try to implement
all of CLIM on your own, but some of the design ideas are worth considering
for your system.

Good luck.  It would be nice to have a well designed GTK+ GUI library in
for lisp...

Larry

--
Lawrence Hunter, Ph.D.        Chief, Molecular Statistics and Bioinformatics

Federal Building, Room 3C06                         phone: +1 (301) 402-0389
7550 Wisconsin Ave.                                   fax: +1 (301) 480-0223
Bethesda, MD 20892  USA



Sat, 27 Apr 2002 03:00:00 GMT  
 GUI event loops

In Garnet, event handling is encapsulated in objects called
`interactors'.  These interactors are created independently of
graphics.

Here's an example:

  (create-instance nil inter:button-interactor
                   (:window *w*)
                   (:start-event :middledown)
                   (:start-where T)
                   (:continuous nil)
                   (:final-function #'zoom-in))

This adds an interactor for the middle button to the window *w*.  The
function in the :final-function slot, `zoom-in', will get called when
the middle button is clicked.

Here's another, a `two-point' interactor:

  (create-instance nil inter:two-point-interactor
                   (:window *w*)
                   (:start-event :leftdown)
                   (:start-action #'(lambda (i p)
                                      (declare (ignore i p))
                                      (s-value *outline-rectangle* :visible nil)))
                   (:start-where T)
                   (:final-function #'set-outline-rectangle)
                   (:feedback-obj *moving-rectangle*)
                   (:line-p nil)
                   (:Min-height 0)
                   (:Min-width 0))

The idea here is that you click on the left button and drag to select
an area.  The area is indicated by a feedback rectangle and once the
area is selected, the function in the final-function slot is called.

There are eight different kinds of interactors in Garnet, covering
most kinds of user input.

I like this better than programming event loops myself.

--

The real point is how much easier it was to conceive of and design the
Lisp version.  I hadn't even realized the problem was hard until
people started to recode it in C....         --Lawrence Hunter, Ph.D.



Sun, 28 Apr 2002 03:00:00 GMT  
 GUI event loops

Quote:
> I'm doing some work on using the GTK+ GUI library in lisp. Regarding
> this, does anyone have suggestions as to what is the natural way to
> express event loops in lisp? Or rather, the bindings between events
> and lisp code.

MCL has a simple model.

All things on the screen are objects (windows, dialog-items, ...).
The MacOS event system calls the MCL event system. So
MCL takes the window where an event takes place (key press, mouse
click, ...) and determines the kind of event. It then calls
a generic function for that event on the particular item of
the window (say, a view-click-event handler for a button).
This function then determines what kind of event for the
item it is (say, a dialog-item-action) and calls another
generic function on the object.
A default handler might look for a function that is stored
in a certain slot of the (say, a dialog-item-action-function) object.

MacOS event -> MCL event -> View event -> handler

So you have certain levels of event handling where you
can change things (the translation of OS events into
MCL events, ..., override handlers, store specific handlers
per object).

Just create a button with an on-the-fly behaviour:

(make-instance 'window
  :view-subviews (list
                  (make-instance 'button-dialog-item
                    :dialog-item-action (lambda (button)
                                          (inspect button)))))

Or: create a special button object you can reuse:

(defclass inspect-mixin () ())

(defmethod dialog-item-action :after ((item inspect-mixin))
  (inspect item))

(defclass my-button (inspect-mixin button-dialog-item) ())

(make-instance 'window
  :view-subviews (list (make-instance 'my-button)))

Or: Modify the event-handler for views. The primary method for
dialog-items calls DIALOG-ITEM-ACTION.

(defmethod view-click-event-handler :after ((view my-button) where)
  (inspect where))

The event-handler of MCL is run as a kind of interrupt in a thread.
That means that other threads can run and the MCL event handler
is independent of the state of, say, running listeners. So you can
move, resize, etc. windows at any time (minus WITHOUT-INTERRUPTS,
and the general problem of non-preemtive threads on the Mac)
- even if they have a running thread. If the special event routine
needs to do a longer and more complicated task, one just would enqueue
a function and the first non-active listener would run that - or one could
create a new listener executing this task - or one could
start a thread that runs in the background and executes the
function.

The MCL model was first implemented as a very flexible way
of writing UIs using a prototype-based object system (Object Lisp).
Later the system has been rewritten completely for CLOS, trying
to preserve some of the nice features of the old system.

Rainer Joswig, ISION Internet AG, Harburger Schlossstra?e 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226



Mon, 29 Apr 2002 03:00:00 GMT  
 GUI event loops

Quote:

> I'm doing some work on using the GTK+ GUI library in lisp. Regarding

I'd suggest taking a look at CLM to see upto what extent this can be
generalized to support both GTK+ and Motif, to start turning it into a
toolkit abstraction layer over which higher-level frameworks can sit.

Until I get them hosted, I can send you a prerelease of CLM 2.4 and GINA
2.4 if you want.

BTW, there's a copyright notice in your files, and a GPL COPYING file in
the distribution, but there's no explicit notice explaining what's the
role of the latter.
If you do intend to go the FSF way, the LGPL would be better.

Regards,

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

www.csem.ch      www.vrai.com     ligwww.epfl.ch/matomira.html



Fri, 03 May 2002 03:00:00 GMT  
 GUI event loops


Quote:

> > I'm doing some work on using the GTK+ GUI library in lisp. Regarding

> I'd suggest taking a look at CLM to see upto what extent this can be
> generalized to support both GTK+ and Motif, to start turning it into a
> toolkit abstraction layer over which higher-level frameworks can
> sit.

This is a worthy goal.  However, note that the CMUCL/Motif interface
(patterned after CLM) is slightly better (it does cons less).

Quote:
> Until I get them hosted, I can send you a prerelease of CLM 2.4 and GINA
> 2.4 if you want.

> BTW, there's a copyright notice in your files, and a GPL COPYING file in
> the distribution, but there's no explicit notice explaining what's the
> role of the latter.
> If you do intend to go the FSF way, the LGPL would be better.

I strongly agree with this.   The GPL is more restrictive.  CL
packages do not need restrictions at this moment.

Cheers

Marco

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa



Fri, 03 May 2002 03:00:00 GMT  
 GUI event loops

Quote:

> This is a worthy goal.  However, note that the CMUCL/Motif interface
> (patterned after CLM) is slightly better (it does cons less).

I guess I'll have to take a look sometime. Note however that CLM 2.4 includes

a lot of performance improvements by `monty', specially w.r.t. CMUCL
[or is anybody getting serious about the CMUCL GC first? >:-I ]

--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))

Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

www.csem.ch      www.vrai.com     ligwww.epfl.ch/matomira.html



Sat, 04 May 2002 03:00:00 GMT  
 GUI event loops

Quote:

> > This is a worthy goal.  However, note that the CMUCL/Motif interface
> > (patterned after CLM) is slightly better (it does cons less).

> I guess I'll have to take a look sometime. Note however that CLM 2.4 includes

> a lot of performance improvements by `monty', specially w.r.t. CMUCL
> [or is anybody getting serious about the CMUCL GC first? >:-I ]

First of all, CMUCL/Motif is more consistent when it comes to naming
things.  No shortcuts w.r.t. Motif naming have been made, only
"trivial" transformations.  Secondly, some functions have had their
arguments switched, therefore, in CMUCL they now are &rest functions,
instead of functions where you need to cons up a structure/list to be
passed back and forth.

Anyway, CMUCL/Motif works pretty well with CMUCL, I guess it'd be
rather easy to port it to other CLs as well.

Cheers

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa



Sat, 04 May 2002 03:00:00 GMT  
 GUI event loops

Quote:

> First of all, CMUCL/Motif is more consistent when it comes to naming
> things.  No shortcuts w.r.t. Motif naming have been made, only
> "trivial" transformations.  Secondly, some functions have had their
> arguments switched, therefore, in CMUCL they now are &rest functions,
> instead of functions where you need to cons up a structure/list to be
> passed back and forth.

> Anyway, CMUCL/Motif works pretty well with CMUCL, I guess it'd be
> rather easy to port it to other CLs as well.

Personally, I don't care about CLM backward compatibility [I doubt anyone does].
I think it's easier to move CLM towards CMUCL/Motif than replicating missing CLM
functionality
in CMUCL/Motif., "from GINA, and 1 function at a time". Or am I wrong?

--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))

Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

www.csem.ch      www.vrai.com     ligwww.epfl.ch/matomira.html



Sat, 04 May 2002 03:00:00 GMT  
 GUI event loops


Quote:

> > First of all, CMUCL/Motif is more consistent when it comes to naming
> > things.  No shortcuts w.r.t. Motif naming have been made, only
> > "trivial" transformations.  Secondly, some functions have had their
> > arguments switched, therefore, in CMUCL they now are &rest functions,
> > instead of functions where you need to cons up a structure/list to be
> > passed back and forth.

> > Anyway, CMUCL/Motif works pretty well with CMUCL, I guess it'd be
> > rather easy to port it to other CLs as well.

> Personally, I don't care about CLM backward compatibility [I doubt
> anyone does]. I think it's easier to move CLM towards CMUCL/Motif
> than replicating missing CLM functionality
> in CMUCL/Motif., "from GINA, and 1 function at a time". Or am I wrong?

I cannot really say.  There are some features you find in CLM that are
not in CMUCL/Motif, but I don't see the the necessary forces around to
do such a thing.

Anyway, I'd be more interested in a better (more R6) implementation of
CLX.

Cheers

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa



Sun, 05 May 2002 03:00:00 GMT  
 GUI event loops

Quote:

> Anyway, I'd be more interested in a better (more R6) implementation of
> CLX.

Well, of course if like Lisp toolkits more, but native look&feel is more
important for me
(not `me-me', the lusers, of course..)


Sun, 05 May 2002 03:00:00 GMT  
 GUI event loops

Quote:
> BTW, there's a copyright notice in your files, and a GPL COPYING
> file in the distribution, but there's no explicit notice explaining
> what's the role of the latter.

I have now changed the license to a BSD-style one. The copyright
notice informs who the "owner" of the software is, and the COPYING
file explains under what terms this "owner" allows the stuff to be
copied. I've added a "Distribution" entry in the file headers to
indicate this.

Have a look at <URL:http://www.cs.uit.no/~frodef/sw/cl-glade/> :-)

--
Frode Vatvedt Fjeld



Tue, 14 May 2002 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. GUI/event loop programming is Continuation Passing - paper

2. Continuations and GUI event loops

3. Tcl Event Loop vs TK Event Loop issues with Asynchronous Events

4. Merging Tcl's event loop with some other event loop

5. Merging Tcl's event loop with other event loops (notifier)

6. Multithreaded C++ and Tk GUI: Tcl Event Loop

7. Handling file events in the event loop

8. Extend TK event loop to handle user defined event

9. Expect event loop triggers 'after' events

10. Creating a new event source in the TCL event loop

11. Handling Tk-Events in Motif-Event Loop

12. Bug in event loop ??

 

 
Powered by phpBB® Forum Software