Re: 3.2: gjs/seed

["jose aliste gmail com" <jose aliste gmail com>]

Hi,


On Thu, Apr 21, 2011 at 1:12 AM, Colin Walters <walters verbum org> wrote:
> Hi,
>
> So speaking as someone who was motivated to make writing GNOME apps
> easier, I'm not very happy with how things turned out with the mix of
> gjs/seed/python/introspection/gtk3.
>
> In this mail I just want to focus on the gjs/seed situation.  Before
> 3.0 we chose to use gjs for gnome-shell for a variety of reasons:
>
> 1) gjs existed
> 2) seed didn't
> 3) Litl contributed a number of engineers to gjs
> 4) While I know some GNOME contributors here don't like Mozilla, in
> the big picture their mission and culture is *MUCH* more aligned with
> ours than Apple, at least
> 5) The Spidermonkey-specific JavaScript extensions like "const" and
> "let" were useful and cool
> 6) Many GNOME consumers actually ship Firefox and not Epiphany, and so
> we were technically aligned on that end (yes, this is the "GNOME is a
> bucket of parts" mindset, which I would really like to fix, but that's
> a separate issue)
>
> But let me cut to the chase and say that I think we'd at least
> consider realigning on seed for 3.2 for gnome-shell (and by extension,
> mark gjs as deprecated at least in GNOME).
>
> There are, however, nontrivial issues.  First is that actually in good
> news on the gjs front, a standalone Spidermonkey release was just made
> recently, and I have a patch ready to use it in gjs:
> https://bugzilla.gnome.org/show_bug.cgi?id=646369
> In contrast though, /usr/bin/seed appears to actually link to WebKit,
> which would be a painful dependency to have for gnome-shell, since
> it'd be insane to try using it inside the compositor process.  This
> may (hopefully) be fixable.
>
> Even tougher would be unwinding the Spidermonkey let/const and
> generator usage inside gnome-shell, but we dug the hole, we can dig it
> out.
>
> That covers reasons 1,2 and 5.  As far as reason 3), they're not as
> active anymore (probably gjs basically works for them), and for 6) I
> think we need to change this anyways.  This leaves reason 4) which I
> admit is just a feeling.
>
> So - seed/gjs contributors - what do you think?

>From my personal (developer using seed) point of view, I think the
important point is to have one blessed javascript-gi glue. I am using
Seed to add Javascript support to Evince, so it would be good to know
that Seed is going to be revamped or deprecated so I can use gjs
instead.

>
> One thing I'm not totally happy with is the organic growth in API in
> both seed and gjs.  seed for example added an "os" module with e.g.
> "fork" which I think is totally wrong; it's just broken to fork() a
> GNOME app, since it conflicts with threads, etc.  If we're going to do
> some unification, we should also prune a lot of cruft.  If there are
> bits missing from GNOME (like GIO is really missing both Console and
> Process classes), we need to add them.
>
> == 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*.  Python comes
> with a vast API, a lot of it really old and crufty, but even more
> importantly, large parts of it are *wrong* to use in GNOME.
>
> For example, we don't want people to use Python's mostly-POSIX-like
> wrappers for IO, we want people to use GIO, so it doesn't block the
> mainloop.  We don't want people to use Python's "webbrowser" module,
> its "multiprocessing" module (which totally breaks things like X and
> DBus since it uses a bare fork()), etc.
I understand your point, but I don't think this implies that we don't
(at  least for me) python. What we really need IMO is good
documentation on how to write good Python Gnome Apps, by pointing out
the recommendations,  like, use GIO instead of python IO, etc. The dev
is free to mix code in weird ways, no?


>
> On the other side of the coin though, I think we largely failed to
> make JavaScript a compelling way to write apps.  The language is only
> a part of the question, and it's really not a large one.  We need to
> focus more on a build/deploy story, and less on /usr/bin/gjs.  By
> "build" I mean we really shouldn't be leaving it up to app authors to
> figure out how to use Automake with gjs/seed and to do
> "imports.gi.Gtk".  Deploy is another story.
>
> The other reasons:
>  * ecosystem: The industry adoption is reflected in all the work that
> goes into JIT compilers, as well as people simply learning the
> language
>  * Better engine internals - the global interpreter lock in cPython
> really hurts it as far as a future in a multicore world
>
> (No, unlike what you've read in some parts of the internets, a reason
> to add JavaScript wasn't to attract "web developers" explicitly; but
> they are part of the industry)
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>