Re: Scene graphs in user interfaces

[Zenaan Harkness <zen freedbms net>]

On 8/15/13, Emmanuele Bassi <ebassi gmail com> wrote:
> On 15 August 2013 12:12, Zenaan Harkness <zen freedbms net> wrote:
..
> > 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.

Cool thanks. Are there any slides/transcript etc? I have a rural
dialup only at the moment, so probably can't dl a video.

> > 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.

Ah ok. Can you refer me/us who are not appraised of your thoughts, to
any links on the subject? I'm only interested in the technical side of
things...

> > 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.

Thanks for the feedback.

I am only a Java programmer, and have no experience either way outside
of Java's libraries. I am wondering - have you managed to catch up
with Carsten at any conference and talk design together?

Thanks again
Zenaan