Re: Sponsored Canvas (was: Re: The state of the canvas)

[Damon Chaplin <damon karuna uklinux net>]

On Fri, 2005-11-18 at 13:45 +0100, Alexander Larsson wrote:
> On Fri, 2005-11-18 at 11:00 +0100, Sven Herzberg wrote:

> One thing your page doesn't mention at all is layouting. Its very nice
> to be able to have some form of layout of items in a canvas. For
> instance if you put two items in another item you might want the max
> width of the two to set the parent item width and the other items width.

How would you do this in practice? I guess the GTK+
size_request/size_allocate model would fit in nicely with the rest of
GTK+ (especially if we support embedded widgets in future).

But would you do this for all items, or just ones that support a
particular interface? Basic canvas items like lines and rectangles
already have their positions set explicitly, so what would they do when
placed in a layout container?

I guess it is best to have special LayoutContainer and LayoutChild
interfaces and only allow LayoutChilds to be placed in LayoutContainers.

(I think this could be implemented on top of my code quite easily.)


> Unfortunately, in a model-view system such layouting conflicts with the
> sort of view-dependent (zoom dependent really) things you describe on
> your page. For instance, if one of the childrens of an item with
> layouted children changes with zoom level, then other child items
> positions can depend on the zoom level of the view, and have different
> positions in different views. Then there is no longer a common model.

I think you're assuming the model is graphical in nature. But it doesn't
have to be, so I don't see a problem with views varying wildly.
(The model may just be structural, so absolute positions aren't
important.)


> Have you looked at Piccolo? The camera model they use is very
> interesting, because it allows an item to be visible in multiple places
> in the view which allows some cool effects like drop shadowing very
> easily.

How can you do drop shadowing in Piccolo? I can't quite figure out how
that would be done from looking at the API.

I like their idea of having separate affine transformations for the
overall view and for each layer, and also having 'sticky' objects that
don't move at all.

It also has a few simple animation features (e.g.
animateToPositionScaleRotation()), which might be useful and should be
easy to do.


Another useful idea is to be able to render a layer to a separate cairo
surface, and to perform some graphical operation on the entire layer
(change alpha/colors etc.) before applying the layer to the main
surface.

Damon