Nitro wrote: > 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.
Sounds good. >> #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). If that's it, then maybe we only need one -- a particular application could still call them different things. When I think about GIS and drawing applications I've used, groups can be nested, and you can have multiple groups per layer, whereas there is simply one stack of layers. However, from a technical perspective, I don't see any reason to have that restriction for layers. Also, from a UI perspective, when objects are grouped, they then are selected as a group, and moved, etc as a group. Layers don't move, and usually they are selected in a different way. However, at the moment, it looks like a layer is simply a special case of a group. > 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. OK -- this is just going to be application dependent. > 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. yes -- I like that. It makes sense. >> #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. OK -- I see that. >> #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) Also, one thing BoundingBoxes are used for in the current FloatCanvas is to determine if a given object is in the view when drawing -- it's very helpful that all the DrawObjects have a BB in the same coords. I'm thinking that we may want to shift that check to the DrawObject itself, but it may get a bit slow to have to do a transform to do a bounding box check -- this applies to hit-testing too. We may find that we need to keep a BB in two different coord. systems, though then they'd have to be kept in sync. >> #chb: Should a BitmapLayer be a different class than a regular >> layer? Or > 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. if we use a non-binary flag, then it could have any number of values for multiple back ends -- but in any case, this is a bit different -- I think for other renderers, there is still the same question -- is it cached as a bitmap or not? Though I suppose that you'd never want to cache it as a bitmap with SVG, (or PDF) for instance. >> #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. yes, this is going to require some careful thought -- I see things like an offset distance (between say a point and it's label) as possibly being defined in three way, depending on the application: world coords --- easy pixel coords --- also easy paper coords -- this is trickier, as the mapping between paper coords and pixel coords is a function of scale. But, we may not want to have it change as the user zooms into a view -- that would be just using world coords. Here's and example I'd like to support: Say the user is drawing a map: when they print it they want 12 point fonts, and the text label to be 10 points to the right of the point that is being labeled. They need to define a scale for the map -- that will define the transform from paper to projected coordinates. However, when they work on the map, they may want to zoom in to look at some detail, and they'll want the relative position of everything to scale with that zoom -- so there are two scales: one that defines paper to projected coords, and one that defines projected coords to pixel coords for display. What all this means is that for a gen DrawObject, a user may want to define things like line widths, text size, spacing, etc in any of three (or more?) different coordinate systems. I'm not sure how to accommodate that without an ugly and confusing API. >> #chb: I'm confused a bit now what is a canvas? I was imaging a >> canvas would have 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. Ah -- so a Canvas is the document. > The > other things are more involved, because they require user > customization. Yes -- it will always take more to make custom objects, and the more complex those objects, the harder it will be, but I do think we can provide a framework that makes "the simple things are easy, and the hard things are possible" > 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. good idea. > 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. absolutely. > 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. Yes, that would be great -- maybe post to the wxPython list too. - 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
