Hi David,

David Poundall wrote:
> You may recall that previously I was physically doing a redraw every 
> time I added an object to the canvas, but direct calls to your draw 
> event (specifically using zoom) go outside of this and things start 
> falling apart with my framework. 

yes, this was a bit ugly-- I think I agree that it really makes the most 
sense to have a Properties object of some sort, so that all properties 
can be passed around more easily, rather than having each one dealt with 
individually.

> So my question is how best to proceed.  Is floatcanvas.py stable for you 
> at the moment, ie. are there no significant changes in the offing?

Well, I wouldn't say that -- I"d like to re-work the event binding code 
-- but that should be orthogonal to what you're doing. In any case, I"m 
really not sure how much time I can put into it for a while, so the 
current SVN is the best version to work with.

 >  That
> being the case I can do the changes I need over the next few days and 
> ping them back to you critiquing.

Good plan. If we go forward with more changes, we could create a branch 
in SVN, and I could get you write access so we can collaborate that way.

> I will be looking to add the following functionality to the code.
> 
>    1. All objects to have a properties dict (call it pdict for now).

This is a good idea -- however, do take a look at the enthough traits 
package. I"m totally sure that I want to add the dependency, but it 
seems that traits is exactly what we want here:

  -- You can define which traits a given object can have, and what 
values that trait can have. This provides a lot of error checking for you.
  -- They have wxPython code that can automatically build a dialog to 
edit any traited object -- that could save a lot of code also.

If we just use a dict, then we'll be repeating a lot of the work that is 
built in to traits.

>    2. Introduce Zorder as one of the properties in pdict and modify the
>       internal _dlist to refer to Zorder on a draw where the property
>       exists.  

I'm not sure about this one -- I don't really see zorder as a property 
of the DrawObject itself, but rather a property of the Canvas it's on -- 
or the "Document" or layer, or something. Part of this idea comes from 
how I've always envisioned that the same DrawObject could exist outside 
of any Canvas, and perhaps be on more than one canvas at once.

I have thought about how there really should be some sort of "Document" 
or "Drawing" object that FloatCanvas uses to keep track of the 
DrawObjects, rather than just a couple lists, like it has now. This 
would provide a place for code to save the Drawing, and perhaps code to 
manipulate z-order and the like. To start, I think it could just be a 
class with a _DrawList and _ForeDrawList attributes (and few others, 
like maybe the various "Dirty" flags.

Whether or now we do that, I've always intended to have methods like:

MoveObjectToTop
MoveObjectToBottom
ShiftObjectUp

etc.

On the other hand, in some applications some sort of z-order value could 
make sense -- if it's optional, then it won't hurt anything.

>    3. Any move change to an object that is within a group will act on
>       all members of that group.   It’s a simple way of adding some
>       functionality to grouped objects.  pdict will identify the
>       groupings and be able to apply any ‘dxy’ changes to all items
>       within the group easily.

This I'm not so sure about -- for one, it's bit tricky to implement - it 
means that an Object would have to know that it's in a Group, and there 
would have to be some sort of messaging system to pass to the group the 
fact that something has been changed.

Also, sometimes you're going to want to change something about one 
object in a group without changing them all. One more thing -- "dxy" 
changes aren't really a property thing -- the property is the 
coordinates of the object, and different objects have those structured 
differently -- that's why I use a Move(dxy) method -- each object can 
implement it as it needs to.

Why not just keep that as a group method? That's what all the Group.Set* 
methods are now.

> What are your thoughts on the above?

The short version is that I'm glad to have the contribution -- it'll 
make FloatCanvas better.

> Merry Christmas by the way.

And a Happy Winter Solstice to you -- time for the days to start getting 
longer!

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

[EMAIL PROTECTED]
_______________________________________________
FloatCanvas mailing list
[email protected]
http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas

Reply via email to