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
- Introduction
- Design
- Backends
- Developers
- State
- Achievements
- Next steps
- The version numbering scheme
- TODO
- 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:
- procmail to store them for me
- have a gui that presents them in an independent form
- fetch other bug reports and updates directly (e.g. via http)
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
- Class::MethodMaker
- Storable
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).
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.
- remove dependencies from the current environment (done, 2002-01-22)
- upload of a first distribution (done, 2002-01-22)
- gwyple-0.2.0.tgz uploaded (done, 2002-01-23)
- upload of webpage & complimentary files (done, 2002-01-23)
- have a selection of example bug reports (done, 2002-01-27)
- gwyple-0.3.0.tgz uploaded (done, 2002-01-29)
- testsuite-2.0.1.tgz uploaded (done, 2002-01-29)
- freshmeat announcement (done for 0.3.0)
- gwyple-0.4.0.tgz uploaded (done, 2002-03-03)
- testsuite-2.1.0.tgz uploaded (done, 2002-03-03)
- gwyple-0.5.0.tgz uploaded (done, 2002-04-15)
- testsuite-2.2.0.tgz uploaded (done, 2002-04-15)
- gwyple-1.0.0.tgz released (done, 2002-06-18)
- gwyple-1.1.0.tgz released (done, 2003-03-05)
- gwyple-1.2.0.tgz released (done, 2003-04-02)
- gwyple-1.3.0.tgz released (done, 2003-04-07)
- gwyple-2.0.0.tgz released (done, 2003-04-27)
- gwyple-2.1.0.tgz released (done, 2003-05-01)
- gwyple-2.2.0.tgz released (done, 2003-05-11)
- gwyple-2.3.0.tgz released (done, 2003-05-12)
- gwyple-2.4.0.tgz released (done, 2003-08-12)
- gwyple-2.5.0.tgz released (done, 2003-09-07)
- support for Gwyple on Windows (planned for ver. 2.X.0)
- support the Bugzilla bugtracking system (planned for ver. 3.0.0)
- support the debian bugtracking system (planned for ver. 4.0.0)
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:
- gui improvements (or redesign, possibly another toolkit)
- new BTS backends (debian, bugzilla, ...)
- remove OS specific code (make gwyple work in Windows)
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:
- 2002-01-22: gwyple project launched on savannah
- 2002-01-23: introduction of the web page
- 2002-02-02: first freshmeat announcement
- 2002-06-18: gwyple-1.0.0 released to the astonished public
- 2003-04-27: gwyple-2.0.0 released to the astonished public
Last modified: Sat Sep 6 09:57:22 CEST 2003