forked from gregier/libpeas
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
100 lines (74 loc) · 4.33 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Introducing libpeas
===================
libpeas is a gobject-based plugins engine, and is targetted at giving every
application the chance to assume its own extensibility. It is currently used by
several Gnome applications like gedit and Totem.
It takes its roots in the old gedit plugins engine, and provides an extensive set
of features mirroring the desiderata of most of the applications providing an
extension framework.
Multiple extension points
-------------------------
One of the most frustrating limitations of the Gedit plugins engine was that it
only allows extending a single class, called GeditPlugin. With libpeas, this
limitation vanishes, and the application writer is now able to provide a set of
GInterfaces the plugin writer will be able to implement as his plugin requires.
On-demand programming language support
--------------------------------------
libpeas comes with a set of supported languages (currently, C, Python and
Javascript). Those languages are supported through “loaders” which are loaded
on demand. What it means is that you only pay for what you use: if you have no
Python plugin, the Python interpreter won't be loaded in memory. Of course, the
same goes for the C and for the Seed/JS loader.
Damn simple to use (or at least we try hard)
--------------------------------------------
Adding support for libpeas-enabled plugins in your own application is a matter
of minutes. You only have to create an instance of the plugins engine, and
call methods on the implementations of the various extension points. That's it,
no clock harmed.
A shared library for everyone
-----------------------------
As I noted earlier, the latest improvements of our beloved development platform
made it possible to create bindings for apps very quickly. And with the Gnome 3
announcement, this looked like the perfect timing to make the plugins engine
and its latest improvements available to everyone, with a library. Also,
hopefully it will reduce code duplication and allow bugs to be fixed at the
right place, once and for all, improving the quality of our applications.
As a member of the Gnome community and as an offspring of gedit, libpeas already
shares most of the Gnome infrastructure and philosophy:
* You can download the first release tarball on the Gnome FTP server.
* You can browse the source and contribute using our git repository.
* You can come and discuss with me and others on #libpeas (GimpNet)
* And you can report bug or propose new features through the good old Gnome
Bugzilla, against the libpeas module.
A few hints on using libpeas
============================
As always for the new projects, it can take some time to grasp all the
subtleties at first.
Plugins versus Extensions
-------------------------
Something that is going to puzzle most of the newcomers is the fact that the
libpeas API talks about both plugins and extensions, two terms that are usually
used interchangeably, but who have very different meanings in libpeas.
Let's try and give a definition of both of these words in this context:
- Plugin: In the context of libpeas, a plugin is a logical package. It's what
you will enable or disable from the UI, and at the end it is what the user
will see. An example of plugin for gedit would be the file browser plugin.
- Extension. An extension is an object which implements an interface
associated to an extension point. There can be several extensions in a single
plugin. Examples of extensions provided by the file browser plugin would be
the configuration dialog, the left panel pane and a completion provider for
file names.
Building libpeas
----------------
Building libpeas is quite straightforward. But as of today (8 jun 2010) you need
to be careful to build pygobject with the --enable-pygi option if you plan on
using the Python bindings capability, or you will experience weird bugs.
Sample code
-----------
The libpeas package contains a sample application called peas-demo, and sample
plugins written in C, Python and Javascript.
The global idea is this one: you create a new PeasEngine instance and give it
the information needed for it to find your plugins. Then you load some plugins
(you can use the PeasUIPluginManager for that purpose) and perform actions
through some PeasExtensions objects you can get from the engine.
Copied from http://log.istique.net/2010-06-03/announcing-libpeas.html