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
|