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
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
====== Files - Contribute ======
**This document is licensed under the LGPL 2.1.**
This document is based on the HACKING file from the Midori browser project.
====== Testing the latest build ======
Get daily builds in Launchpad (https://launchpad.net/~elementary-os/+archive/daily ppa:elementary-os/daily).
====== Join IRC chat rooms ======
Join #elementary-dev on Freenode: https://kiwiirc.com/client/irc.freenode.net/elementary-dev.
====== Contribute without touching code ======
- http://bugs.launchpad.net/pantheon-files Go through problem reports and check Unconfirmed bugs or those lacking information and mark any duplicates you spot.
- https://translations.launchpad.net/pantheon-files Help getting Files translated in your language!
====== Check out the sources ======
bzr branch lp:pantheon-files
The development **trunk** (master, tip) is the latest iteration of the next release.
Browse it online and look for other branches at http://code.launchpad.net/pantheon-files
====== Build the code ======
Refer to INSTALL for required dependencies.
Then:
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug
make
Run Files:
./src/pantheon-files
To run Files from a local branch, you will need to already have Files installed in your system, since configuration files and plugins are loaded from system directories.
If you'd like to install from your local branch:
sudo make install
====== Debugging issues ======
Testing an installed release may reveal crashers or memory corruption which require investigating from a local build and obtaining a stacktrace (backtrace, crash log).
gdb ./src/pantheon-files
run --debug
====== Coding style and quality ======
Be sure to check the official elementary Code Style guide at:
http://elementaryos.org/docs/code/code-style
Files' code should in general have:
* 4 space indentation, no tabs.
* Between 80 to 120 columns.
* Prefer /* */ style comments.
* Call variables //animal// and //animal_shelter// instead of <del>camelCase</del>.
* Keep a space between functions/ keywords and round parentheses.
For Vala:
* Prefer //new Gtk.Widget ()// over //using Gtk; new Widget ()//
* No necessity to prefix anything from the GLib namespace. An exception to this rule is when using GOF.File and GLib.File in the same source file.
* Stick to standard Vala-style curly parentheses on the same line
* Cuddled //} else {// and //} catch (Error error) {//
For C:
* Always keep { and } on their own line.
====== Important: Keep fixes for different bugs in different branches ======
Branches that contain patches to fix more than one bug will be rejected, and you will be asked to supply a separate branch for every bug fix.
This doesn't apply to patches that are indivisible by nature, and that fix multiple bugs.
The reasons to work in this way are the following:
* If one of the bugs targeted by your branch is correctly fixed, but one of the other bugs is incorrectly fixed or needs corrections, the branch won't be accepted until everything looks ok for all bugs. This causes an unnecessary delay for the bugs that where fixed correctly.
* Suppose your branch was accepted for merging in the main one. Later, it is discovered that your branch introduces faulty behavior. The standard course of action for these situations is to revert the merge that introduced that faulty behavior. This will cause that all of your fixes are reverted (even the ones that didn't cause problems) because there was no way of discriminating between them. If a separate branch for each bug fixed existed, only the offending one would have been reverted, and not all of them.
Be sure to understand this, and avoid a headache later!
====== Committing code ======
Make a branch which will contain your changes for fixing bug XXXX:
bzr branch lp:pantheon-files fix-XXXX
Tell Bazaar your name if you haven't yet:
bzr whoami "Real Name <email@address>"
See what you did so far:
bzr diff
bzr diff | colordiff
Get an overview of changed and new files:
bzr status
Add new files, move/ rename or delete:
bzr add FILENAME
bzr mv OLDFILE NEWFILE
bzr rm FILENAME
After making your changes, you need to commit your work as a new revision.
bzr commit -m "Commit message"
Commit your changes in small increments. It is better to keep different changes in different commits.
To see the last 5 revisions in the current branch:
bzr log -l5
bzr log -l5 -p | less
In the case you committed something wrong or want to ammend it:
bzr uncommit
If you want to revert all the changes made after the last revision:
bzr revert
Remember to keep your branch updated:
bzr pull
As a general rule of thumb, ''bzr help COMMAND'' gives you an explanation of any command and ''bzr help commands'' lists all available commands.
//If you're a die-hard git user, http://zyga.github.io/git-lp/ checkout git-lp to use git commands with the Bazaar repository.//
====== Push proposed changes ======
If you haven't yet, https://launchpad.net/~/+editsshkeys check that Launchpad has your SSH key - you can create an SSH key with **Passwords and Keys** aka **Seahorse** or ''ssh-keygen -t rsa'' - and use ''bzr launchpad-login'' to make youself known to bzr locally.
If you checked out trunk, and added your patch(es), just **push it under your username** in Launchpad and you can **propose it for merging into trunk**. This will automatically request a **review from other developers** who can then comment on it and provide feedback.
bzr push lp:~USERNAME/pantheon-files/fix-123456
bzr lp-open
The last command will open a summary of the current branch in your web browser. There, you will be able to propose it for merging into trunk.
Your branch will be reviewed by another developer. At this stage, you may be notified that changes need to be made to your branch, so keep an eye on your email inbox!
After the branch is approved by the reviewer, it will get merged into the main project's source code.
**What happens to all the branches?**
Leave the branches alone, **approved branches are cleared automatically** by Launchpad.
For larger feature branches, **use the team** in Launchpad to allow other developers to work on the code with you.
What if I want to help out on an **existing merge request** that I can't push to?
bzr branch ~OTHERPERSON/pantheon-files/fix-123456
cd fix-123456
# make commits
bzr push lp:USERNAME~/midori/fix-123456
bzr lp-open
And in the Launchpad web overview of your branch, propose your branch for merging into ~OTHERPERSON/pantheon-files/fix-123456
Updating a branch that may be out of sync with trunk:
bzr pull
bzr: ERROR: These branches have diverged
bzr merge lp:pantheon-files
# Hand-edit conflicting changes
bzr resolve FILENAME
# If any conflicts remain continue fixing
bzr commit -m 'Merge changes from lp:pantheon-files'
Save a little bandwidth, **branch from an existing local copy** that you keep around:
bzr branch lp:pantheon-files pantheon-files
bzr branch pantheon-files files-fix-123456
cd files-fix-123456
bzr pull lp:pantheon-files
|