Re: GtkCanvas requirements?

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

On S� 2007-04-21 at 17:09 -0400, Havoc Pennington wrote:
[...]
> So another structure could be that there's a "core" which tries to 
> encapsulate the minimum amount of structure for multiple objects to 
> negotiate their usage of the screen area and keyboard, and then there 
> are objects that layer in more widget-like and more svg/flash-like 
> behaviors. Don't know exactly how that would work.

  I agree that a layered solution is the way to go.  The layers I
envision are along these lines:

  1- An immediate mode drawing layer: we have this now, it is called
Cairo;

  2- A retained mode drawing layer: a bunch of "objects" that know how
to paint themselves, and when pointer or keyboard events belong to them.
GooCanvas is one example of such a layer (except that it also does stuff
like animations which I don't think belong in this layer).

  3- Then we can have a bunch of modules on top of layer-2:
    3a- animations;
    3b- object drag-and-drop;
    3c- markup language, scripting, SVG, etc.

> 
> Federico also brings up again the great point that the whole thing 
> should perhaps be designed for primarily markup, plus some scripting, 
> rather than primarily as a programming API.
> 
> Maybe the as-lightweight-as-possible "core" has some ideas like:
>   - the whole display is a DOM-like tree, loadable from markup
>   - item painting
>   - keyboard focus
>   - ...

  Yes, I agree with this view, except that I hope you mean DOM-like tree
is just a programmatic object tree, like gtk widgets, not XML.  I think
glade/libglade/gtk clearly have proved to us that you can perfectly
layer XML on top of a core library.

> 
> Then add a set of "widget" style items built on the core which have:
>   - layout management
>   - themes
>   - keyboard accelerators/mnemonics
>   - ...
> 
> And have a set of "SVG" items (could just be SVG embedded in the overall 
> markup), used for drawing and animations.
> 
> Just brainstorming on how to break down the big picture enough to get a 
> handle on it...

  This is all very nice except that I believe that for now we should
focus on only "layer-2" for inclusion in Gtk+, and only time will tell
how many layer-3+ modules belong in Gtk+, or how much of that is
application-specific.  But even if it belongs in Gtk+, I believe a clear
separation of the layers 2 and 3 is crucial.

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