Re: Canvas shortcomings

[Owen Taylor <otaylor redhat com>]

Martin Sevior <msevior mccubbin ph unimelb edu au> writes:

> I conjecture that having one GtkObject per item would not yield sufficient
> speed for a WordProcessor where we're constantly reshuffling text all over
> the screen. Just imagine hitting delete on a line of Justified text that
> swallowed the following line. All the text following needs to be cleared
> and repainted. 

Well, you probably wouldn't use one-GObject-per-glyph chunking.  But
also you perhaps you misunderstood. A shape object is simply a more
complex equivalent to a GdkRectangle - a way of holding the definition
of a shape to draw on the screen.

I'm not talking about some complex system like GnomeCanvas with
virtualized rendering methods, transformations, etc.

Whether you can get away with using GObject for the shape object or
you have to use something simpler, I don't know. GObject creation is
pretty fast now, and certainly could be sped up even more.

> However I'm certainly open to counter examples that show it could be done.
> 
> Regarding the seperation between Model-View, I think what you really want
> is just an interface layer between an application specific model and a
> variety of rendering methods (GDK, PS whatever). The AbiWord project uses
> such a layer which allows arbitary rendering backends to be plugged into a
> consistent front end.
> 
> This is how we can support multiple Display systems (WIndows, QNX,
> gdk,...) and is also how we print. We just open a new view on the Model
> and render into a postscript or gnomeprint backend.
> 
> I also conjecture that doing this in C based API would be a challenge.

Not really.  

  You can look at GtkTextView / GtkTextBuffer.
  GtkTreeView / GtkListStore / GtkTreeStore
               
In GTK+ head, for just a few examples of doing model/view in C. But
this strays off of discussing a _rendering_ API, which has relevance
only to the view.

I think the concern is eventually having a consistent API for
different types of rendering - not because you can't program around
different interfaces - but primarily reduce the amount of learning for
and work for the programmer.

Learning how to program with GNOME shouldn't involve learning
the Xlib, Postscript, and libart rendering models.

Regards,
                                        Owen