Fredo's Blog

Humanities, Social Sciences and Free Software

Subscribe to RSS feed

Posts tagged with "Python"

Mal schnell was programmieren

, , , ...

Was bisher „Rapid Application Development“ genannt wurde, braucht unter Ubuntu jetzt einen neuen Namen: „Develop Applications Quickly!“

Wenn man mal ehrlich ist: Für viele ist der entscheidende Vorteil von OpenSource Software doch, dass sie kostenlos ist. Natürlich ist die Philosophie dahinter sympathisch, aber wer liest den tatsächlich den Code der Programme, die man benutzt? De facto teilt sich meiner Erfahrung nach die OpenSource-Gemeinschaft in die (wenigen) Programmierer, die wirklich was mit einem Quelltext anfangen können, und die (vielen) Benutzer, die einfach eine Software haben wollen, die funktioniert.

Ich persönlich finde aber das schöne an Linux als Betriebssystem, dass es tatsächlich ein dazwischen gibt: Nicht nur, dass man auf verschiedene Arten zu OpenSource beitragen kann. Auch der Einstieg in die Programmierung selbst ist einfacher, als man vielleicht denkt. Es fängt vielleicht beim einfachen Shell-Skript an, um eine Reihe von Bildern zu verarbeiten, und endet irgendwann bei einem kleinen, aber vollständigen Programm inklusive grafischer Benutzeroberfläche. In der Ubuntu-Community nimmt man so auch zunehmen die Gelegenheitsentwickler in den Blick. Diejenigen, die also nicht hauptberuflich Informatiker oder ähnliches sind und sowieso den ganzen Tag programmieren, sondern die Benutzer, die einfach gerne ab und zu mal ein kleines Programm schreiben, um ein ganz konkretes Problem zu lösen. So wurde im März die „Opportunistic Developers Week“ veranstaltet, die eben jenen Gelegenheitsprogrammierern einen Einblick in die neuen Möglichkeiten der Anwendungsentwicklung unter Ubuntu geben sollte.

In eine ähnliche Richtung geht Quickly, ein neues Framework für schnelle Anwendungsentwicklung. Das Ausgangsproblem ist schnell beschrieben: Programmieren lernen ist das eine. Hat man sich erst einmal durch die Tutorials gewühlt und verstanden, was Datentypen sind, wie man Schleifen und Bedingungen programmiert, sich vielleicht die Grundzüge von Objektorientierung erarbeitet, fangen viele Folgeprobleme erst an: Wie kriege ich jetzt eine grafische Oberfläche für mein erstes Programm? Wie baue ich Internationalisierung ein, damit man das Programm in verschiedene Sprachen übersetzen kann? Wie benutze ich ein Versionskontrollsystem, um meinen Code mit anderen zu teilen? Und wie baue ich Pakete, um anderen die Installation zu erleichtern? Jeder dieser Punkte braucht wieder Einarbeitung, wieder muss man sich durch verschiedene Tutorials wühlen, und für jeden Punkt wendet man wieder fast so viel Zeit auf wie für die eigentliche Programmierung.

Genau hier setzt Quickly an. Quickly stellt einem ein Skelett für die Programmierung bereit, also in etwa den Teil, den man ansonsten ohnehin per Copy und Paste aus diversen Tutorials übernommen hätte: Eine Basisstruktur für die Dateien in einem Projekt, die Anbindung an einen GUI-Designer, Code für die Internationalisierung und den Paketbau. Aber Quickly macht auch mehr: Quickly trifft gewisse Vorentscheidungen. Was routinierte Entwickler vielleicht als Bevormundung empfinden, ist für Einsteiger oftmals eine Hilfe: Sich nicht über zig Alternativen informieren, auswählen, Entscheidungen treffen, die man kaum einschätzen kann. Quickly macht hier gewisse Vorgaben: Python als Programmiersprache, Glade/GTKBuilder für die Oberflächengestaltung, bzr als Versionsverwaltung, Launchpad als Code-Hosting-Plattform. (All das lässt sich über sogenannte Templates festlegen. Es spricht also nichts dagegen, ein Template für KDE-Programme zu schreiben, das auf git/GitHub setzt. Es hat nur noch niemand getan.)

Von der Benutzung greift Quickly vieles auf, was Web-Frameworks bieten: Wer etwa Django kennt, und dessen Kommandozeilenhelfer django-admin, dem wird quickly bekannt vorkommen. Aber auch so versteht man das Prinzip schnell.

$ quickly create ubuntu-application myapp

erzeugt ein neues Projekt myapp auf der Basis der Vorlage ubuntu-application (derzeit stehen daneben noch ubuntu-cli und ubuntu-pygame zur Verfügung). Dabei wird ein Grundgerüst angelegt, bestehend aus GTKBuilder- und Python-Dateien für ein Programmfenster, einen Einstellungsdialog, einen About-Dialog und etwas Kleister, der das Ganze zusammenhält. Ist man mit „$ cd myapp“ in das neu erstellte Projektverzeichnis gewechselt, kann man Projektspezifische Befehle ausführen:

$ quickly tutorial

zeigt etwa ein schönes, bebildertes Tutorial im Hilfebrowser an, das einem die Funktionsweise von Quickly und die ersten Schritte bei der Programmierung erklärt.

$ quickly commands

listet alle verfügbaren Befehle auf, die man sich mit
$ quickly help <command>

erläutern lassen kann.

Richtig los geht es dann mit
$ quickly design


Damit werden alle UI-Dateien im Glade Interface-Designer geöffnet, so dass man die Oberfläche seines Programms gestalten kann. Den zugehörigen Code bearbeitet man mit
$ quickly edit

woraufhin die Python-Dateien in gedit geöffnet werden.

$ quickly run

startet dann das Programm, so dass man es ausprobieren kann. Entsprechende Befehle gibt es, um das Projekt in bzr zu speichern, auf Launchpad hochzuladen, oder ein Installationspaket daraus zu bauen (wobei gleich auch die Übersetzungsvorlagen angelegt werden). Insgesamt geht mit Quickly vieles leicht von der Hand, wofür man sich früher relativ lange einarbeiten musste.

Das ganze hat aber auch einen Preis: Man muss sich in sein eigenes Programm erst einmal einlesen. Gerade Einsteigern fällt es oft leichter (zumindest kann ich das aus eigener Erfahrung sagen), selbst Code zu schreiben, als Code von anderen zu lesen und zu verstehen. Es ist oft erst einmal mühselig, nachzuvollziehen, wie die einzelnen Komponenten miteinander zusammenhängen. Dadurch, dass ein Quickly-Programm schon viel Infrastruktur mitbringt, muss man sich erst einmal die Zeit nehmen, zu verstehen, was da schon passiert und an welchen Stellen man nun seinen eigenen Code einfügt oder Modifikationen vornimmt. Der Code ist aber gut kommentiert und das Tutorial erklärt alle Schritte, so dass sich die Mühe am Anfang durchaus lohnt.

Deskbook: Deskbar meets Adressbuchsuche

, , ,

Der einen oder dem anderen ist die Deskbar sicherlich ein Begriff: Jenes kleine Panel-Applet, hinter dem sich eine universelle Suchleiste verbirgt. Damit lassen sich Dateien finden (unter anderem über Tracker), Programme starten, Übersetzungen nachschlagen und vieles mehr.

Unter anderem ist auch eine Adressbuchsuche enthalten, die die Evolution-Adressbücher durchsucht, so dass man schnell eine E-Mail an eine bestimmte Person erstellen kann. Das war mir aber zu wenig, denn – kaum zu glauben, aber wahr – es gibt noch andere Kontaktmöglichkeiten außer E-Mails. So habe ich nie die Telefonnummern der Kollegen im Kopf, und deswegen schlage ich die relativ häufig nach.

Zu diesem Zweck gibt es das Panel-Applet »Adressbuchsuche« (contact-lookup-applet). Es fügt eine kleine Suchleiste ins Panel ein und zeigt gefundene Kontakte in einem übersichtlichen Fenster als »Adresskarte« an. Auch von dort aus lassen sich dann leicht Mails erstellen.

Aber ich bin kein großer Freund von Suchleisten im Panel, die nehmen mir zu viel Platz weg, dafür dass sie doch nur einem sehr eingegrenzten Zweck dienen. Daher dachte ich mir, es wäre ganz hübsch, die Funktionalität der Adressbuchsuche (und vor allem die Ergebnisdarstellung) in der Deskbar zu haben. Da das ja ein begrenzt komplexes Unterfangen ist, habe ich es einfach zu meiner Abendbeschäftigung erklärt. Und nun ist es langsam fertig, die Adressbuchsuche in der Deskbar:





Da das contact-lookup-applet in C geschrieben ist, die Deskbar aber in Python, habe ich den Dialog nach Python portiert. Daher wird das Paket python-gnome2-desktop benötigt, das die Evolution-Anbindung für Python bereitstellt. Ansonsten sollte es für die Installation reichen, das Plugin-Paket in die Pluginliste der Deskbar (zu finden unter »Einstellungen«) zu ziehen.

deskbook.tar.bz2

Viel Spaß damit!

Update 2. Nov. 2009: Unter Karmic gab es ein ein kleines Problemchen mit dem Plugin. Deswegen habe ich eine neue Version hochgeladen, in der der Fehler nicht mehr auftaucht.

Update 3. Nov 2010: Ein kleiner Fehler hat verhindert, dass Kontakte mit Homepage-Angabe angezeigt werden. Der Fehler ist in einer neuen Version behoben. (Lustig, dass mir das fast haargenau ein Jahr nach dem letzten Update auffällt.)

Zur Serienreife? Serienbriefe mit LaTeX

, ,

Das Thema Serienbrief bringt mich regelmäßig zur Verzweiflung. OpenOffice.org bietet hier zwar die entsprechenden Funktionen an, aber wirklich reibungslos läuft das bei mir nie. Schon allein eine ODS-Datei mit den Adressen in das Dokument zu laden ist für mich eine Herausforderung.

Außerdem schreibe ich meine Briefe sowieso lieber mit LaTeX. Dort sieht alles ganz schnell so aus, wie es bei einem anständigen Brief sein soll. Also habe ich mich gefragt, ob man mit LaTeX nicht auch Serienbriefe erstellen kann. Und tatsächlich, in der KOMA-Anleitung bin ich fündig geworden. Serienbriefe sind mit scrlttr2 möglich. Allerdings muss man die Adressdaten in einem bestimmten Format haben. Eine Datei mit der Endung .adr soll Einträge in der Form
\adrentry{Name}{Vorname}{Adresse}{Telefon}{F1}{F2}{Kommentar}{Kürzel}

haben. Das ist natürlich eher ungewöhnlich, um nicht zu sagen nervig.

Also habe ich mir ein kleines Skript in Python geschrieben, das eine CSV-Datei in eine adr-Datei umwandeln kann. Dabei kann man die adr-Felder frei aus Feldern in der CSV-Datei zusammensetzen. Oftmals wird man z.B. die Adresse in einzelnen Feldern vorliegen haben, z.B. Straße, PLZ und Ort.

Das Skript gibt’s hier: addressify.py

Ein Aufruf könnte z.B. so aussehen:
python addressify.py -m 'Name=$Nachname' -m 'Vorname=$Vorname' -m 'Adresse=$Strasse\\$PLZ $Ort' -m 'F1=$Geschlecht' -o 'adressen.adr' adressen.csv

Nun hat man eine passende Datei, also steht dem Serienbrief nichts mehr im Weg. Der könnte z.B. so aussehen:

\documentclass[DIN]{scrlttr2}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[ngerman]{babel}
\usepackage{mathpazo}

