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
|
gedit development - getting started
===================================
The following explanations can be improved over time, if you see something
missing, a feedback is welcome.
Programming languages and paradigms
-----------------------------------
gedit is mostly written in C, with some plugins in Python or
[Vala](https://wiki.gnome.org/Projects/Vala/). The build system is in
[Meson](https://mesonbuild.com/).
The code is object-oriented and event-driven. In C, it's thanks to the use of
the GObject library (see next section). If you open some `*.c` or `*.h` files,
you may think “what is this horror?!” but – don't panic – it's just some
C/GObject boilerplate code, and that boilerplate can be generated by a tool. So
once you've learned GObject, you will no longer be afraid ;-)
Libraries used
--------------
As every GNOME application, gedit uses the GLib, GObject and GTK libraries. To
modify the gedit source code, you should be familiar with those libraries. See
the [GTK website](https://www.gtk.org/) and the document
[The GLib/GTK Development Platform – A Getting Started Guide](https://people.gnome.org/~swilmet/glib-gtk-book/).
The main widget used by gedit is GtkTextView, a general-purpose multiline text
editor. To learn that widget API, read the excellent
[GtkTextView tutorial](http://www.bravegnu.org/gtktext/) (a bit old but still
mostly valid). But GtkTextView is not enough for source code edition. gedit
actually uses the
[GtkSourceView](https://wiki.gnome.org/Projects/GtkSourceView) library, which
contains a subclass of GtkTextView with many features useful for a text editor
or an IDE. But GtkSourceView is not enough to have a full-blown text editor,
gedit is actually in the process of using more features from the
[Tepl](https://wiki.gnome.org/Projects/Tepl) library, and to further develop
Tepl alongside gedit.
For its plugin system, gedit uses the
[libpeas](https://wiki.gnome.org/Projects/Libpeas) library.
Plugins may have other dependencies, for example the spell-checking plugin uses
[gspell](https://wiki.gnome.org/Projects/gspell).
gedit architecture
------------------
The [gedit Git repository](https://gitlab.gnome.org/GNOME/gedit) contains the
_gedit core_ plus the default plugins. There is also the
[gedit-plugins Git repository](https://gitlab.gnome.org/GNOME/gedit-plugins)
for additional official plugins. The gedit core source code is in the `gedit/`
directory. The plugins are in … `plugins/`!
gedit core provides:
- A basic text editor.
- The integration of libpeas, with an API for plugins.
There is a class diagram of gedit core in the file
[class-diagram.dia](class-diagram.dia) (but it may be outdated, see the Git log
for that file).
Build/Installation
------------------
See the file [build.md](build.md).
First contribution
------------------
See the [Newcomers](https://wiki.gnome.org/Newcomers/) page to start
contributing to GNOME in general. But perhaps some things explained there are
not relevant for gedit, in case of doubt the gedit documentation takes
precedence.
To know how to contribute to gedit specifically, read the
[README.md](../README.md) and [CONTRIBUTING.md](../CONTRIBUTING.md) files
present in the Git repository (and then you'll see that the `CONTRIBUTING.md`
file refers to this file, but please don't end up in an infinite reading loop).
A good way to learn a lot of things is to write a new plugin (as a third-party
plugin first).
A potentially easy task (but not always) is to fix compilation warnings, for
example when a deprecated function is used. If you encounter a runtime warning
or critical message, it is also a good idea to fix it.
Improvements to the documentation (for users or developers) is also useful,
especially to improve the API reference for developing gedit plugins.
Note that gedit, although simple to use, is old. Some parts of the code is
legacy code. The remaining tasks to do are often not simple, the codebase needs
a lot of refactoring, and to do it properly an experienced developer is advised.
That's why writing plugins is normally easier.
Interesting article to read, written by a GNOME developer:
[Working on Free Software](http://ometer.com/hacking.html)
Happy hacking!\
the gedit developers.
|
