Re: 3.2: gjs/seed

["alan akbkhome com" <alan akbkhome com>]

While a little biased, I'd rather there was a plan to keep Javascript in 
Gnome front and center...

I did think the plan of Introspection was to be able to say to Gnome 
users, "You want to customise application X", pick _your_ favourite 
language, it's _your_ choice..., rather than getting into a 'this 
language is better...' story that tends to put people off. More of an 
Inclusive community concept I guess..

Seed on Gtk3 should be usable, Most of the issues I had with maintaining 
applications written using it are around the changing Gtk API and 
introspection changes, which I presume python & gjs all suffer from now. 
(It would be nice if introspection had a mailing list rather than IRC to 
follow and/or follow up discussions...)

From a maintenance / development point of view Seed is 'maintained' 
(eg. bug reports and patches tend to be responded to or applied), 
however there is little active development (fixing hard problems etc.).. 
Could have been a good SoC project..

Python is always going to be stronger  as it has a longer history in 
gnome (unfortunately as some people like me really do not enjoy using 
it), It will also take a long time for JS to gain as much ground, and 
any sense that the door is closing is not really going to help.

I watched my son last night experimenting with Javascript on a web-page 
with chrome and komodo for his first programming, it was all javascript, 
as it's accessible on any platform. While some of us grew up with 
assembler and BBC basic, as that was all that was available, todays 
generation are more likely to have toyed with javascript first. These 
are hopefully the type of people that will eventually drive Gnome in the 
future and I'd be keen to see the barrier of entry kept as low as 
possible for them..

Anyway my 2c on that.

Regards
Alan



On 04/29/11 07:03, Emmanuele Bassi wrote:
> hi Colin;
>
> 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
> > > 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.