Fredo's Blog

Humanities, Social Sciences and Free Software

Subscribe to RSS feed

Posts tagged with "GTK"

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.

Ubuntus neues Design – die dreihundertfünfundsiebzigste

, , , ...

Das neue Design der kommenden Ubuntu-Version Lucid Lynx ist enthüllt, und schon bricht ein Sturm aus. Aber das war wohl auch nicht anders zu erwarten. Also kann es auch nicht schaden, wenn ich auch noch meinen Senf dazu gebe.

Eigentlich bin ich bei diesem Thema relativ emotionslos. Ich finde das neue Thema nicht schlecht, aber auch nicht überwältigend. Dass die Fensterknöpfe nun links statt rechts sein sollen, finde ich ungewohnt, aber keine Katastrophe. Dass ein ganzes Designteam besseres schaffen könnte, finde ich durchaus zutreffend, aber auch nicht ungewöhnlich.

Ein Artikel von Pinguinzubehör hat mich aber auch noch mal zum Nachdenken gebracht. Kernaussage:

Das wirklich Tragische am neuen Ubuntu-Design ist jedoch, dass alles wirklich sehr gut aussieht. […]
Allein – alles zusammen sieht grausam aus, es scheint nichts zusammenzupassen.



Und in der Tat ist das auffällig. Vor allem die Kombination von Fensterdekoration und GTK-Thema finde ich irritierend. Kerngedanke ist ja, ein helles und ein dunkles Thema anzubieten. In beiden Fällen passen Fensterdekoration und GTK-Thema in meinen Augen jedoch überhaupt nicht zusammen. Die dunkle Festerdekoration ist in Dunkelgrau gehalten und wirkt eher kühl. Das dazugehörige GTK-Thema jedoch greift das (von vielen, wenn auch nicht von mir, gehasste) Braun wieder auf und wirkt damit deutlich wärmer. Beim hellen Thema ist es anders herum: Die helle Fensterdekoration ist mit ihrem Beige eher warm. Das helle GTK-Thema kommt dagegen in kühlem Grau daher.

Auf die schnelle habe ich mal den GIMP angeworfen und als kleines Experiment Dekoration und GTK-Thema ausgetauscht. Und siehe da: Für meinen Geschmack ein deutlich stimmigeres Bild. Zwar treffen die Attribute „hell“ und „dunkel“ jetzt nur noch bedingt zu; vielmehr hat das eine Thema jetzt einen relativ geringen Kontrast zwischen Fensterdeko und Fensterinhalt, das zweite dagegen einen eher starken. Aber insgesamt scheint es mir so besser zu passen.

Auch wenn ich insgesamt skeptisch bin, welche Auswirkungen die zahlreichen Kommentare aus der Community auf den tatsächlichen Entwicklungsprozess haben, muss ich mir jetzt zumindest nicht vorwerfen, geschwiegen zu haben. Schauen wir einfach mal, wie die Entwicklung weitergeht. Insgesamt bin ich ganz zuversichtlich, und austauschen kann man die Designs am Ende ja immer noch.

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.)

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...