Re: [fc] Summer of Code

[Nitro]

I wrote the first version of a UseCase. Please tell me what you think of it. There might be small errors/problems I did not notice. The UseCase.py file is attached, I hope it gets through. If not, I'll send it to you. Am 08.05.2008, 19:50 Uhr, schrieb Christopher Barker <[EMAIL PROTECTED]>:

I think sometime soon we should summarize some of the core decisions,
like what versions we're planning on supporting, etc, and post that to
the wxPython list to solicit feedback.

Alright.

Yup.

Say the user has a database of a flowerbed with positions for all flowers.

Then he could hook fc somehow so that the flowers in the db correspond

fc scenegraph (document).

with the flowers seen in fc. This means creating/deleting the nodes in the

Right, but this could just as easily be accomplished by
creating/deleting/altering entire DrawObjects. There are some slight
performance gains possible with the more MVC approach (more shared
objects), but I'm not yet convinced that we get anything else. ON the
other hand, if we can wrap it up in an easy-to-use interface, then maybe
we don't lose anything either.

Yes. I think both is possible. The FlowerBed in the UseCase example makes use of a very simple fc.Rectangle call.

Not sure if you count this as "Float canvas

document".

object level" or "each flower is a view and together they form the entire

Well, the entire document is a view of the entire database, while each
node is a view of each individual flower -- this makes my head hurt!

Maybe this comes down to this:

How do want to handle the changing of an individual flower?

1) The flower object gets changed -- it notifies the flowerbed model
that a change has occurred. The flowerbed model sends out a message that


2) The flower object gets changed -- it sends out a message that it has
changed, and both the flowerbed model and the Scenegraph can respond to
that change.

If was summarize these questions, maybe we can send them to some key
people, like perhaps the folks that wrote or contributed to the MVC/MVP
pages on the wxPython list.

something has changed, and the FloatCanvas Scenegraph can respond to that.

Yes, also be sure to check this part in the UseCase. I guess the way it's setup there would be ok for me (as a user).

And yes, the IFlowerData is an interface (hence the I- prefix)

OK -- I'll look up zope interfaces, though it feels a bit JAVA-ish to me!

Yes, it doesn't feel to pythonic. But the user needs some
code/documentation when he wants to extend things. Interfaces tend to be
ok for that.

If you think you want to do formal interfaces, code up an example, and
lets see.

By the way, I do like the idea of Enthought Traits -- we should
definitely consider using that -- I think we can bundle the package so
it won't be an external dependency. At least until you can do
"easy_install traits" reliably on all platforms.

Ok, have to check that out more in detail.

I am not sure I understand the problem here and how it relates to having
more than one renderer for an object. I'd write your example like this

class PointsData(list):
     # instead of subclassing from list, one could also subclass from
object and then add this:

right -- I wouldn't subclass from list --

  1) I think of a pointsdata object as Using a list, rather than Being a
list

  2) It should be a numpy.ndarray anyway!

     # def __init__(self, points):
     #     self.points = points

# can eventually omit this
class LinesData(PointsData):
     pass
     # Do you want to add a ConvertToSpline() method here?

This is the question, I think they way you're setting it up, it doesn't
belong there, as whether it's a Spline or Line isn't a property of the
LinesData object at all.

I think it is. After all the type is LineData, meaning it is *line* data, and not a general list/array of points. It might be useable by both renderers since it is the same in the sense of duck typing, but the type clearly states it's specifically meant to be a line.

yup. Except this needs to be wrapped up in a class(your node?), so there


def Spline(points, ...)
     spline = Node()
     spline.Data = LinesData(points)
     spline.Renderer = SplineRenderer
     spline.Style = LineStyle(...)
     return spline

is one object for the user to deal with. And we need the factory functions:

Yes, see the code.

I like that. Not sure if whether a layer gets rendered to its own bitmap
or directly to the main one is a property of the layer or manged by the
main rendering code...

Ya, I am also not too sure about how to do that. The example code shows one way it could be set up, but definately not the only one.

The other options is to make some kind of importer hook where the svg file

is loaded and convert it to fc native renderables.

I think this is the way to go.

Yes, I also like it better. It's the same as the view as a whole question above. It makes more sense to create lots of small little views and not have another document for the whole thing.

I can only test on XP. No other platforms around here. If we really need

absolutely necessary.

to I can probably setup a virtual machine with linux, but not unless it's

Yes -- I saw your post on the wxPython list!

I think for this task I'd still feel comfortable with it :-)

Any float canvas users here who use linux and would
like to help testing?

Let's put a call out for testing when we get something to test. We
should be testing on the three major platforms early on though. I can
probably support Linux and OS-X, but if there end up being frequent
issues, it might be worth your setting up a Linux VM or partition.

Yes, we see when time comes.

-Matthias

UseCase.py
Description: Binary data

_______________________________________________
FloatCanvas mailing list
FloatCanvas@mithis.com
http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas