Softwareentwicklungsprojekte für die Molekularbiologie

GCK2.5-bezogen

1. GCK2.5-Fehlerbehebung unter Wine** Es gibt immer noch einige Fehler, die die Nutzung von GCK2.5 unter Wine manchmal erschweren. Insbesondere die Unmöglichkeit, Regionen zu annotieren, nach einer Sequenz zu suchen und eine neue Datei zu öffnen.
2. GCK2.5-Export** GCK2.5 kann keine Dateien im EMBL-Format exportieren, bei denen die Regionen in Features umgewandelt wurden. Es kann jedoch Kommentare in eine Textdatei und reine Sequenzen in eine Textdatei exportieren. Es sollte ein Leichtes sein, ein Perl-Skript zu schreiben, das diese beiden Dateien übernimmt und sie in eine EMBL-Datei, eine EMBOSS-CIRDNA-/LINDNA-Datei oder eine pDRAW32-Datei konvertiert.
3. GCK2.5/Wine-Desktop-Integration** Beim Klicken auf Dateien, die mit Windows-Programmen (unter Verwendung von Wine) verknüpft sind, übergibt der Linux-Dateimanager (z. B. Konqueror) die Datei als Argument an die zugehörige Windows-Anwendung, und die Datei wird unter Wine geöffnet. GCK2.5 weigert sich jedoch, die Datei als Argument anzunehmen. Wenn ich auf eine .gcc-Datei klicke, startet GCK2.5 zwar, öffnet aber ein leeres Fenster, und ich muss die .gcc-Datei erst innerhalb von GCK2.5 öffnen. Das ist unnötiges Klicken, insbesondere wenn ich mehrere Ordnerhierarchien durchlaufen muss. Wenn GCK2.5 nativ unter Windows läuft, ist es dann möglich, GCK2.5 mit einer Konstruktionsdatei als Befehlszeilenargument zu starten? Das sollte ich mal prüfen.

pDRAW32-bezogen

1. pDRAW32-Debugging für Wine
2. Ein Dateiformat-Plugin für EMBOSS schreiben. EMBOSS sollte pDRAW32-Dateien (bei denen es sich um reine Textdateien handelt) als Ein- und Ausgabedateien verwenden können.
3. Ein Perl-Skript-Konverter für embl/GCK2.5/pDRAW32 schreiben

Staden-bezogen

1. Ein SUSE Linux 9-RPM für Staden erstellen. Als Ausgangspunkt für die Erstellung von RPMs kann man sowohl den Quellcode als auch die Binärdateien verwenden. Vor allem möchte ich Staden besser in den KDE-Dateimanager integrieren (dafür muss ich MIME-Typen und Dateizuordnungen, Symbole sowie jede Menge .desktop-Dateien erstellen).
2. Im Wesentlichen dasselbe wie unter 1, jedoch für Mac OS X. Anders Nister hat ein Paket erstellt, das sich manchmal korrekt installieren lässt. Allerdings fehlt die Desktop-Integration. Einige anklickbare Symbole und Dateizuordnungen wären schön. Leider kann man weder auf Shell-Skripte klicken noch Dateien darauf ablegen. Ich habe mit Platypus experimentiert, um die von mir geschriebenen Shell-Skripte zu verpacken, aber die Drag-and-Drop-Unterstützung funktionierte mit Platypus nicht. Außerdem ist mir unklar, wie ich MacOSX dazu bringen kann, zu erkennen, dass mehr als nur .ab1-Dateien mit z. B. pregap4 geöffnet werden können. Es ist einfach, macOS dazu zu bringen, eine neue Dateiendung (ich habe .ab1 ausprobiert) mit einer Anwendung (ich habe ein mit Cocoa verpacktes Shell-Skript verwendet) zu verknüpfen, indem man die entsprechende info.plist-Datei (Strg-Klick -> „Paketinhalt anzeigen“ usw.; es handelt sich um eine XML-Datei, die in einem recht benutzerfreundlichen XML-Editor geöffnet wird, in dem man solche Dinge bearbeiten kann; man kann einfach eine andere info.plist-Datei als Vorlage nehmen, um zu sehen, welche Optionen es gibt).

Ich habe meinen Cocoa-Wrapper mit allen Dateien verknüpft, die auf .ab1 enden, und ihnen ein bestimmtes Symbol sowie einen Namen zugewiesen. Das funktioniert. Als ich jedoch eine weitere Dateiendung hinzufügte (ich habe es mit .txt versucht, da reine Sequenzdateien von pregap4 lesbar sein sollten), funktionierte es nicht mehr. Ich hatte erwartet, dass Mac OS X nun im Menü „Öffnen mit“ verschiedene Optionen anzeigen würde (wie z. B.: TextEdit, pregap usw.), aber stattdessen war dort nichts zu sehen … Anscheinend unterscheidet sich Mac OS X in der Art und Weise, wie Dateitypen und Anwendungen zugeordnet werden, ziemlich stark von z. B. KDE.

EMBOSS-bezogen

1. Verbesserung der EMBOSS-Sequenzbearbeitungswerkzeuge (Beibehaltung der Annotationen)
2. Schreiben eines Perl-Skript-Konverters für embl/GCK2.5/pDRAW32

OpenOffice-bezogen

1. Literaturverwaltungssystem. Der Hauptgrund, warum Forscher in den Lebenswissenschaften Microsoft Office nutzen, ist die Verfügbarkeit relativ guter Literaturverwaltungssysteme. Die meisten Leute, die ich kenne, nutzen EndNote (es gibt aber auch andere sehr gute Tools). Zwar gibt es mehrere Open-Source-Literaturverwaltungssysteme, doch keines davon kommt an die kommerziellen heran, insbesondere was die Integration in OpenOffice betrifft. Es gibt zwar Leute, die an einem Literaturverwaltungssystem für OpenOffice  arbeiten, aber offenbar sind es nur wenige, die an diesem Modul arbeiten, und daher wird es noch einige Zeit dauern… Natürlich hat man mit LaTeX ein sehr gutes Werkzeug, aber es ist aussichtslos, 300.000 Forscher aus den Lebenswissenschaften davon zu überzeugen, LaTeX zu lernen. Es gibt auch ein Literaturverwaltungssystem für Linux namens SixPack, aber ich habe es nicht ausprobiert und glaube, dass es nicht mehr weiterentwickelt wird.