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
|
GHEX HACKING GUIDE
==================
INTRODUCTION
------------
Welcome! By way of introduction, first let it be stated that we aim for the
GHex project to be as hacker-friendly as possible, especially for newcomers.
No suggestion or question is dumb, and everyone who puts forth a genuine effort
will be treated with utmost respect within this project.
Although GHex is part of the GNOME Extra Apps family, I adopt fully the GNOME
Code of Conduct, as well as the common-sense principle of "Be Excellent to
Each Other."
HOW TO BUILD FROM GIT
---------------------
First install the build dependencies (i.e. libraries that ghex uses).
If you're on Debian or Ubuntu you can install the build dependencies
of the distro packaged version of ghex using the command:
sudo apt-get build-dep ghex
If you're on Fedora, the equivalent command is:
sudo yum-builddep ghex
Other distributions have similar commands for their package managers.
Of course, there is no guarantee that the build dependencies of the
distro packaged version is the same as the git version, but in practice
the former gets you quite far and if not, autogen.sh will tell you
what is missing during the next step.
To configure and build the git version of ghex, run:
git clone git@gitlab.gnome.org:GNOME/ghex.git # Using SSH
git clone https://gitlab.gnome.org/GNOME/ghex.git # Using HTTPS
cd ghex
meson build
cd build
ninja-build
sudo ninja-build install
For instructions on how to prepare a patch, see:
https://wiki.gnome.org/Git/Developers#Contributing_patches
CODING STYLE
------------
We all have our relgious beliefs when it comes to coding styles. At the GHex
project, we are not uber-pedantic when it comes to these things, but I do
believe that consistency within a codebase is important. To that end, here are
some basic principles that apply:
- To the extent possible, let's keep our user interface defined in .ui files,
and reserve our C code for callbacks and things that C is actually good for,
like, you know, programming! In the GHex project, this mainly applies to new
UI features; pre-existing features that have been with GHex for a long time and
have been done programmatically can continue to be updated and ported to new
APIs as necessary.
* Tabs, not spaces. I prefer tab-shifts and shift-widths of 4, but that's the
beauty of tabs! You can define them to be whatever you want them to be!
* When it comes to function definitions, I prefer the usual GNOME/GTK style,
which is basically K&R style except with the return type on a separate line
from the function name and parameters.
* When it comes to if, etc. statements, I'm not super picky. I just want the
code to be as readable as possible. I prefer spaces between `if` and the
opening parenthesis.
* Keep a maximum of approximately 80 characters per line, please. I don't mind
going a bit over, but I don't have the best eyesight and tend to look at code
in vim with the source file in one column and the header in another, so keeping
things at 80 characters keeps things relatively readable in 2-column displays
without ugly wrapping.
* No mid-block declarations.
|
