Custom Event Handler

Toby Watson toby at tui.co.uk
Wed Aug 8 15:49:00 UTC 2001


Hi,

For anyone looking at this. You may find soem of the following papers
useful. Reference is often made to double dispatch, i.e. the action is
dependent on the tool _and_ object being it is being applied to.

http://www.research.ibm.com/people/v/vlis/pubs.html

"Tooled Composite," C++ Report, September 1999.
"Visitor in Frameworks," C++ Report, November/December 1999.

I've generally found this stuff a pain and quite opaque. Would people agree
that implementing good drawing editors remains a difficult task?

This was useful in my investigations :
http://citeseer.nj.nec.com/156213.html :

"Using the Multi-Layer Model for Building Interactive Graphical Applications
(1996)"
Jean-Daniel Fekete, Michel Beaudouin-Lafon
ACM Symposium on User Interface Software and Technology

Ultimately I found the Unidraw source code most illuminating.

For here on I get more vague.....

In addition - Adobe's InDesign SDK is quite revealing on the architecture of
their latest baby. It implements a small core hub with tools and objects all
implemented as plug-ins.

Some people have suggested that concurrency could provide some relief in
building such applications and graphical application/windowing systems in
general. They tend be aimed at removing the event loop spaghetti.  I notice
that the suggestion of capturing events by the tool is similar to this
approach. The main ones I know of are:

"Composing the user interface with Haggis"
http://citeseer.nj.nec.com/finne96composing.html
Example 10 in this is a drawing editor.

Stuff by Rob Pike - NewsSqueak, A Concurrent Window System. eXene concurrent
window system in ML. The Haskell reference is the only one with a drawing
editor.

cheers,
toby

----- Original Message -----
From: "Ned Konz" <ned at bike-nomad.com>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, August 08, 2001 3:41 PM
Subject: Re: Custom Event Handler


> On Wednesday 08 August 2001 07:07 am, Josh wrote:
>
> > > In
> > > effect, it raises the question of whether a tool "should be applied"
to
> > > an object or whether an object "should provide a service" if
stimulated
> > > with a certain tool. In my understanding, the latter is almost always
the
> > > better way to go although I do understand that changing existing
(e.g.,
> > > predefined) classes is not always a good thing to do.
> >
> > Could you point me at some literature on the topic?  The only thing I've
> > read wrt tools in object-oriented GUI frameworks was a paper on
InterViews.
>
> You should look at HotDraw as well
>  http://st-www.cs.uiuc.edu/users/brant/HotDraw/HotDraw.html
>
> In HotDraw, changing tools switches the state machine used to respond to
user
> interaction.
>
> There is an interesting paper about creating tools by composition at
> ftp://st.cs.uiuc.edu/pub/papers/HotDraw/HotDrawTools.ps.Z
>
> HotDraw has several kinds of tools that apply to different things:
> * CreationTool makes new objects
> * DrawingActionTool does something to the whole drawing
> * FigureActionTool does something to the next selected (clicked) object.
>
> Each of the kinds of tools also supplies an icon and a cursor (as I
recall).
>
> --
> Ned Konz
> currently: Stanwood, WA
> email:     ned at bike-nomad.com
> homepage:  http://bike-nomad.com
>
>
>
>





More information about the Squeak-dev mailing list