Re: 3.2: gjs/seed
- From: Emmanuele Bassi <ebassi gmail com>
- To: Colin Walters <walters verbum org>
- Cc: johan gnome org, GNOME Desktop Developers Mailing List <desktop-devel-list gnome org>, alan akbkhome com
- Subject: Re: 3.2: gjs/seed
- Date: Fri, 29 Apr 2011 00:03:48 +0100
On 28 April 2011 23:38, Colin Walters <walters verbum org> wrote:
> On Wed, Apr 20, 2011 at 7:12 PM, Colin Walters <walters verbum org> wrote:
>> == Dynamic Languages in GNOME ==
>> One thing that's worth addressing though (again) is the question "do
>> has been relatively low; lower than Python at least for scripting
>> GNOME apps. However, I think at least one the core reason for working
> Actually I've been thinking about this more, and I am changing my
> 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)
> 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
> return later with something more interesting. For example, a combined
> different attempts at.
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
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
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.
] [Thread Prev