Re: Canvas API proposal



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]