hi; On 15 August 2013 12:43, Zenaan Harkness <z...@freedbms.net> wrote:
>> 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. there are my notes: https://wiki.gnome.org/EmmanueleBassi?action=AttachFile&do=view&target=guadec-2013-future-in-the-past-notes.pdf which sadly don't follow exactly what I said because I couldn't read them while giving the talk (long story). I also have a bunch of wiki pages for Clutter: https://wiki.gnome.org/Clutter/Apocalypses https://wiki.gnome.org/Clutter/Future it should give you an overview of where Clutter is, and where it's going to be in the future. >>> 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... not really: it's more a collection of thoughts that I developed after examining the current state of Evas and EFL for work, a year ago. let's just say it left some scars, and this mailing list is *definitely* not the right place to rant about another project (especially one that I don't have any intent or desire to contribute to). >>> 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? I've met Carsten — as well as meeting with the Qt developers that worked on QGraphicsView and the Qt5 scene graph and rendering API. I've also looked extensively at the equivalent API in MacOS/iOS (CoreAnimation), Android, and Windows. if you actually look at the Clutter API you'll easily recognize concepts, terminology, and even API from all those implementations. creating a generic scene graph is not something worthwhile. there are other projects that try to achieve that — OpenSceneGraph comes to mind. generality and performance are pretty much at odds. also, all the platforms and libraries you suggested are neither using the GNOME base libraries or even the same language that GTK+ is written in. we definitely want to use all the core facilities provided by our core libraries, exactly like other projects want to do the same with their *own* core libraries; this would imply creating a generic, unoptimized, library with virtually no dependencies — as well as convincing other projects which already have their own solution to switch to ours. I've been working, both as a professional and as a hobbyist, in the free and open source software arena for too long to know that not only adding these requirements upfront is a guarantee for a dead project that will have barely produced a line of code in 6 months time, and that it is never going to work in the first place. what we can, and should do, is to work on making GTK and its API kick ass, for the people using GTK already and for the people that will use GTK in the future. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
