On Tue, 2005-02-15 at 18:31 +0000, Bill Haneman wrote: >Gustavo said: > >> 2. Your canvas looks excessively complex to me. Are you sure we need >>canvas item model/renderer separation? I think you need it if: >> a) You want to store data that is specific for per item-view pair; >>Example: some caching of pixel coordinates, or something like that, I >>don't know.. >> >> >> >One of the things we need in a canvas is the ability to report the >objects drawn in it as objects, and report the bounding boxes and >stacking order of those objects. This is needed for accessibility >purposes; it might be easier to do this with a model/renderer >separation, I am not sure. I was thinking each canvas item would be a GObject with a virtual method to render itself to a cairo context. The canvas items would then be stored in a scene graph associated with a canvas _model_. Then we could have many canvas _views_ associated with the same model. Each view would have a distinct transformation matrix. So, while the stacking order of objects in each is the same as in the model, the bounding boxes would be obtained from the corresponding bounding box in the model multiplies by the view transformation matrix. So basically my proposal was that canvas items would provide functionality for both model+view[1], but we would still have model/view separation at the canvas level. I don't think it invalidates anything for accessibility work. Regards. [1] although the canvas view might need to wrap some view-specific state around a canvas item, that would be an implementation detail and invisible to the programmer, and the programmer not having to worry about this is the main benefit. -- Gustavo J. A. M. Carneiro <gjc inescporto pt> <gustavo users sourceforge net> The universe is always one step beyond logic.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature