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

[Alexander Larsson <alexl redhat com>]

On Sat, 2005-11-19 at 11:08 +0000, Damon Chaplin wrote:
> 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'm not at all sure what is the best way to do this. Its a complicated
issue. But its not something new. I mean, gnome-canvas already
"supports" it in a fashion. Take for instance
addressbook/gui/widgets/e-minicard-label.c in evolution. It inherits
from GnomeCanvasGroup and resizes its child widgets. Thats easy though,
the hard part is how to handle an item growing due to a change in its
children. 

Take a look at Piccolo and their layoutChildren. They really don't
define exactly how size allocation is supposed to be working, but they
have some sort of model of how layout should work:
http://www.cs.umd.edu/hcil/piccolo/learn/patterns.shtml#Validating%20Bounds
I remember seeing various kludges in the code to avoid infinite loops
during "layout" though, so there are unwritten rules as to how you need
to do things. 

I'm not sure you need an size allocation scheme as complicated as the
main gtk+ one, but at the very least you need to define rules of what is
allowed and not, because people will do things like this.

> > 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.)

A canvas item view object is graphical though. And once you add things
like affine transformations of items or layouting of items you get a
mapping back from view object to the model object, so you force the
model to be graphical too.

I think the fact that a canvas is graphical is one of the main reasons
you use it. In the case where you have a structural model I think it
might be better to create a graphical model from the structural model
and use that, rather than trying to map your graphical object directly
on the structural model.

> > 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.

Their camera object can be used for making an item appear multiple times
in the view. Look at the CameraExample.java example. Then they have the
interesting node type PNodeCache (in edu.umd.cs.piccolox.nodes) which
caches its children as an image and draws that, but you can override it
and apply e.g. blur filters to the image.

> 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.

Yeah, sticky objects are very useful i think.

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

Yeah, i think easy to do animations and features like easy "allow this
item to be moved with the mouse" are important.

> 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.

This is essentially PNodeCache.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a sword-wielding moralistic Green Beret with acid for blood. She's a 
supernatural winged journalist who inherited a spooky stately manor from her 
late maiden aunt. They fight crime!