Am 20.05.2008, 20:20 Uhr, schrieb Christopher Barker <[EMAIL PROTECTED]>:
> Nitro wrote: >> have you found the time to review the use case? > > Finally! Sorry that took so long. Enclosed is a version with my > interspersed comments, proceeded but "#chb:" I got your version and worked through it. I don't comment on everything now, just the things which seem most important to me. I'll get started on the prototyping code the next week. Comments: > #chb: Good point -- what is the difference between a layer and a group? This is something I am not sure about myself, too. Right now it looks like they are the same, but in practice it may be different. A layer is probably a group along with a "render target" (bitmap/window). > #chb: This doesn't seem right -- now we have the look getting info from > the data -- shouldn't the look and the data be orthogonal? No, sometimes the data defines the look, too (just like the example where the model had the colour of the flower). Sometimes it does not, then it is orthogonal indeed. > #chb: "Do you have multiple looks?" You can call Renderer.ApplyLook multiple times with different looks. Or (the better way imo) you create a flower object as a group object of petals and center. > #chb: there should be a way to put this kind of math outside of the > Render method, in case it is computationally expensive. This is up to the user who wrote the flower class and easily possible. In this case the view has to register for the modelChanged event and update the cached x, y coordinates. > #chb: what coordinate system is the BoundingBox in? > #chb: (by the way, let's use properties where we can, so .BoundingBox > would be a property) Local (although this seems to impose problems with the non-linear projections, so we might change this to world) and agreed upon using properties instead of Get* methods. > #chb: Should a BitmapLayer be a different class than a regular layer? Or > could > #chb: we just set a flag as to whether the layer gets cached as a bitmap > -- > #chb: it seems that would be more flexible. A flag might do it although this might cause problems if you want a third backend (neither window nor bitmap, maybe for saving svgs). It's not a big problem though and is something we can easily interchange. > #chb: is fc.FRONT a constant like MaxInt -- or does it dynamically > figure out > #chb: what the z-value is for the front? If it's not a number, then I > prefer > #chb: text flags: where = "back" Good point, text flags it is. > #chb: What unit is that in? You may want a relative position in world > coords, or in pixel or paper coords. By default this is in local coordinates for me. However, you raise an interesting point. I think it boils down to where the transform is inserted in the transform chain. It probably looks like viewport_transform * projection_transform * camera_transform * parent_transform(s) * local_transform * coordinate_vector. I need to think more about a way to handle coordinates in a generic way, yet with an easy user interface. The Scaled* set of classes is certainly interesting here. > #chb: Overall, thius looks like too much work -- perhaps some of those > calls could get rolled into a flowNode factory function. Yes, it is definately possible to provide some shortcuts here. > #chb: I'm confused a bit now what is a canvas? I was imaging a canvas > would hvae one view, but maybe that's what you're calling a renderer. A renderer is for me just the think which draws something, for example a GC. The canvas is a collection of nodes and such, but the same nodes can be rendered from different views. > #chb: Anyway, it's time to move on, and get some prototype code working, > and we'll see how more of this shakes out. I really agree on this one. > #chb: Do keep in mind that one of the goals of FloatCanvas is to provide > a simle API -- if people want complete control over eveything, then they > can jsut use a GC. For the most part, regular users shoudln;t hve to > think in term so transforms, etc. -- they should be able to just place > an object with a few properties on a canvas and have it drawn for them. Ok, I'll try to make things simpler to use. It seemed simple to me when I wrote it because I am already familiar with them, but to the normal gui user it's certainly overkill. The fc.Rectangle() call shows a typical very simple use case, coupled with adding a pos keyword to its constructor it seems it can't get much simpler. The other things are more involved, because they require user customization. Some of that can be made better though, like replacing flowerNode.transformer.translation with a position keyword argument in the RenderableNode constructor. Nodes can also have properties like position which will internally call self.transformer.translation = position. If you add another keyword parameter called "parent" to the RenderableNode, you can also save the .addChild call. There could be something like canvas.addObject(some_node) as well to provide an alternative, simplified entry point. Same for the view/camera. If I do this the code gets much simpler and the power user can still customize it. Maybe there's the core functionality in one class and then I write two mixins, one which adds the simplified layer on top of the default class and another one which is the backwards-compatibility layer. This might just be part of the class, too, but separating the "access/helper layers" from the real working code seems cleaner. Anyway, enough talk, I'll start coding, with an emphasis on keeping things simple to use. The first attempt is certainly not going to be exactly what we want to have in the end and some hurdles might turn up which we haven't foreseen. So I propose an iterative approach to this. I'd also like to see more typical use cases of current FloatCanvas users, so I can make sure they are taken care of in a good way. If you think it's a good idea, I'll post another mail on this list during the next days with a call for use cases/user code snippets and wishes/complaints that are not part of the TODO file and the wiki entries. -Matthias _______________________________________________ FloatCanvas mailing list [email protected] http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas
