Custom Event Handler

Joshua 'Schwa' Gargus schwa at cc.gatech.edu
Wed Aug 8 19:59:51 UTC 2001


Thanks for the pointers!

Joshua

On Wed, Aug 08, 2001 at 04:49:00PM +0100, Toby Watson wrote:
> 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