Module proposal: Gjs



I'm having mail delivery from desktop-devel disabled, so please include
me in the cc.

Purpose:
 Gjs a language binding for Spidermonkey, the original JavaScript engine.
 It provides access to GObject based libraries such as Gtk+, Clutter and
 GStreamer though gobject-introspection and it also contains native bindings
 for cairo and dbus, Gjs is currently being used by GNOME Shell and that's
 why it's proposed here.

Target: Desktop Release Set

Dependencies:
 spidermonkey: JavaScript engine used by firefox & thunderbird.
 gobject-introspection: Will either be proposed as a desktop release
 set module or used as an external dependency
 cairo: already an external dependency
 dbus: ditto

Spidermonkey is a part of the xulrunner platform which is packaged by
most distributions shipping GNOME. In the current situation it means that
to be able to build Gjs on one of the distributions you would have to install
a large part of firefox. This is the main way Mozilla supports Spidermonkey as
there are no recent (~12 months) tarballs released, users of Spidermonkey are
encouraged to stick by a specific version by forking it. [citation needed]
In short-term Spidermonkey will depend on xulrunner, in the future it'll be made
to work on top of the occasional standalone tarballs released by Mozilla.

Resource usage:
 tarballs: http://ftp.gnome.org/pub/GNOME/sources/gjs/
 source control: git://git.gnome.org/gjs
 bugzilla: http://bugzilla.gnome.org, gjs product

Adoption:
 Gjs is a dependency of GNOME Shell for which packages exist for most
 major Linux distributions; since GNOME Shell has not yet had a stable release,
 no distribution is shipping it by default.

GNOME-ness, community:
 Gjs was originally developed by litl LLC for it's client user
interfaces, it has
 since been picked up by GNOME shell and is slowly being picked up by
 others. Development of Gjs happens openly and there has been 17 people
 commiting (8 outside of litl).

Other notes:
 Gjs vs Seed or in extensions Gecko/Xulrunner vs WebKit is not going be a
 productive discussion. Both seed and gjs has their strengths and merits.
 Gjs is a mature binding, which is used in production, shipped software
 (see http://litl.com), a refusal to accept Gjs would force the GNOME Shell
 team to rewrite its javascript parts to run on top of Seed would not be
 very productive at this point. I strongly encourage tempted list members
 to avoid that discussion for reasons mentioned above.

--
Johan Dahlin


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]