You can help development by contributing translated texts. The gettext system is not used in Tux Commander, though it would be certainly beneficent for translators if it was. Volunteers for porting are welcome, I myself would like to focus on other, more important areas. Porting to gettext won't be easy, not sure if it's possible to easily automate strings extraction from Pascal sources.

Strings are located in files with the naming scheme UTranslation_XX.pas where XX stands for locale abbreviation. Each language has its own file, standard Pascal unit file, full of string constants. The main disadvantage is the requirement to compile the application if you want to test the translation. However this solution brings the benefit of independency on additional files or external libraries. Locale strings are updated in every stable version, development snapshots may contain English texts. These versions are under development and things may change before releasing stable version.

The best way to start is to grab latest translation file from the GIT repository (see below), either the English translation file (UTranslation_EN.pas) when making new translation or an existing translation, if you plan to take over the maintainership (check the Description page for list of translations and their statuses). Open the translation file and change all "EN" abbreviations to your new locale abbreviation (including all constants with LANGen prefix). You need to use UTF-8 compliant text editor (gedit, katoob, ...) and save the file in UTF-8 encoding - this is mandatory! If you want to compile tuxcmd to test your translation, you need to add your unit name into a ULocale.pas file - find the line starting with uses and add your new unit. If you don't want to test the translation yourself, send me the file by e-mail, I will check it and will send you a compiled snapshot with your translation.

You may find strings containing underscore ("_") characters, which represent keyboard shortcuts. There's no need to keep shortcuts on the same letter as English source, feel free to change them. Only beware of duplicates in the same submenu or a dialog.

Sometimes a particular translation can be longer than 255 characters (Pascal string constant limit) and sources won't compile. As a workaround, split the constant into several pieces, concatenated by a plus sign. E.g. const x = 'First sentence.' + ' Second sentence.';

To prevent potential encoding issues caused by mail agents, I'd strongly advise to send packed translations (simply do gzip UTranslation_XX.pas and you are fine).

If you are building Tux Commander yourself, use the enclosed Makefile. The only prerequisite is working FreePascal compiler. Further instructions can be found in the 'INSTALL' file.

Please always use latest version of FreePascal compiler, older versions than 2.2.2 contain various bugs, such as the annoying thread limit (0009016: Create Thread Limit).
Similarly, to compile on PowerPC platforms, you need either patched fpc-2.2.4 or any later release. Releases up to fpc-2.2.4 pass wrong arguments on PPC platforms (0013123: Lazarus crash during startup).


List of make targets:

- every module contains necessary URIs for checkout and commit
- to get a snapshot without need to clone whole repo, click the "snapshot" link on particular commit line

network browsing functionality through gvfs plugin

streaming archive extraction optimization

separate extract and archive test functions

support for creating new archives

? cross engine copy support

GTK+ 3.0 port

GVolumeMonitor integration (optional) as a third mounter backend

MIME type support through GIO subsystem (optional)

GFileMonitor integration

complete C rewrite

new panel widget, written from scratch to fullfill file manager needs

VFS (Virtual File System) modules (plugins) are small libraries which include a functionality for access to a remote filesystem or explore the contents of a packed archive. The main goal is to access the virtual filesystem in the same way like it was local filesystem. User should be able to perform basic operations such as directory tree browsing, copying, deleting... The modules have unified API which they communicate with the host application (Tux Commander here) and they could be used also in other file managers (sharing the modules vice versa).

The host application is searching for available modules on program start in these locations: /usr/lib/tuxcmd, /usr/local/lib/tuxcmd, ~/.tuxcmd/plugins and ./plugins and tries to load each module. If the module is successfully loaded, new submenu will appear under the Plugins menu. At this time, there's only the About item, but in the future, the other items will appear (plugin actions, configuration dialogs). For testing purposes there's also the Test plugin dialog where you can try to open the URI with the selected module and test/debug the functionality.
Each module can provide access to the archives and/or to the remote services. You can use integrated Connection Manager to define new connections, which are using the services of the VFS modules.
If the modules aren't loaded on startup, please run tuxcmd with parameter --debug and watch the debug log, you should see what happened. Additionally you can run ldd on each module to see if there are all required libraries available in your system.

Modules are standard unix shared objects (dynamic libraries), loaded dynamically from the host application. You can write your own modules in any programming language, if they could generate compatible so libraries (e.g. gcc, Kylix, FPC). If you are using Pascal or other non-C languages you have to use the cdecl directive or such equivalent. If the module is dependent on some other system libraries not present in the system running in, it will simply display an error message to the debug log and the module will not be available in the application.

There are two modules available in the sources: gnome-vfs and null. You can use the null module to start making your own plugin, there is a skeleton of all functions used in the current version of VFS API. With included Makefile, you can easily compile the module and test the binary version. You can also take a look to the file uVFSprototypes.pas, there are simple comments to each function used in the API. Please note that the API is not fully stable yet, there will be probably some minor changes in the future, mostly for better error handling. I will not describe here detailed comments for each function, maybe when the VSF API v3 will be finished (corrected and working stable VFS API).