Re: [pyGEF-develop] Some python tech: zope.interfaceandenthoughTraits

[<pyg...@li...>]

On 6/14/07, pyg...@li... <
pyg...@li...> wrote:
I don't really have a good feeling for what the Editor's responsibilities
are from looking at the code.  It seems like a lot of what's there is stuff
that I might want to own myself at the application level.  Like the
CommandStacks.  On the other hand the LayerManager seems to me like it
should be in the canvas.

Seems like much of the functionality in Editor is either simply delegating
to someone else (e.g.. addfigure/removefigure) or it's implementing
functionality that may need to be overridden with something more
app-specific (like Load/Save if you don't want to use pickle as your file
format.)   I guess just aggregating a canvas and its undo stack and related
tools into one object is somewhat useful from the App's perspective.
Probably wouldn't be a bad idea to push as much of the functionality as
possible down to the canvas, though, so it's as easy as possible to replace
Editor with custom code.

One thing that Inkscape does is separate out a layer between "view" and
"document".  This layer deals with caching representations of document
objects that are tailored to the specific view.  For instance in a drawing
app, Bezier curves should be tessellated into line segments according to
their size on the screen, which depends on the zoom level of the document.
The doc contains bezier curves, the graphics API used by "View" only knows
how to display line segments.  So the doc is asked to create a display-list
for the current view.  The display-list in Inkscape's case has to be only
things that Cairo knows how to draw. In our case it might consist of things
wx.GraphicsContext knows how to draw.  Anyway just thought I'd mention
that.  At this point such a middle layer should probably be consided an
application-specific addition to a view.


[Retief:] Ok, so Document should only contain ElementData. So then what
> I had as Editor should then maybe be called
> DocumentController/Controller. This will clean up the loading and saving
> of Documents as it only contains DataModel objects that can be
> serialized. It is then easy to create a View for/from a Document. I
> think this makes things clearer.
>
> > > >               Canvas -> View or DocumentView
> >
> > Similarly it seems Editor has-a Canvas whereas in the typical Doc/View
> > paradigm one "Document" can have many "Views".
> >
>
> [Retief:] Yes, the a DocumentController can then have many
> Views/DocumentViews?
>
> > > >
> > > >               Control  -> Element or
> > > DocumentElement/Component/DocumentControl
> >
> > I like Element, yep.
> >
> > > >
> > > >               DataModel -> ElementData or
> > > ElementDataModel/DocumentDataModel/ElementModel
> >
> > I like ElementData too, yep.
> >
> > > >               Figure -> ElementView/ Graphic ? or
> > > GraphicObject/DrawObject/DocumentGraphic
> >
> > I lean towards Graphic or GraphicObject.
> >
> [Retief:] I was also leaning towards Graphic, but then the ElementData
> and DocumentView made me lean toward ElementView. Then again a figure is
> a graphic not a view. So I'm happy with Graphic
>
>
> [Retief:] I am just staring to convert things to traits, but there are
> still a few things that I need to sort out. How long have you been using
> traits?
> Is there a nice document about the inner workings/implementation of
> traits, as there are a lot of things that happen in the background, that
> traits "figures out" for itself.


If you mean something other than the "Traits User Manual" I don't know of
anything.  There are a bunch of examples
But the mailing list is very helpful, as you've found.

--bb