Re: Scene graphs in user interfaces

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 15 August 2013 12:12, Zenaan Harkness <zen freedbms net> wrote:
> Hi, I just read the recent 2013-08-14 LWN article:
> http://lwn.net/Articles/562856/
> in particular regarding Clutter, a scene-graph canvas, and the calls
> over the years to merge Clutter with GTK.
>
> This motivated me to read the linked wikipedia page:
> http://en.wikipedia.org/wiki/Scene_graph
>
> and, in particular, to add the section "Scene graphs in user interfaces":
> http://en.wikipedia.org/wiki/Scene_graph#Scene_graphs_in_user_interfaces
> which is currently primarily a list of various canvas libraries.
>
> My hope is to raise awareness of the alternatives, to make it easy for
> future canvas and UI scene-graph hackers to appraise themselves of
> what's already available.

we already have a fairly well understood set of requirements for
adding a scene graph API in GTK.

my suggestion is to download and watch my GUADEC talk about the topic:

  http://www.superlectures.com/guadec2013/future-in-the-past-designing-and-implementing-the-gtk-scene-graph

if you can get past my annoying voice, I detail the constraints and
design tenets for the scene graph API work that I'm currently doing.

> Of note to my mind is Evas:
> http://docs.enlightenment.org/auto/evas/
>
> which appears surprisingly simple in its API, yet enough for UI
> building, and is a scene-graph with all sorts of benefits that
> entails, and given the design decisions made with Evas in particular.

my thoughts on the overall design and implementation quality of Evas
(and the overall EFL set) are probably well known, so I won't comment
on that.

> I hope the starting list of canvas's at wikipedia is useful. Dunno if
> there's an appropriate QT -dev list to forward this email to, or if
> there might be some cross-project mutual interest between qt/gtk/evas.

a scene graph API is pretty much integral to how a toolkit is
developed and implemented. trade-offs are made, as well as design
decisions, based on the existing code base — especially since the
general idea is to *not* break API. I don't foresee any chance of
collaboration, here.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/