Developer guide

This is a guide that may help developers who are new to huggle project. Before you decide to jump into huggle development, you should get yourself familiar with huggle, at least by installing it and running it.

Before you start writing Huggle code, make sure to read Coding style

In order to develop huggle you should understand C/C++, HTML and MediaWiki

TIP: Save yourself troubles with set up of development IDE for Huggle, and download our ready-to-go preinstalled VM which is preconfigured for Huggle development, see Portable development environment.

First of all you need to understand how to compile Huggle. It uses several 3rd libraries and modules that are all linked as git submodules, so make sure you always do a recursive clone. There are multiple guides based on your OS, see menu of this wiki for links. Once you can build huggle to a working binary, you should run it with parameter --help - that will show you some options that as a developer you would use very often, especially these 2:

• -v: increases verbosity, you want to start huggle with this option every time you are debugging it
• --qd: dump RAW traffic between mediawiki and huggle

Where to start

Huggle is a web browser (or sometimes called diff-browser). It's talking to MediaWiki through APIs using so called queries, there is a number of query types in huggle, they are all inherited from base type Query. Most often you will see instances of ApiQuery. The query objects make it very simple for developer to use API in order to asynchronously retrieve some data from a wiki, or they can be used to call simple arbitrary web-requests.

Garbage collector

There is a garbage collector in huggle called just GC. You may not need to directly interact with it, because it works fully automatically. It is able to manage all objects that are inherited from class Collectable. What is important to know is, that every object inherited from collectable should never be manually deleted. There are 3 types of memory objects in huggle:

• Unmanaged
• Unmanaged collectable
• Managed collectable

Unmanaged objects are always manually handled by a programer. If you create an instance of collectable, it may, or may not be (depending on its constructor) become managed.

Members of "developers" and users with permissions for direct push

It's generally not recommended to push directly to master branch, although it's a common practice. The reason why it's common practice is that there is only few active developers and thus it's sometimes impossible to review every pull request in reasonable amount of time in order to make the development swift and efficient.

That being said, if you are doing any change that is not trivial (modification of typos in text, localization, non-code files, readmes etc, minor code cleanups) you should create a separate branch and open a pull request for it, so that other project members have a chance to review it. Don't forget to request review.

If nobody pays attention to it, you can merge it yourself.