\begin{document}
\newcommand{\Anrede}{}
\renewcommand*{\adrentry}[8]{%
    \if #5w \renewcommand{\Anrede}{Frau} \fi
    \if #5m \renewcommand{\Anrede}{Herrn} \fi
    \begin{letter}{\Anrede\\#2 #1\\#3}
        \if #5w \opening{Sehr geehrte Frau #1,} \fi
        \if #5m \opening{Sehr geehrter Herr #1,} \fi

        Serienbriefe mit \LaTeX{} sind nicht schwer zu realisieren.

        \closing{Mit freundlichen Grüßen,}
    \end{letter}
}

\input{adressen.adr}
\end{document}


Für meine Zwecke reicht das erst einmal, endlich ein verlässlicher Weg, einfache Serienbriefe zu schreiben. Raum für Optimierungen gibt es sicherlich noch, aber das überlasse ich, wie man so schön sagt, dem Leser als Übung.

LaTeX, Zotero und gedit

, , , ...

In der Tat, Zotero hat mich weitgehend überzeugt. Es ist ein recht brauchbares Literaturverwaltungsprogramm, vor allem aber wird es aktiv weiterentwickelt und von etablierten Institutionen unterstützt. Damit ist es eine recht zukunftssichere Wahl, schließlich will ich nicht alles halbe Jahr meine Literaturdatenbank umziehen.

Die Integration in OpenOffice.org ist außerdem wirklich gut. Nur schreibe ich eigentlich lieber mit LaTeX, und hier bietet Zotero von Haus aus keine Unterstützung. Aber gedit, mit dem LaTeX-Plugin mein favorisierter LaTeX-Editor, hat ja eine schöne Python-Plugin-API. Also kann man ja mal versuchen, ein gedit-Plugin für die Zotero-Einbindung zu schreiben…

Read more...

First impressions of AVG

, , , ...

Recently, I discovered AVG (Ain't Vector Graphics). AVG is a platform for developing interactive multimedia applications, e.g. for exhibitions or showrooms. Since a friend of mine told me that he was searching for an open alternative to Macromedia Director, I took a look. And being an SVG enthusiast for quite a while, I was interested in what one could achieve using AVG that one couldn't with SVG and vice versa.

Read more...

Genesis gets you started with SyncEvolution

, , , ...

SyncEvolution isn't actually hard to configure. But it requires the creation of a specific directory structure (unter ~/.sync4j) and the manual editing of configuration files. This is somewhat a hurdle for less tech-savvy users when getting started with SyncEvolution. (It also took me some time before I decided to use SyncEvolution because I found that config-file stuff not very appealing.) Genesis 0.2 is an attempt to change that. It now includes a configuration wizard that helps you create your initial setup.

Read more...

Genesis – A Graphical Frontend for SyncEvolution

, , , ...

I have recently started to use SyncEvolution. This is a commandline driven SyncML client that allows you to synchronize your Evolution data (appointments, addresses, tasks) with a SyncML server like Scheduleworld. I like this concept, because it is based on open standards and free software, and I think this is a better approach than the proprientary client APIs that, for example, Google provides.

Now it's relatively easy to set up and use syncevolution. You have to edit some config files, but they are well documented and easy to understand. And you have to execute a simple command to perform the actual synchronization. Plus, you get detailed information about the actual process. But I mostly don't need that much information (except in the case of failure), and I don't want to open up a terminal every time I sync my data. So I decided to write a simple, small GUI in PyGTK.

Read more...

Check online status with DBUS

,

One of the advantages of NetworkManager is that it's accessible via DBUS. So if your application relies on a network connection, you can easily check the online status before running into problems.

A simple python example that might be sufficient for many applications:

import dbus

NM_STATE_UNKNOWN = 0
NM_STATE_ASLEEP = 1
NM_STATE_CONNECTING = 2
NM_STATE_CONNECTED = 3
NM_STATE_DISCONNECTED = 4

bus = dbus.SystemBus()
nm = bus.get_object('org.freedesktop.NetworkManager',
        '/org/freedesktop/NetworkManager')
if nm.state() == NM_STATE_CONNECTED:
    print 'Network available!'