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
118
119
120
121
122
123
124
125
126
127
128
|
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd"
[
<!ENTITY % local.common.attrib "xmlns:xi CDATA #FIXED 'http://www.w3.org/2003/XInclude'">
<!ENTITY % gtkdocentities SYSTEM "xml/gtkdocentities.ent">
%gtkdocentities;
]>
<part id="intro">
<title>Introduction</title>
<para>
libgedit-tepl is a library that eases the development of text editors and
IDEs based on GTK. Tepl is the acronym for “Text editor product line”.
</para>
<para>
The libgedit-tepl library follows a product line approach, inspired by
<emphasis>Feature-Oriented Software Product Lines: Concepts and
Implementation</emphasis> (2013 - Apel, Batory, Kästner and Saake).
</para>
<para>
Instead of creating one general-purpose text editor or IDE with a plugin
system, the idea is to create several <emphasis>specialized</emphasis> text
editors. For example specialized for one programming language, or one
development platform, or a small group of related languages. By being
specialized, an application is potentially better at what it does. It
follows more closely the UNIX philosophy to “do only one thing but do it
well”. And it better follows the GNOME philosophy: writing applications that
Just Works; when a user opens the text editor for the first time, it should
work out-of-the-box, without the need to find, install and configure
plugins. Of course it still makes sense to develop one general-purpose text
editor for the languages not yet covered by specialized text editors.
</para>
<para>
Most of the features of the library are available as a toolkit, but the
interesting part of libgedit-tepl is that it contains also a framework (for
now without a plugin system). The goal of the framework is to provide
higher-level APIs, to be able to create a new text editor easily. An
application wanting to use libgedit-tepl is not forced to use the framework
in its entirety, it is possible to use just the toolkit parts. The library
is implemented this way to achieve maximum re-usability: the framework is
less re-usable because it makes some assumptions about the general
architecture of the application, but since the features are also available
with a lower-level API – as a toolkit – all text editors and IDEs
based on GTK and libgedit-gtksourceview (or even other types of
applications) should be able to benefit from the features implemented in
libgedit-tepl.
</para>
<para>
Initially, libgedit-tepl was created as an incubator for new GtkSourceView
features, but in practice the features remained in libgedit-tepl, because
libgedit-tepl is considered less stable for its APIs, and it's convenient to
iterate on the APIs with more freedom. Another reason is that renaming the
namespace of all symbols is difficult to do in C.
</para>
<refsect1>
<title>Boundary between libgedit-gtksourceview and libgedit-tepl</title>
<para>
For the framework part of libgedit-tepl (not the toolkit parts), there is
a somewhat clear boundary between libgedit-gtksourceview and
libgedit-tepl: the top-level object in libgedit-gtksourceview is the
<link linkend="GtkSourceView">GtkSourceView</link> widget (representing
only one view, or one file), while the GtkSourceView widget is at the
bottom of the containment hierarchy in the libgedit-tepl framework (it is
a “somewhat” clear boundary because there is also
<link linkend="TeplBuffer">TeplBuffer</link>, a subclass of
<link linkend="GtkSourceBuffer">GtkSourceBuffer</link>).
</para>
<para>
The top-level object in libgedit-tepl is
<link linkend="TeplApplication">TeplApplication</link>, representing the
whole application which can contain several windows, with each window
containing one or several GtkSourceView widgets (typically with a Tabbed
Document Interface).
</para>
<para>
So the libgedit-gtksourceview library is not aware that there can be
several files opened in the application, while the libgedit-tepl framework
has a complete view of the application with regards to the opened
files/tabs. It permits to implement higher-level APIs.
</para>
</refsect1>
<refsect1>
<title>API stability</title>
<para>
The API is now constantly <emphasis>unstable</emphasis>. The library
soname is adapted (if needed) for each release.
</para>
<para>
libgedit-tepl contains experimental APIs, sometimes even unfinished
features. API design is hard, it needs an iterative process. Instead of
being stuck for years with a non-optimal API, the libgedit-tepl developers
want to be able to break the API at any time, to iteratively improve it.
Sometimes we see possible improvements several years later.
</para>
<para>
The API breaks are documented in
<link linkend="api-breaks">this section</link>.
</para>
</refsect1>
<refsect1>
<title>GTK dependency</title>
<para>
libgedit-tepl &package_api_version; depends on GTK 3.
</para>
</refsect1>
<refsect1>
<title>pkg-config name</title>
<para>
For libgedit-tepl &package_api_version;, the pkg-config name is:
<code>libgedit-tepl-&package_api_version;</code>
</para>
</refsect1>
</part>
|
