New module proposal: libpeas
- From: Steve Frécinaux <nudrema gmail com>
- To: GNOME Desktop Developers Mailing List <desktop-devel-list gnome org>
- Cc: libpeas-list gnome org
- Subject: New module proposal: libpeas
- Date: Mon, 04 Oct 2010 13:10:36 +0200
Hello Gnomers,
I'd like to propose libpeas as part of the desktop release set, or
whatever the release team cooked to replace it in Gnome 3.0.
libpeas is a library targetted at native applications in Gnome and
allowing them to easily provide extensibility through either a C GModule
or gobject-introspection-based bindings (currently, either pygi or
seed). It is meant to replace the old Gedit Plugins Engine which got
copy-and-pasted in too many applications.
Dependencies:
-------------
Libpeas currently depends on the latest gtk+ of the 3.0 branch, and on
gobject-introspection 0.9.6. It optionally depends on pygobject 2.20
(for python support) and seed 2.28 (for javascript support).
That's all.
Adoption:
---------
As of today, libpeas is used in several applications already member of
the release set in their master branch, to be used in Gnome 3.0:
- totem
- gedit
- vinagre
- nautilus-sendto
Several other maintainers have expressed their interest in using libpeas.
GNOME-ness:
-----------
Libpeas comes from gedit, and uses the gnome infrastructure (bugzilla,
git, ftp, irc, mailing-list) since the very beginning.
We express ourselves in a clean GObject-based API and provide a separate
library for Gtk+ 3.0 integration.
3.0 readiness:
--------------
Relevant because many apps plan to use libpeas for 3.0 in order to make
their own codebase simpler.
Having a single library also makes it easier to integrate with other
tools, such as an eventual addons.gnome.org website.
We only use the latest Gnome libraries available, so we build fine using
the latest GLib, Gtk+ and gobject-introspection.
License:
--------
LGPL 2.1+ for all the code base.
API/ABI stability.
------------------
I think most of the API work is done now and from now on I hope being
able to provide additional features without breaking the C API for
applications.
Python and seed binding stability is bound to gobject-introspection and
respective bindings so I cannot make any promise yet for those.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]