Re: canvas notes

Le lundi 15 ao�05 �2:38 -0400, Havoc Pennington a �it :
> Hi,
> Been thinking about canvas widgets a little this weekend, thought I'd
> write down some notes. Some people are doubtless way ahead of me.
> This isn't very organized. Summary of this mail is that GnomeCanvas was
> missing some very useful features a canvas can have, so I was
> underestimating the value of a canvas widget.
> Among other things I've been looking at scene graph APIs, specifically
> Piccolo (a 2D scene graph using Java2D):
> and Java3D:
> Piccolo is BSD-license. Java3D be careful with since it has a
> noncommercial use license, I avoided looking at source code or Sun 
> specs.
> There's Avalon also I suppose but I haven't read recent things about it.
> I see Piccolo was cited here:
> So random thoughts.
> 1. 2D vs. 3D (Cairo vs. GL) seems like a tricky question
>    that we also face on the compositing manager level.
>    Do we want two entirely different scene graph APIs
>    for this? Or one grand unified scheme where you can 
>    put Cairo-on-Glitz into flat portions of the 3D graph?
>    Possibility: a hybrid approach which is an OpenGL scene
>    but designed for a mostly-2D desktop UI. i.e. a not-very-rich 3D 
>    API, and convenience weighted toward 2D. Not sure what this
>    means.
> 2. Animations. Scene graph APIs make it simple to say 
>    "this object should move back and forth" or whatever. They have 
>    built-in stock animations such as animated affine transforms
>    (translation, shrinking, etc.) Very useful for smoother 
>    and snazzier UIs.
> 3. Behaviors. It should be trivial to implement "object is 
>    draggable by mouse" for example without writing your 
>    own event handler.
> 4. Widget embedding. Absolutely critical to using the canvas
>    for real-world UI. The widget embedding can't be broken 
>    as in GnomeCanvas or it isn't useful; layering and events must work 
>    properly. Affine transforms probably should work properly, and 
>    when you think about animations (minimization, etc.) could even be 
>    useful.
> 5. Multiple views. Sometimes useful, needs to be designed-in. 
>    Should probably be item-by-item rather than for an entire
>    tree of items...
>    Multiple views means that you can have 1-1 mapping from 
>    application data objects to canvas nodes.
> 6. Path item. In C at least it's easier to do this:
>      path = path_item_new();
>      cairo_t* state = path_item_get_cairo();
>      cairo_line_to(state, ...);
>      cairo_line_to(state, ...);
>    Than to create piles of Line items. Also, piles of 
>    Line items won't get the joins right and won't be as 
>    efficient.
> 7. Usable for a compositing manager. This should not really 
>    be very hard, I don't think.
> 8. Data/markup form of the graph; with a GUI editor usable 
>    by an artist.
> 9. Layouts. Parent nodes should have "layout policies" that can 
>    be applied to their child nodes (stack, tile, springs-and-struts, 
>    hbox, whatever).
> The basic idea here would be to make high-quality custom displays much
> easier to implement. One kind of custom display is the
> window/compositing manager; another is the "middle" of most main
> application windows (whether presentation app, UI builder, graphing
> calculator, or whatever it is); another might be panel applets or
> gdesklets-style thingies.

All these ideas are interesting IMHO. I'd add at least printing and svg
export for 2D items (hopefully cairo will help).

Now, the main point is that we need to rewrite a canvas widget since the
current one will be soon deprecated. Now that gtk+-2.8.0 is available, I
feel it is time to start working on it and avoid to depend on both cairo
and libart, cairo is enough.
I am willing to participate with my modest competencies. Anyway, I need
a functional canvas for my app (GChemPaint).

Hope others will join ;-)

Best regards,
Jean Br�rt <jean brefort normalesup org>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]