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? 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. 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