The Gwyple Homepage

Welcome to the homepage of the Gwyple project. Gwyple is a graphical frontend - implemented in PerlTK - for various bugtracking systems. It enables the user to handle bug reports from multiple sources in one consistant interface.

Refer to the Gwyple Installation and Usage Guide for a detailed description of the installation process and usage instructions, and to the Gwyple Project Page about CVS access, mailing lists, FTP area, and the tasks list. If you just want to see how it looks like, see the screenshot.

Table of Contents

  1. Introduction
  2. Design
  3. Backends
  4. Developers
  5. State
  6. Achievements
  7. Next steps
  8. The version numbering scheme
  9. TODO
  10. History


I get lots of bug reports for various projects by mail. I don't want to handle all of them in my mailtool. I want: gwyple organizes such a local repository of bug reports. Reports are stored on the local disc, one file per report. In the gui they can be sorted and according to some fields, and filtered (by perl regexes).

The gui consists of a listbox from which to select a bug report, and a text box that presents the content of the selected report. The listbox can be configured according to personal preferences and needs. The appearance of the text box depends on the BTS backend. Usually it's just the plain text of the bug report as it came in.

There is no code that tries to update the remote data storage, or, with other words, access is read-only. This paradigm is changing now: Backends can register special custom functions into one of the dialogs Gwyple provides. This can provide additional functionality like changing the state of a bug in the remote repository. The DDTP backend makes use of this mechanism, and the backend template demonstrates the use with example code.


I want to keep it simple and easily extensible for new kinds of bugtracking systems. Since it's all about processing of text, Perl was choosen as a language, and Perl/TK for the GUI features.

You'll need perl (perhaps any version, I use 5.6 and 5.00503) and of course Perl/TK (any version) to operate this. Depending on used backends you'll probably also need

Backends may require further modules. See the documentation of the specific backend for further details.

Special notes for Windows installations are available on a separate page.


The following bugtracking backends are officially supported by Gwyple: The following bugtracking backends are either unofficially supported or officially unsupported by Gwyple: See the page Gwyple Backends for more information about available backends, or click one of the above links for more information on a specific backend.


Bernd Sokolowsky is doing all the work currently. He works at imbus and hacks on Gwyple in his free time.

Of course, others are invited to contribute (see TODO).

Current State

gwyple-1.1.0 featured some code cleanup and a complete rewrite of the format menue.

gwyple-1.2.0 introduced some exciting new features: filters on bug fulltext, reverse sorting (on all fields separately), and a bug counter in the window title bar.

gwyple-1.3.0 had some cosmetic cleanup of the $ENV code, and preparation for the upcoming port to Windows.

gwyple-2.0.0 introduced official support for the Debian Description Translation Project (DDTP) and a new mechanism that allows backends to register specific functions into the move/delete/export dialog.

gwyple-2.1.0 added preliminary support for Bugzilla and a new contrib section.

gwyple-2.2.0 introduced a new alorythm for file prefix recoginition, which resulted in faster execution speed. Additionally it is now possible to use multiple file prefixes for each backend.

gwyple-2.3.0 fixed a nasty bug that was introduced in 2.2.0.

gwyple-2.4.0 had an update for the email address that is used for DDTP uploads.

gwyple-2.5.0 improved the startup behaviour (no need to run gwyple with the --dir=. option any more.

The current version works fine for ClearDDTS and DDTP, preliminary support for the Debian BTS and for Bugzilla are is also included.


Next steps

The version numbering scheme

Major version 1 indicates that the interface is solid. At this time preliminary support for debian and bugzilla is available, so I will avoid interface changes for my own sake. But, honestly, you'll never know. If there are changes, they will hopefully for the best.

The major digit(s) will indicate the number of (fully supported) backends. The minor digit(s) will be increased for regular updates, and the patch digit(s) will only be used if patches to a previously released version become necessary.


Lots of parts are still missing. And I can't probably do it on my own, so help would be appreciated. There are three fields that I have in mind: I'll try to divide it all into small chunks, to help with a detailed planning. See the TODO page for specifics.


This originates from a tool I wrote to aid me at work. It was originally only designed to work with ClearDDTS.

Later support was added for Sablime. This was removed, however, for the first release at savannah. The reason was that I lost access to this system, and I will not be able to test it any further. Additionally support for Sablime was always somewhat "hack-ish" requiring access to native tools on the local machine.

The "Sablime adventure" led gwyple a good part of the way to be system independant and extensible. It gave me the idea to adapt it for private use, starting with the debian bugtracking system.

(jan 2002)

The rest, as they say, is history:

Last modified: Sat Sep 6 09:57:22 CEST 2003