Re: GTK+ canvas?

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

Qua, 2006-08-30 �16:17 -0400, Havoc Pennington escreveu:
> Hi,
> 
> I posted some sort of blue-sky canvas ideas a year ago:
> http://mail.gnome.org/archives/gtk-devel-list/2005-August/msg00067.html
> 
> 
> Since then I've learned HTML/CSS much more thoroughly and also used 
> Flash a bit. And in the last week needed to write a canvas in 2-3 days 
> to use for Mugshot. Which is maybe interesting as a case study - "if you 
> had to strongly prioritize features since you only have 2-3 days, what 
> would be really important for a real-world application"
> 
> The code is here:
> http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-canvas-item.c
> http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-canvas.c
> http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-canvas-box.c
> http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-canvas-text.c
> 
> Remember, written in a few days for a single app; not intended to become 
> a maintained library API. The HippoCanvasBox is the base class for all 
> the items, i.e. all items are containers.

  It seems this HippoCanvas has no model-view split, yet I remember you
designed GtkTextBuffer/View with model/view.  Do you consider model-view
unimportant, or simply just got "prioritized away"?

  IMHO, and from experience with coding in GooCanvas, dealing with
model-view split adds much complexity with very little gain.  How often
do you see or use e.g. the model-view split of GtkTextBuffer being used
by an application?  And doing layout with MVC is cumbersome; e.g. in
case of GooCanvas, doing layout with text items is hard and weird: you
store the position in the model, but you need the view in order to get
the size that item; but from the moment you need the view for anything,
which view do you choose?  Effectively you lose the model-view
separation... but you just have to get the job done, so you eventually
stop caring about model-view.

  In any case, it's still possible to do multiple views on top of a
single-view canvas, even if it wastes more memory.  However, I would
argue that to display a very large document in a canvas creating a
canvas item for each document item is not the best solution; I'd rather
have a pool, or cache, of visible canvas items, and just reconfigure
them on the fly to show the portion of the document currently visible.

> 
> Thoughts since last "canvas notes"
> ===
> 
> - I think an important thing to keep in mind is that a canvas is just an 
> alternate widget system.

  Yeah, kind of agree.

> - Along the same lines you can also think of a canvas as an alternative 
> to Flash or HTML/CSS, two systems many programmers will be familiar with.

  Don't agree so much.  I would say that an HTML widget could be built
on top of a canvas, but a canvas IMHO should be something lower level
than HTML (can't comment about Flash).

> - This poses a huge question for a canvas in GTK, namely, how much does 
> it overlap widgets; if I'm writing an app, when do I use the canvas vs. 
> widgets; exactly what is the scope of a canvas project; etc.

  There is some overlap.  A canvas system, if done right, could lay the
foundation for a next-generation widget system.

> - My opinion is that the canvas should "replace" the GTK core in a way, 
> i.e. GtkWidget becomes a specialized thing you can embed in a canvas.
> This obviously makes the canvas into a pretty big project.

  Sounds an interesting idea...

> 
> - In fact a useful bit of discipline might be that gtkwidget.h does not 
> get #include'd by the canvas item implementations. (except the canvas 
> item that embeds a widget)
> 
> Notes on how the Mugshot canvas worked out so far
> ===
> 
[...]
> - canvas items always see only their own coordinates (what gnomecanvas 
> called "item coordinates"), this removes a _lot_ of confusion that 
> GnomeCanvas had - unlike GtkAllocation, this means the canvas item only 
> needs to store its allocated size, not its allocated origin. Cairo makes 
> this possible since drawing doesn't require converting to drawable 
> coords (the cairo_t can have its translation matrix already set up)

  It works this way in GooCanvas.

> - GnomeCanvas wouldn't have helped much if at all with cleaning up 
> hippo-bubble.c, because the disaster is all the custom layout code. So, 
> the canvas should support layout.

  GooCanvas doesn't have layout yet, but Damon mentioned some plans
about this.


> - I think making CanvasItem an interface worked very well, I haven't 
> looked at GooCanvas but I see its website says it does the same.

  It's true.  Item and ItemView are two interfaces.

> - the image item is able to tile, which is a common way to draw e.g. the 
> edge of a box in html

  So true.

> - typing in C is definitely worse than HTML

  Try Python! ;-)

> , so having a markup language 
> as an integral part of a canvas design is of interest.

  Markup in the text item sounds fine.  Anything else sounds like
reinventing HTML.

> I think the biggest question about a canvas in gtk in my mind really is 
> this thing about "how far to go" - how do you define the thing, both in 
> absolute terms, and relative to the core gtkwidget/gtkcontainer stuff.

  IMHO a canvas in gtk+ should not go too far.  I'm not saying an HTML
widget would not be good to have in gtk+, but HTML/CSS and canvas are
two separate things; HTML/CSS can be built on top of a canvas, in
principle.

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic