Thread: [pyGEF-develop] Some python tech: zope.interface and enthough Traits
Status: Pre-Alpha
Brought to you by:
hrgerber
Menu
▾
▴
pygef-develop
|
From: <pyg...@li...> - 2007-06-08 01:24:15
|
Just thought I'd mention these two packages that might be helpful in
putting together a big python system.
--------------------
zope.interface:
>From the link below:
"""
Interfaces provide a number of important benefits:
* Documentation
* Specification
* Support for component systems
"""
It gives you a nice way for instance to specify and check that classes
used as 'control' satisfy certain requirements without requiring them
to derive from an uber "Control" base class.
I've run into it a few times in bigger Python projects (specifically
twisted and Skencil if IIRC)
http://www.python.org/pypi/zope.interface/3.3.0
-------------------
enthought's Traits / TraitsUI:
>From the user guide link below:
"""
A common and well-tested approach to building end-user applications is
the MVC ("Model-
View-Controller") design pattern. [...] The three parts of the MVC
pattern correspond roughly to the HasTraits class in Traits and the
View and Handler classes in Traits UI. The remainder of this section
gives an overview of these relationships.
"""
This one is reportedly used extensively throughout Enthought, but
until recently the only way to get it was in one huge bundle with
enthought's whole massive toolsuite, so I think that has hampered
adoption. But recently they've started reorganizing their codebase so
that things like Traits can be downloaded and used individually.
http://code.enthought.com/traits/
user manual:
https://svn.enthought.com/enthought/browser/trunk/enthought.traits/enthought/traits/doc/Traits2_UM.pdf?format=raw
See chapter 1.2 Background in particular for a good motivation.
Related to Traits, but independent, is TraitsUI. This lets you create
GUIs automatically from Traits (currently wxPython only, but pyQt is
in the works).
traits UI user guide:
https://svn.enthought.com/enthought/browser/trunk/enthought.traits/enthought/traits/doc/Traits%20UI%20User%20Guide.pdf?format=raw
-----------------
There was a discussion on the enthought-dev ML last year about
incorporating interface functionality into Traits, but I'm not sure
where that ended up.
https://mail.enthought.com/pipermail/enthought-dev/2006-October/003325.html
Just some things to think about. Using something like these can have
a big impact on what the code will look like in the end, so it's worth
deciding early on.
--bb
|
|
From: <pyg...@li...> - 2007-06-08 04:47:42
|
Word from enthought-dev is that the next version of Traits will have interface support. Read about it here: https://svn.enthought.com/enthought/wiki/Traits_2_1_Interfaces On 6/8/07, David C. Morrill <dmo...@en...> wrote: > The next version of traits (available now from the main ETS SVN trunk), > which is/will be called Traits 2.1 or Traits 3.0, includes (among other > new features) support for interfaces and adapters based on PyProtocols > (although the PyProtocols API is not exposed directly). The code is > working fine if you want to try it out, although there may still be a > few more tweaks to the syntax/semantics before the final version is > released. > > You can read all about the new features (including interfaces/adapters) > at: http://svn.enthought.com/enthought/wiki/Traits in the topics under > the "Traits 2.1 Features" section. There's also an interactive set of > tutorials available when you check out the code... > > Dave Morrill > _______________________________________________ > Enthought-dev mailing list > Ent...@ma... > https://mail.enthought.com/mailman/listinfo/enthought-dev > > |
|
From: <pyg...@li...> - 2007-06-12 17:05:10
|
Hi=20 Thanks for the info. Really great news.=20 I had just started designing a messaging system, I just couldn't = continue without one anymore. Now I can just use traits. Spent the last couple of days reading manuals and playing with Traits.=20 So far I have only read the Traits UI manual as I am having some trouble = getting Traits UI to work with wx 2.8.=20 Very impressive. I have previously looked at Zope interfaces, but I think Traits is much = better suited to what we want to do.=20 I have been playing with the older version of traits. I'm just busy = changing my python to 2.5 and decided to change back to MS Visual Studio = 2003 as I really struggle to compile python packages with 2005/gcc and = not all packages come precompiled for 2.5.=20 Long story short, I've got a bit of installation to do. Then I can play = with Traits UI and interfaces.=20 What is the easiest way of getting Enthought ETS installed on py 2.5? I have made a few changes and bug fixes to pyGEF again, but saw that I = broke the creation of connections. This is at the app level though, i.e. = not the fault of the framework.=20 I still have to figure a few things out with the SelectionManager. We = should talk a bit about this. First I'm reading up on how the other GEFs = did this. Also added side panels for ControlsView and LayerManagerView (to make = debugging easier), but they don't contain anything yet as I first want = to convert, as much as I can, to make use of Traits and interfaces = instead. It will just make things easier and I can then clean up a few = things as well.=20 Regards Retief Retief Gerber Lektor Lecturer Departement Elektriese en Elektroniese Ingenieurswese Department of Electrical and Electronic Engineering Tel: +27 21 808 4011 =A0I =A0Faks/Fax: +27 21 808 4981 E-pos/E-mail: hrg...@su... Universiteit Stellenbosch University Privaat Sak/Private Bag X1 Matieland 7602=20 Suid-Afrika/South Africa www.eng.sun.ac.za > -----Original Message----- > From: pyg...@li... [mailto:pygef- > dev...@li...] On Behalf Of pygef- > de...@li... > Sent: 08 June 2007 06:48 AM > To: pyg...@li... > Subject: Re: [pyGEF-develop] Some python tech: zope.interface and > enthoughTraits >=20 > Word from enthought-dev is that the next version of Traits will have > interface support. > Read about it here: > https://svn.enthought.com/enthought/wiki/Traits_2_1_Interfaces >=20 > On 6/8/07, David C. Morrill <dmo...@en...> wrote: > > The next version of traits (available now from the main ETS SVN > trunk), > > which is/will be called Traits 2.1 or Traits 3.0, includes (among > other > > new features) support for interfaces and adapters based on > PyProtocols > > (although the PyProtocols API is not exposed directly). The code is > > working fine if you want to try it out, although there may still be = a > > few more tweaks to the syntax/semantics before the final version is > > released. > > > > You can read all about the new features (including > interfaces/adapters) > > at: http://svn.enthought.com/enthought/wiki/Traits in the topics > under > > the "Traits 2.1 Features" section. There's also an interactive set = of > > tutorials available when you check out the code... > > > > Dave Morrill > > _______________________________________________ > > Enthought-dev mailing list > > Ent...@ma... > > https://mail.enthought.com/mailman/listinfo/enthought-dev > > > > >=20 > = ----------------------------------------------------------------------- > -- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > pyGEF-develop mailing list > pyG...@li... > https://lists.sourceforge.net/lists/listinfo/pygef-develop |
|
From: <pyg...@li...> - 2007-06-13 02:42:28
|
On 6/13/07, pyg...@li... < pyg...@li...> wrote: > Hi > > Thanks for the info. Really great news. Cool I was wondering what happened to you. > I had just started designing a messaging system, I just couldn't continue without one anymore. Now I can just use traits. I'm not sure if you can really call Traits a "messaging" system. It's more of a type enforcement system, but yeh, it does also provide a way to watch modified Trait values. But I wouldn't be surprised if you need to have some messages that aren't trait related. There is also wx.lib.pubsub which despite being inside wxPython contains no wx stuff at all. It should probably be made a separately downloadable entity (like zope.interface, part of zope, but also a separate component). The actual code is only around 800 lines (without the tests) See here -- http://wiki.wxpython.org/PubSub Basic usage looks very straightforward. > Spent the last couple of days reading manuals and playing with Traits. > So far I have only read the Traits UI manual as I am having some trouble getting Traits UI to work with wx 2.8. > Very impressive. I haven't really tried to get TraitsUI working yet. Anyway you want to get the latest development version of Traits, since the released 1.x version doesn't have interfaces. > I have previously looked at Zope interfaces, but I think Traits is much better suited to what we want to do. With 2.0 it does offer the nice one-stop shopping for all typing specifications -- classes (interfaces) and parameters (traits). I'm not as sold on TraitsUI yet, just because their automatically generated interfaces tend to look just like that -- automatically generated interfaces. But for some parts of the UI it makes sense. I suspect I would end up wanting to code a custom UI factory though to do the mapping of traits to widgets myself. Gael Varoquox has made a nice tutorial for TraitsUI, though, in which he creates a GUI that looks fairly decent. It's a great Traits tutorial anyway. http://gael-varoquaux.info/computers/traits_tutorial/index.html > I have been playing with the older version of traits. I'm just busy changing my python to 2.5 and decided to change back to MS Visual Studio 2003 as I really struggle to compile python packages with 2005/gcc and not all packages come precompiled for 2.5. > Long story short, I've got a bit of installation to do. Then I can play with Traits UI and interfaces. Too funny. I just spent the last two days finally converting over to Python 2.5 and VS 2005 too. And just like you I'm not really happy with VS 2005. It seems quite a bit slower and more bloated than VC 2003. > What is the easiest way of getting Enthought ETS installed on py 2.5? 1) Get easy_install. -- download and run this file: http://peak.telecommunity.com/dist/ez_setup.py 2) Get latest enthought stuff from their eggs repository -- easy_install -f http://code.enthought.com/enstaller/eggs/windows/xp/unstable/ enthought.traits (change the url to what's appropriate if you aren't on windows/xp) To make it easier to update in the future you can add this to a file called pydistutils.cfg in your home directory: [easy_install] find_links = http://code.enthought.com/enstaller/eggs/windows/xp/ http://code.enthought.com/enstaller/eggs/windows/xp/unstable/ > I have made a few changes and bug fixes to pyGEF again, but saw that I broke the creation of connections. This is at the app level though, i.e. not the fault of the framework. > > I still have to figure a few things out with the SelectionManager. We should talk a bit about this. First I'm reading up on how the other GEFs did this. Yes it does seem to be a bit tricky. What issues are you thinking about? In my overhaul of pySketch I've set it up so the selection tool asks objects for a handle at the specified point. If an object has a manipulation handle at the specified location it should return an object-specific identifier (could be a whole object). Then as the user drags events are sent to the object who had the handle along with the handle identifier. Well almost that's what happens. Actually I have the selection tool calling a "moveHandle" method on the objects directly, but my ultimate plan is to delegate the event handling to the objects themselves (or maybe even the handle objects returned by getHandleAtPoint()). The part I'm least confident about right now is how to show the feedback as things are dragged around on the canvas. On the one hand you want to really make the changes as the user is dragging, but on the other hand you'd kind of like to avoid committing to it in order to avoid excessive, slow updates, and in case the user decides to cancel the operation in the end. Right now I'm giving the _Tools_ a draw() method to do with as they please. For instance the CreateRectangle tool uses that to draw the rectangle being added until the user lets go of the mouse and it gets really added to the document. That simplifies undo because there's only one "addObject" command to undo. But it seems kind of wrong design-wise for some reason. I guess because an object in the process of being added is as much a part of the document as a preexisting object. > Also added side panels for ControlsView and LayerManagerView (to make debugging easier), but they don't contain anything yet as I first want to convert, as much as I can, to make use of Traits and interfaces instead. It will just make things easier and I can then clean up a few things as well. Ok. Sounds good. --bb |
|
From: <pyg...@li...> - 2007-06-13 08:43:11
|
=20 From: pyg...@li... [mailto:pyg...@li...] On Behalf Of pyg...@li... Sent: 13 June 2007 04:42 To: pyg...@li... Subject: Re: [pyGEF-develop] Some python tech: zope.interface andenthoughTraits =20 On 6/13/07, pyg...@li... <pyg...@li...> wrote: > Hi=20 >=20 > Thanks for the info. Really great news. Cool I was wondering what happened to you. > I had just started designing a messaging system, I just couldn't continue without one anymore. Now I can just use traits.=20 I'm not sure if you can really call Traits a "messaging" system. It's more of a type enforcement system, but yeh, it does also provide a way to watch modified Trait values. But I wouldn't be surprised if you need to have some messages that aren't trait related. =20 [[RETIEF:]] As far as I read the Event Trait can be used to implement a basic messaging system, although I am sure that this was not the intended usage. I have to think about this again. =20 There is also wx.lib.pubsub which despite being inside wxPython contains no wx stuff at all. It should probably be made a separately downloadable entity (like zope.interface, part of zope, but also a separate component). The actual code is only around 800 lines (without the tests)=20 See here -- http://wiki.wxpython.org/PubSub Basic usage looks very straightforward. [[RETIEF:]] I have used this before, another good option. > Spent the last couple of days reading manuals and playing with Traits. > So far I have only read the Traits UI manual as I am having some trouble getting Traits UI to work with wx 2.8. > Very impressive. I haven't really tried to get TraitsUI working yet. Anyway you want to get the latest development version of Traits, since the released 1.x version doesn't have interfaces. > I have previously looked at Zope interfaces, but I think Traits is much better suited to what we want to do. With 2.0 it does offer the nice one-stop shopping for all typing specifications -- classes (interfaces) and parameters (traits).=20 I'm not as sold on TraitsUI yet, just because their automatically generated interfaces tend to look just like that -- automatically generated interfaces. But for some parts of the UI it makes sense. I suspect I would end up wanting to code a custom UI factory though to do the mapping of traits to widgets myself.=20 Gael Varoquox has made a nice tutorial for TraitsUI, though, in which he creates a GUI that looks fairly decent. It's a great Traits tutorial anyway. http://gael-varoquaux.info/computers/traits_tutorial/index.html [[RETIEF:]] I saw this, I do have a few question that I will have to ask him. I don't really know how configurable/integratable the Traits UI is. I have a feeling that is quite restrictive or that it would require a lot of work to customize. Only using it will tell. > I have been playing with the older version of traits. I'm just busy changing my python to 2.5 and decided to change back to MS Visual Studio 2003 as I really struggle to compile python packages with 2005/gcc and not all packages come precompiled for 2.5. > Long story short, I've got a bit of installation to do. Then I can play with Traits UI and interfaces. Too funny. I just spent the last two days finally converting over to Python 2.5 and VS 2005 too. And just like you I'm not really happy with VS 2005. It seems quite a bit slower and more bloated than VC 2003.=20 [[RETIEF:]] Have you been able to compile any Python packages with VC 2005? > What is the easiest way of getting Enthought ETS installed on py 2.5? 1) Get easy_install. =20 -- download and run this file: http://peak.telecommunity.com/dist/ez_setup.py=20 2) Get latest enthought stuff from their eggs repository -- easy_install -f http://code.enthought.com/enstaller/eggs/windows/xp/unstable/ enthought.traits=20 (change the url to what's appropriate if you aren't on windows/xp) To make it easier to update in the future you can add this to a file called pydistutils.cfg in your home directory:=20 [easy_install] find_links =3D http://code.enthought.com/enstaller/eggs/windows/xp/ =20 http://code.enthought.com/enstaller/eggs/windows/xp/unstable/ =20 [[RETIEF:]] I got it working last night with some help from a guy named Rick at enthough. I installed the entire ETS. There is now a new install script ez_enstaller_setup.py.=20 > I have made a few changes and bug fixes to pyGEF again, but saw that I broke the creation of connections. This is at the app level though, i.e. not the fault of the framework. >=20 > I still have to figure a few things out with the SelectionManager. We should talk a bit about this. First I'm reading up on how the other GEFs did this. Yes it does seem to be a bit tricky. What issues are you thinking about? In my overhaul of pySketch I've set it up so the selection tool asks objects for a handle at the specified point. If an object has a manipulation handle at the specified location it should return an object-specific identifier (could be a whole object). Then as the user drags events are sent to the object who had the handle along with the handle identifier. Well almost that's what happens. Actually I have the selection tool calling a "moveHandle" method on the objects directly, but my ultimate plan is to delegate the event handling to the objects themselves (or maybe even the handle objects returned by getHandleAtPoint()).=20 The part I'm least confident about right now is how to show the feedback as things are dragged around on the canvas. On the one hand you want to really make the changes as the user is dragging, but on the other hand you'd kind of like to avoid committing to it in order to avoid excessive, slow updates, and in case the user decides to cancel the operation in the end. Right now I'm giving the _Tools_ a draw() method to do with as they please. For instance the CreateRectangle tool uses that to draw the rectangle being added until the user lets go of the mouse and it gets really added to the document. That simplifies undo because there's only one "addObject" command to undo. But it seems kind of wrong design-wise for some reason. I guess because an object in the process of being added is as much a part of the document as a preexisting object.=20 [[RETIEF:]] There are a couple of options. In pyGEF I create the new Control (Document element), but don't add it to the document. All controls have a createfigure and createdragfigure method. When a element is added to the design the createfigure method is used to create the figure that is added to the document. The createdragfigure is used to create the figure that is dragged. This figure is held by the Tool, which adds and removes it from the canvas. All dragfigures should be placed on the drag layer. Then only this layer needs to be redrawn as the figure is moved. The other layers can be drawn as a background bitmap. The CreateCommand, that adds the element to the document, is then only called one the element is placed. This make undo easy. It also makes the escape easy as the add figure to canvas is not implemented as a command. You generally can't undo the escape from a specific tool, although this could be an interesting feature. =20 =20 The other option is to Issue the CreateCommand at the beginning and then merge all the MoveCommands as the element is dragged. However this way you can't restrict the drawing to a specific layer, so redrawing is much more expensive. =20 [[RETIEF:]] I can see that I must change the names of some of my classes to make things more clear. Here are some suggestions (please comment): Editor -> Document Canvas -> View or DocumentView Control -> Element or DocumentElement/Component/DocumentControl DataModel -> ElementData or ElementDataModel/DocumentDataModel/ElementModel Figure -> ElementView/ Graphic ? or GraphicObject/DrawObject/DocumentGraphic I'm leaning towards the first suggestions. =20 > Also added side panels for ControlsView and LayerManagerView (to make debugging easier), but they don't contain anything yet as I first want to convert, as much as I can, to make use of Traits and interfaces instead. It will just make things easier and I can then clean up a few things as well.=20 Ok. Sounds good. --bb |
|
From: <pyg...@li...> - 2007-06-13 09:00:49
|
> *[[RETIEF:]] Have you been able to compile any Python packages with VC > 2005?* > >From what I understand Python 2.5 itself is still compiled with VC 2003. > *[[RETIEF:]] There are a couple of options. In pyGEF I create the new > Control (Document element), but don't add it to the document. All controls > have a createfigure and createdragfigure method. When a element is added to > the design the createfigure method is used to create the figure that is > added to the document. The createdragfigure is used to create the figure > that is dragged. This figure is held by the Tool, which adds and removes it > from the canvas. All dragfigures should be placed on the drag layer. Then > only this layer needs to be redrawn as the figure is moved. The other > layers can be drawn as a background bitmap. The CreateCommand, that adds > the element to the document, is then only called one the element is placed. > This make undo easy. It also makes the escape easy as the add figure to > canvas is not implemented as a command. You generally can't undo the escape > from a specific tool, although this could be an interesting feature. * > > * * > > *The other option is to Issue the CreateCommand at the beginning and then > merge all the MoveCommands as the element is dragged. However this way you > can't restrict the drawing to a specific layer, so redrawing is much more > expensive.* > > * * > > *[[RETIEF:]] I can see that I must change the names of some of my classes > to make things more clear.* > > *Here are some suggestions (please comment):* > > * Editor -> Document* > > * Canvas -> View or DocumentView* > > * Control -> Element or > DocumentElement/Component/DocumentControl* > > * DataModel -> ElementData or > ElementDataModel/DocumentDataModel/ElementModel* > > * Figure -> ElementView/ Graphic ? or > GraphicObject/DrawObject/DocumentGraphic* > > *I'm leaning towards the first suggestions.* > Gotta go now... I'll reply to this later. --bb |
|
From: <pyg...@li...> - 2007-06-13 19:28:42
|
On 6/13/07, Bill Baxter <wb...@gm...> wrote: > > [[RETIEF:]] There are a couple of options. In pyGEF I create the new > Control (Document element), but don't add it to the document. All controls > have a createfigure and createdragfigure method. When a element is added to > the design the createfigure method is used to create the figure that is > added to the document. The createdragfigure is used to create the figure > that is dragged. This figure is held by the Tool, which adds and removes it > from the canvas. All dragfigures should be placed on the drag layer. Then > only this layer needs to be redrawn as the figure is moved. The other > layers can be drawn as a background bitmap. The CreateCommand, that adds > the element to the document, is then only called one the element is placed. > This make undo easy. It also makes the escape easy as the add figure to > canvas is not implemented as a command. You generally can't undo the escape > from a specific tool, although this could be an interesting feature. That sounds more or less like how I was doing it. Tool holds onto the new object till creation parameters are fixed, and then the "AddObject" command is issued. But for a more general drawing app you might want the interactive placement step to draw the object in the correct layer while dragging, so it won't necessarily be on top. > > [[RETIEF:]] I can see that I must change the names of some of my classes > to make things more clear. > > > > Here are some suggestions (please comment): > > > > Editor -> Document Document is often used to mean "DataModel" in things like the wx DocView framework. I'm not sure that's the role Editor is serving. > > Canvas -> View or DocumentView Similarly it seems Editor has-a Canvas whereas in the typical Doc/View paradigm one "Document" can have many "Views". > > > > 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. --bb |
|
From: <pyg...@li...> - 2007-06-13 21:41:24
|
> -----Original Message----- > From: pyg...@li... [mailto:pygef- > dev...@li...] On Behalf Of pygef- > de...@li... > Sent: 13 June 2007 09:29 PM > To: pyg...@li... > Subject: Re: [pyGEF-develop] Some python tech: > zope.interfaceandenthoughTraits >=20 > On 6/13/07, Bill Baxter <wb...@gm...> wrote: > > > [[RETIEF:]] There are a couple of options. In pyGEF I create the > new > > Control (Document element), but don't add it to the document. All > controls > > have a createfigure and createdragfigure method. When a element is > added to > > the design the createfigure method is used to create the figure that > is > > added to the document. The createdragfigure is used to create the > figure > > that is dragged. This figure is held by the Tool, which adds and > removes it > > from the canvas. All dragfigures should be placed on the drag layer. > Then > > only this layer needs to be redrawn as the figure is moved. The > other > > layers can be drawn as a background bitmap. The CreateCommand, that > adds > > the element to the document, is then only called one the element is > placed. > > This make undo easy. It also makes the escape easy as the add figure > to > > canvas is not implemented as a command. You generally can't undo the > escape > > from a specific tool, although this could be an interesting feature. >=20 > That sounds more or less like how I was doing it. Tool holds onto the > new object till creation parameters are fixed, and then the > "AddObject" command is issued. But for a more general drawing app you > might want the interactive placement step to draw the object in the > correct layer while dragging, so it won't necessarily be on top. >=20 > > > [[RETIEF:]] I can see that I must change the names of some of my > classes > > to make things more clear. > > > > > > Here are some suggestions (please comment): > > > > > > Editor -> Document >=20 > Document is often used to mean "DataModel" in things like the wx > DocView framework. I'm not sure that's the role Editor is serving. >=20 [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 >=20 > Similarly it seems Editor has-a Canvas whereas in the typical Doc/View > paradigm one "Document" can have many "Views". >=20 [Retief:] Yes, the a DocumentController can then have many Views/DocumentViews? > > > > > > Control -> Element or > > DocumentElement/Component/DocumentControl >=20 > I like Element, yep. >=20 > > > > > > DataModel -> ElementData or > > ElementDataModel/DocumentDataModel/ElementModel >=20 > I like ElementData too, yep. >=20 > > > Figure -> ElementView/ Graphic ? or > > GraphicObject/DrawObject/DocumentGraphic >=20 > I lean towards Graphic or GraphicObject. >=20 [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. > ----------------------------------------------------------------------- > -- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > pyGEF-develop mailing list > pyG...@li... > https://lists.sourceforge.net/lists/listinfo/pygef-develop |
|
From: <pyg...@li...> - 2007-06-14 00:24:35
|
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 |
Thanks for helping keep SourceForge clean.
X