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
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
If you are the maintainer of an applet, feel free to commit - unless
we're very close to a release. In that case, contact us.
If you just want to hack, let us know. Most of the applets are
unmaintained, but you should try to contact the maintainer (or past
maintainer) before working on them, to avoid duplicate work and
stepping on any toes. If unsure, ask us about it.
The list of official maintainers is in the MAINTAINERS file. If you're
a MAINTAINER and you're not listed, contact one of the overall
maintainers to get yourself added. If you want to get bug reports for
GNOME-Applets you can add yourself to listen to the
gnome-applets-maint@bugzilla.gnome.org alias in your
preferences. Filter on X-Bugzilla-Component: if required.
Release planning for GNOME Applets is online at
http://live.gnome.org/GnomeApplets
We share a mailing list with GNOME Utilities, you can subscribe to
gnome-utils-list@gnome.org
Please attach your patches to a bug in http://bugzilla.gnome.org, either by
filing new bugs or attaching it to an old one.
Patches should be generated with `diff -uprN`.
If you are committing directly into the git repository, then follow
these guidelines for the commit message (see also ChangeLog.README):
The expected format for git commit messages is as follows:
=== begin example commit ===
Short explanation of the commit
Longer explanation explaining exactly what's changed, whether any
external or private interfaces changed, what bugs were fixed (with bug
tracker reference if applicable) and so forth. Be concise but not too brief.
=== end example commit ===
- Always add a brief description of the commit to the _first_ line of
the commit and terminate by two newlines (it will work without the
second newline, but that is not nice for the interfaces).
- First line (the brief description) must only be one sentence and
should start with a capital letter unless it starts with a lowercase
symbol or identifier. Don't use a trailing period either. Don't exceed
72 characters.
- The main description (the body) is normal prose and should use normal
punctuation and capital letters where appropriate. Normally, for patches
sent to a mailing list it's copied from there.
- When committing code on behalf of others use the --author option, e.g.
git commit -a --author "Joe Coder <joe@coder.org>" and --signoff.
- If the checkin is related to a bug, reference the bug number.
- Checkin comments MUST use the UTF-8 encoding.
- Avoid meaningless checkin comments such as "forgotten file" !
If you forget to check in some changes that belonged in the same
commit (e.g. you accidentally omitted a file), you must copy the
checkin comment from the previous, incomplete checkin, and
additionally reference that commit's svn revision number.
Some tips for hacking/debugging the applets:
1) The Panel Applet Writer's Reference Manual, including the
PanelApplet library documentation, can be found at
http://developer.gnome.org/doc/API/2.0/panel-applet/libpanel-applet.html,
or in gnome-panel/doc/reference/panel-applet (source). It is not
completely up to date, but it covers the basics of writing an
applet.
2) Look at the other applet implementations. One of the simpler
applets is the fish applet, which lives in
gnome-panel/applets/fish.
3) Read the article about debugging GNOME Applets at
http://www.davyd.id.au/articles/debugging-gnome-applets.shtml.
This article also contains a list of common considerations when
developing applets. Please, please read this article, it covers
everything you're likely to need to know. If you find anything is
missing, then contact the maintainers.
4) Be weary of static, global variables if you plan to allow the user
to be able to add multiple instances of the applet. Each instance
will share the static varible. This is described in the debugging
article, under "Other considerations".
5) You'd probably want to run the applets from git, without
nescessarily doing the same with all of GNOME. To do this, install
the applets from git to a different prefix than the rest of GNOME,
and change your bonobo servers directory to
$prefix/lib/bonobo/servers. You'll find the config file by running
"bonobo-activation-sysconf --config-file-path". Add the directory
to as an <item> at the top of <searchpath>. Log out, run
bonobo-slay and make sure no bonobo processes are running. When you
log in again, your applets should be running from the new prefix.
Running single applets from CVS is described further in Davyd's
debugging article.
6) Please make use of the global defines already provided for you,
rather then defining your own in your Makefile.am. Some useful
global defines are GNOME_ICONDIR, GNOME_PIXMAPSDIR,
GNOME_LOCALEDIR, GNOME_GLADEDIR, DATADIR, SYSCONFDIR, LIBDIR and
VERSION.
7) Attempt to use the Nautilus/GNOME-VFS coding style in
GNOME-Applets. Code should be neatly tabbed, with 8 character tabs,
and fit on an 80 character wide terminal. Ideally functions
(will_be_called (LIKE, THIS)); opening braces will be on a new line
and variables will be declared at the top of the block without
assignment, C89 style.
Davyd Madeley <davyd@madeley.id.au>
Kevin Vandersloot <kfv101 at psu dot edu>
Christoffer Olsen <co at deworks dot net>
|
