hi Colin; On 28 April 2011 23:38, Colin Walters <[email protected]> wrote: > On Wed, Apr 20, 2011 at 7:12 PM, Colin Walters <[email protected]> wrote: >> >> == Dynamic Languages in GNOME == >> >> One thing that's worth addressing though (again) is the question "do >> we need both Python and JavaScript?". The uptake of both seed and gjs >> has been relatively low; lower than Python at least for scripting >> GNOME apps. However, I think at least one the core reason for working >> on JavaScript remains that *we define the platform*. > > Actually I've been thinking about this more, and I am changing my > mind; if we don't have an immediate plan for making JavaScript more > compelling, and there's still active people maintaining Python, we > should be advertising the latter, and not the former. > > So here's what I propose (and I'm willing to write patches, but mostly > this is just marketing/messaging): > > * Officially mark both gjs and seed as experimental (this is the > reality as it is for 3.0 anyways) > * Drop all consumers of seed in GNOME 3.2; rewrite them (this is just > gnome-games/lightsoff?) using C/Vala/gtkmm/Python > * Remove /usr/bin/gjs > * Keep gnome-shell on gjs (but switch to using Spidermonkey 1.8.5, and > no - porting to Python would be a pointless waste of time at best) > > What does this mean about the JavaScript future? My take here is that > for 3.2 at least, we could move it more towards being an "embedding" > language, designed from the very start to be used in a split C/JS > role. Also, this allows us flexibility to evolve JavaScript and > return later with something more interesting. For example, a combined > WebKit-with-arbitrary-gnome-JavaScript that I've seen at least two > different attempts at. > > Thoughts?
with all due respect, I think this is a knee-jerk reaction, and an oversimplification of the issue. both gjs and seed have been in some way marked as "experimental" de facto, if not de jure: the fact that only gnome-games and shell have been written using them is in no way a testament to the widespread usage and adoption; quite the contrary. so, marking them both as experimental would achieve nothing, and surely it wouldn't achieve the goal of having a better support of JavaScript as a primary language for Gnome applications. I do agree that the situation is untenable: gjs is barely maintained, with patches bitrotting in bugzilla (e.g. support for array arguments); seed is a hodge-podge of web platform, unixy-platform and gnome-platform, with questionable design choices for the advanced features like sub-classing support, or missing features. setting them both to be experimental bindings would not make them developed any further - actually, it would probably be a surefire way to have them both killed, with nothing to replace them. part of the current situation is due to uncertainty: which one to target when embedding, which one to contribute to, which one to use to write apps. I think it has come time for the Gnome project to do what we are generally afraid to do, and that is: pick one side and stick with it. in your original email you identified Seed as the potential candidate because of the platform's general momentum towards WebKit and JSCore; let's pick Seed - or, at least, let's pick a subset of Seed that makes sense and remove the cruft, i.e. the unix-wrappers for the low-level platform and the sub-classing; let's do some profiling on the introspection-to-jscore layer to verify that there are no performance/memory usage issues; let's make the syntax as close as possible as the one in gjs for signal, property and boxed types handling. then we can add back some form of sub-classing, and eventually port gnome-shell to it. in the meantime, for embedding, we should definitely go back to alexl's idea of a GScript API in GIO, using extension points to avoid linking to JSCore for every app. I'm willing to help out in Seed and G-I to make this happen. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
