Developers Guide To Gummi¶
This information should assist if you want to get involved in the Gummi project itself or if you’re curious and want to learn more about the project
- Main Program Structure
- Packaging / Releasing
- Getting involved
Main Program Structure¶
It’s intended that the American English spelling is used as a standard on the website and in the program.
SVN/Subversion is used for source control, the repository is online at http://svn.midnightcoding.org/gummi
Building from SVN¶
There is a separate page for building Gummi from the latest development source.
Creating a Distribution package for Gummi¶
A dedicated page exists for assistance with this.
New features are only included in major releases such as 0.6.0 and 0.7.0 (second quadrant numbering).
Bugfix releases for those series are done with numbering in the third quadrant (0.6.1, 0.6.2, etc.).
We have the agreement that Alexander has the final say on which features are accepted, and which are rejected.
Features for a release will be chosen By Alexander based both on necessity of the feature and predicted time available to himself and the other developers, Dion and Wei-Ning.
Note that this is a warts and all description of the current state of play
Static Code Analysis¶
Some testing is done using Splint , but not currently in a structured manner.
Dynamic Code Analysis¶
Some occasional testing is done using Valgrind , but not currently in a structured manner.
Currently there is no regression testing, such as via unit tests.
It’s important that the features in the program work as described, to this end there is a functional testing plan to assist.
Currently, automated daily builds are not performed
The project depends upon your feedback for features requests, defects and other end user experiences. Do please get in touch if you have an issue.
Adding a New Language to Gummi¶
This process is documented on a dedicated page for the topic.
Adding a new color scheme to Gummi¶
Gummi uses the color schemes defined by GtkSourceView
We also use some fields that usually are not required, one is for highlighting search results in the editor, the other for lines that produce a compile error.
Testing is important as it improves the program quality and helps prevent issues being accidentally reintroduced with a new release.
- Can you program in C? If so, can you write unit tests?
- Or perhaps you are a Valgrind user, able to find and submit a patch for any issues found?
Not being able to write C does not make you non useful, here are some simple ways to assist:
- Are there misspellings on the website, wiki, or inside the program (such as in menu options)?
- Are there punctuation errors?
- Can you find examples of poor readability, and can you suggest how it might be rephrased?
- Can you see conflicting writing styles?