Re: Canvas shortcomings

[Lauris Kaplinski <lauris ximian com>]

Hello Federico!

On 21 Jun 2001 11:30:09 -0500, Federico Mena Quintero wrote:
> Lauris Kaplinski <lauris ximian com> writes:
> > c) There should be 3 coordinate systems:
> >    - world coordinates
> >    - window coordinates
> >    - user coordinates (item coordinates)
> >    with convenience methods (using window ones is tricky at moment)
> 
> Item coordinates are trivial; they are just the composited
> transformations of all the items from the root.
> 
> With this scheme, we can get rid of "world coordinates", which are a
> side effect of the current pixels_per_unit mess.  If you make the
> transformation of the root item be the one that converts from
> root-item coordinates into window coordinates, the problem is solved
> and we get rid of the so-called world coordinates.

One concern still - item->window transformation (albeit only translation
factor) changes with scrolling. So methods have to take that into 
account, and NOT update items for mere translation changes...

> I agree that the stock canvas items are almost useless.  I would like
> to have something like
> 
> 	Item - Abstract class, the most basic one.
> 
> 	Group : Item - Abstract class, defines the API for an item
> 	that contains other items.
> 
> 	Stack : Group - Like the current GnomeCanvasGroup, implements
> 	Z-ordering for items.
> 
> 	BPath : Item - PS-like path, which is the most general shape.
> 	You can then have convenience functions like
> 	make_bpath_from_rectangle (x1, y1, x2, y2) or make_ellipse (x, y, a, b).
> 
> 	Pixbuf : Item - A basic item for images.
> 
> 	Text : Item - Joe has been writing a canvas item for the text
> 	buffer thing from GTK+ 2.0.
> 
> The idea of having an abstract Group class is to have something as
> general as GtkContainer.  Then we provide a convenient Stack
> implementation of Group, which would be equivalent to the current
> GnomeCanvasGroup.

Right.
Btw, in my latest DOM experimentations, I am mostly happy with following
skeleton:

struct _Node {
  Base_Object base_object;
  Node *parent;
  Node *next;
}

struct _NodeClass {
  Base_Class base_class;
  void (* add_child) (Node *node, Node *child, Node *insertafter);
  void (* remove_child) (Node *node, Node *child);
}

So you can derive new grouping objects from any non-grouping one by 
implementing virtual methods.

> > 3. Events
> > Real canvas uses have to extend event system. To adress more needs, it
> > would be helpful, if:
> > 
> > a) You can pass events through - i.e. make they to propagate not only
> >    towards root of item tree, but also to underlying item, if topmost
> >    one is not interested
> 
> Yes, this would be nice.  Perhaps we should make the ::event() method be
> 
> 	typedef enum {
> 		HANDLED,
> 		PASS_UP,
> 		PASS_DOWN
> 	} EventPropagation;
> 
> 	EventPropagation ::event (item, event);
> 
> Or something like that?

Yes.
IMHO it means, that "event" has to be marshalled while traversing the 
tree, not from root level.

> Other things I wanted to have:
> 
> 1. Infinite items.  Items would have an IS_INFINITE flag.  Groups
>    would keep a number_of_infinite_children field.  When redrawing,
>    you would ignore the bounding box of groups or items that have this
>    flag set, and always call their ::redraw() methods.  This would
>    allow you to implement "background grid"-type items very easily.

How this is different from just having (practically) infinite BBOX?

> 2. Plenty of virtualization for the base Group item.  This is required
>    for cleanliness and it would make it much easier to proxy the
>    canvas over Bonobo without the fantastically broken hacks that we
>    have right now.
> 
> A derivation of (2) is that we could have groups whose children do not
> quite exist but are generated on the fly.  My canonical application
> for this is a music score editor; you could avoid having thousands of
> items and just generate them on the fly when you need them, because
> you already know their types and positions.

Hmmm - I cannot pretend I understand the design, but is sounds 
interesting. Other idea coming to my mind, is canvas-based text
editor, that does not have to have canvas items for thousands of
pages present all the time.

> A model/view canvas is a completely different can of worms and I am
> still not convinced that we want to do that.  I guess we can still
> make a point that the canvas is not your data model and beat people on
> the head if they don't agree :)

I'll join you in beating if you need help ;)

Best wishes,
Lauris