Participate

Gwyddion needs your help, most badly in the following areas:

• Microsoft Windows
• Mac OS X
• Packaging
• User documentation writing and correction
• File formats (a separate page)
• Translation

The above list contains things the current developers lack resources or talents to do properly or at all. Of course, there is a lot of more ways you can help:

• use and propagate Gwyddion
• report bugs, and generally send us your comments or wishes (see Communicate)
• port Gwyddion to more systems and/or package it for them (see Porting)
• write new data processing modules and tools (see Developers)
• anything else that you are interested in: hacking the core, performing usability studies, improving the means of communication, maintaining Web resources, …

Developers

If you want to develop Gwyddion, it is probably easiest to start start with some simple module (see module tutorial), to become acquainted with it. Modules are relatively self-contained pieces of code and there are already lots of modules in Gwyddion, usable as examples. Of course, you do not have to limit yourself to modules and start hacking whatever pleases you.

See also Developer documentation index for library API and other relevant documentation.

If you write a module or plug-in, you are encouraged to share it here with other Gwyddion users. Please, let us know, so that we can link it here or include in it Gwyddion. If the module works, does something useful, is distributable (read: legally under GNU GPL), and is not platform-dependent, the chance of inclusion is great.

Gwyddion Subversion repository is public (read-only). Write access is considered and granted individually based on previous work.

Porting

Generally, if you manage to compile Gtk+ on the target platform, Gwyddion should work too. If it does not, it is a bug and report it to Yeti.

The current version should be 64bit-clean, endian-clean, etc. There are two known portability issues (beside insufficient testing):

Shared libraries

Since modules are shared/dynamically loaded libraries, a decent support for shared libraries is required. Particularly, the platform must be supported by both GNU libtool used to build modules, and by GModule used to load them run-time.

Floating point support

For one, Gwyddion requires the standard IEEE 754 floating point numbers (both single and double precision). In principle, it can be worked around but it may not worth the amount of work – nowadays when the IEEE standard is really a standard. Second, Gwyddion is a very FPU-intensive application as it performs practically all calculations in double precision. On systems with weak FPU, the performance is likely to be terrible.

Microsoft Windows

While MS Windows is popular among users, none of the regular developers uses it much (if at all) or understands it, leaving aside developing Gwyddion there.

Moreover, all other supported systems are Unix systems, therefore things that work everywhere else might break or work differently on MS Windows. The MS Windows build system was hacked together by Yeti with the intent to generate everything automatically from Unix makefiles and forget it. The resulting build process is alien to both Unix and MS Windows people.

Consequently, the integration is poor. Features such a thumbnail previews outside Gwyddion are, of course, missing. The Python interface does not work properly and no one knows why. You name it.

This is not going to improve unless you make it improve.

Mac OS X

Gwyddion works on Mac OS X, its packages are available, supported and regularly updated. Still, features such as automatic thumbnail previews outside Gwyddion, integrating the program better to the system, are missing.

Packaging

Gwyddion packages are available in many Linux distributions. However, for political reasons a Fedora package is missing, even though Gwyddion is developed almost exclusively on Fedora.

User documentation

The user guide desperately needs attention from someone who actually speaks English. It is not very complete either, though this part is probably much harder for a non-developer to fix.

Translation

Gwyddion user interface is translatable since version 1.6. If you have an experience with gettext translations, grab po/gwyddion.pot from source code tarballs (Alternatively, you can start from head gwyddion.pot), rename it to your_lang.po, and you can start translating. Please use UTF-8 encoding.

If you do not have any experience with localization, please read gettext manual for some background, namely PO File Format and Translator's View (thought this one talks much about GNU software translations that may not be relevant to Gwyddion). The translation file format is quite simple and can be edited with any text editor, although specialized tools like poedit exist too.

You can also look at existing translations. Then grab po/gwyddion.pot…

Once you have something, send it to yeti. You do not have to translate everything at once, even a partial translation is better than nothing.

To directly test your translation (definitely recommended), you need to compile Gwyddion from source code and have a working gettext. To update installed translations after you changed your PO file, run

make update-gmo install

in po subdirectory. Note this only works on Unix and the translation has to be added to the build system first (i.e., it does not work for fresh translations). Alternatively, you can bypass the build system altogether and run

msgfmt -c -o your_lang.mo your_lang.po

then copy thus created MO file where it belongs manually. Specialized PO editors may be able to run msgfmt themselves.

If you find parts of user interface that are impossible to translate due to missing marking (i.e., the text strings are not present in gwyddion.pot at all), or because they force English sentence structure or depend on English homographs, please report them as bugs.

Translation statistics of current development version are available on-line.