Für meine DRI-Log App wollte ich einen Button verwenden, der den Benutzer zurück zur vorherigen Activity bringt. Leider gibt es bei den unter Android verfügbaren Buttons keinen Zurückbutton. Apple's iOS bringt einen Button mit, der an der linken Seite spitz zuläuft. Genau diese Form habe ich auch für Android gesucht und leider nicht gefunden.

Was tun, wenn man etwas sucht, dass es noch nicht gibt? Man macht es selber!

Ich habe dazu die Originalbuttons von Android in Inkscape als PNG importiert und bestmöglich nachgebaut. Anschließend habe ich sie spitz zulaufen lassen. Ich habe den Button im gleichen Stil wie Android 2.2 und 2.3 erstellt, da meine App bisher noch nicht für Android 3.0 oder neuer optimiert ist. Es wird ein Zurückbutton für diese Versionen folgen, wenn ich ihn benötige.

Achso: Falls mal jemand ein SVG von den Original-Android-Buttons benötigt, so findet er sie hier.

Ich musste gerade auf einem Windowssystem herausfinden, ob eine DLL 32 oder 64 bit hat. Jeder, der den Befehl file unter Linux kennt, sucht nach einer ebenso einfachen Möglichkeit unter Windows. Wenn man nach diesem Problem online sucht, findet man diverse absurde Lösungen ... ein Perl-Skript, kurz mal Visual Studio installiern, etc.

Die einfachste Lösung fand ich beim ReactOS-Projekt, den Dependency Walker. Dieser zeigt einfach bei allen Symbolen der DLL ob sie 64 oder 32 Bit verwenden. So einfach kann es sein und der Dependency Walker muss nicht mal installiert werden.

Ich verwende für eine App eine ListView. Diese ListView wird mit Layoutelementen befüllt, die aus einem Bild links und einem Text rechts bestehen. Soweit so trivial. Eine Zeile muss dabei nicht immer ein Bild haben und es ist natürlich viel schöner, das Nachladen der Bilder über einen Task zu machen. Dieser Task lädt die Bilder von einem Server herunter, der sie vorher auf die gewünschte Größe skaliert hat.

public class DownloadImageTask extends AsyncTask {

 private final ImageView image;

 public DownloadImageTask(ImageView image) {
  this.image = image;
 }

 protected Drawable doInBackground(String... url) {
  return HttpUtil.getDrawableFromUri(url);
 }

 protected void onPostExecute(Drawable drawable) {
  if (drawable != null) {
   image.setImageDrawable(drawable);
  }
 }
}

Damit erhält ist das übergebene Drawable in onPostExecute immer ein 120x120 Pixel großes Bild. Sobald dieser Code allerdings durchgelaufen ist, sind über und unter dem Bild viel zu große Abstände. Mit Hilfe der View Hierarchie-Perspektive der Android-Tools für Eclipse konnte ich feststellen, dass das Drawable mit dem Bild eine Breite von 50 Pixeln und eine Höhe von 120 Pixeln hatte. Das erklärte den Abstand. Aber woher genau kommt er? Sehen wir uns doch mal den Code für das Bild an:

 <ImageView
  android:id="@+id/item_image"
  android:layout_width="50dp"
  android:layout_height="wrap_content" />

Dieser Code legt die Breite auf 50 Pixel fest, allerdings nicht die Höhe. Es gibt zwei Lösungen für das Problem.

• Entweder man setzt die Höhe fest auf 50 Pixel. Das funktioniert allerdings nur bei quadratischen Bildern.
• Oder man fügt ein android:adjustViewBounds="true" in den ImageView-Code ein. Damit werden die Bilder korrekt auf max. 50 Pixel Breite unter Einhaltung der Aspektrate skaliert.

Ich habe mir vor etwas über einem Jahr auf meinem Laptop ein Ubuntu 10.4 LTS installiert. Mein Laptop muss nicht mit der neusten und tollsten Software laufen. Er muss stabil sein, weil ich damit arbeite. Ich will (und kann) mich nicht mit dem darunterliegenden Betriebssystem aufhalten. Allerdings hatte das System irgendwann beim Booten einen Kernelpanic. Da ich schnell wieder ein funktionierendes System benötigte, habe ich eine Gentoo stage3 in das existierende System eingespielt. Damit hatte ich ein stabiles System, was allerdings beim Installieren von Software aus offensichtlichen Gründen immer Probleme verursachte. Das System musste also wohl oder übel neu installiert werden.

Da ich einige Entscheidungen von Canonical bezüglich Ubuntu nicht vollständig teile (um mal die Schlagworte Unity, Ubuntu-One, CouchDB, Banshee zu nennen) und über Fedora sehr viel gutes gehört habe, wollte ich es mal ausprobieren.

Installation

Der Installer von Fedora (anaconda genannt) ist relativ elegant. Man kann mit minimalem Aufwand ein System installieren, dass direkt funktioniert. Das ist ein großer Vorteil gegenüber Gentoo. Die einzelnen Schritte zum Installieren eines Gentoo-Systems beherrsche ich zwar im Schlaf, aber sie sind aufwendiger (insbesondere wenn man nicht nur ein Kernsystem haben will, sondern auch X11, gnome und einen Browser). Die installierte Auswahl an Paketen ist grundsätzlich gut, bringt aber so manches Programm mit, was ich nicht benötigte.

Paketmanager

Gentoo bringt keinen graphischen Paketmanager mit. Es gibt aber diverse Ansätze um diesen zu etablieren, unter anderem PackageKit. Aus Ubuntu kannte ich synaptics, der mir wirklich gut gefiel. Fedora scheint keinen eigenen Paketmanager zu besitzen und statt dessen auch auf PackageKit zu setzen. Ich konnte mich zwar schnell wiederfinden, aber gpk-application ist bei weitem nicht so rund wie synaptics. Es ist schwierig die installierten Pakete zu finden, es wird zu viel wert auf die (leider meist schlecht gepflegte) Beschreibung anstelle des Paketnames gelegt und, was das größte Problem ist, die GUI versetzt sich des öfteren in einen Zustand, in dem nichts angeklickt werden kann (einfachstes Beispiel: nichts auswählen und Ausgewählte Pakete anklicken). Ich bin dazu übergegangen yum zu verwenden. Das Kommandozeilenprogramm lässt sich einfach bedienen und erfüllt seinen Zweck. Da ich unter Gentoo gewohnt bin mit emerge zu arbeiten, ist dies keine große Umstellung.

Software

Es gibt viel Software in Gentoo, die es nicht in Fedora gibt und umgekehrt. Interessant finde ich den Ansatz von Fedora, nur Software zuzulassen die aus den Quellen übersetzt wird. Das mag zwar theoretisch ein ganz toller Ansatz sein, ist aber in der Praxis kaum umzusetzen. Ich benötige beispielsweise den android-sdk. Gentoo stellt ein ebuild bereit, um das Binärpaket nach /opt zu installieren. Mit der richtigen Gruppenberechtigung darf der normale Nutzer auch neue API-Versionen installieren. Super. Unter Fedora wollte ich ebenfalls diesen Luxus. Theoretisch kann man sich den Android SDK selbst bauen (so weit ich weiß sollte alles daran Open-Source sein), aber wieso auf die vorbereiteten Pakete von Google verzichten? Ich bin dazu übergegangen aus Gentoo-ebuilds mir rpm's für Fedora zu erstellen. Beide haben eine gewisse Ähnlichkeit obwohl ebuilds meines Erachtens bedeutend luxuriöser sind. Aber dazu ein andermal mehr.

Fazit

Gentoo bietet mit den ebuilds (und zugehörigen USE-Flags) eine perfekte Möglichkeit ein System genau so zu bauen, wie man es benötigt. Aber: es braucht Zeit. Fedora stellt ein sehr gut nutzbares System zur Verfügung. Es ist bei weitem nicht so "poliert" wie Ubuntu. Es ist auch stärker auf Geeks ausgelegt (z.B. durch Verwendung von SELinux per Default, was nicht das einfachste Sicherheitsframework ist). Alles in Allem ist es aber absolut brauchbar und nach ein paar Konfigurationseinstellungen (SELinux deaktivieren, Themes installieren, Fonts anpassen, PS1 anpassen) sehr gut zu benutzen.

Um einen Apache Tomcat per mod_jk hinter einen Apache HTTPd zu hängen, gibt es das AJP-Protokoll. Dies wird vom mod_jk implementiert, was für die Kommunikation zuständig ist. Soweit die Theorie. In der Praxis wollte das nicht funktionieren und ich fand folgenden Logeintrag:

connecting to backend failed. Tomcat is probably not started or is listening on the wrong port (errno=13)

Die Debug-Ausgaben von mod_jk ergaben, dass eine Verbindung zu 127.0.0.1:8009 fehlschlug. Zuerst hatte ich IPv6 in Verdacht. Also habe ich es erstmal deaktiviert:

echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

Dies brachte keine Besserung. Der Service lief jetzt zwar unter IPv4, telnet klappte, aber der Apache HTTPd wollte sich trotzdem nicht verbinden. Dann fand ich folgenden Logeintrag

[error] init_jk::mod_jk.c (3235): Initializing shm:/var/log/httpd/jk-runtime-status.16551 errno=13. Load balancing workers will not function properly.

Eine kurze Recherche ergabe, dass SELinux dazwischen funkt. Ich weiß nicht, warum Fedora SELinux per Default aktiviert. Es mag zwar für die Sicherheit gut sein, aber ich hatte bisher nur Probleme damit. Meine Lösung ist es in der Datei '/etc/selinux/config' folgende Zeile einzufügen.

SELINUX=disabled

Anschließend funktioniert alles und mein System reagiert gefühlt schneller.

Kürzlich habe ich mal wieder Lust dazu bekommen, mein Wacom Tablet auszuprobieren. Daher habe ich diese kleine Szene gemalt:

Es ist das erste Mal, dass ich mit dem Tablet tatsächlich ein ansehnliches Ergebnis produziert habe. Das hat mit selbst etwas überrascht und ich bin dem etwas nachgegangen. Bisher habe ich das dem Table beiliegende Corel Essential 2 oder Gimp verwendet. Beide sind zwar nette Spielereien für Tablets, aber kommen darüber nicht hinweg. Da ich durch Zufall von MyPaint gehört hatte, wollte ich das mal ausprobieren. Ich muss sagen: Ich bin sehr zufrieden, denn die guten mitgelieferten Brushes sind der Grund, warum ich dieses Mal mehr als ein "Hallo, dies ist ein Test" gemalt habe. Und natürlich, dass ich vor Kurzem in die Bob Ross DVD rein gesehen habe ;-).

Da ich bereits mehrfach gefragt wurde, wie man mit Maven und ADT ein Projekt multimandandenfähig macht (d.h. aus einem Sourcebaum entstehen mehrere Apps), fasse ich das hier mal kurz zusammen.

Grundsätzlich benötigt man die Maven-Struktur für ein Android Projekt. Diese sieht wie folgt aus:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>de.egore911.mobile</groupId>
 <artifactId>test</artifactId>
 <version>0.1-SNAPSHOT</version>
 <packaging>apk</packaging>
 <name>${project.artifactId}</name>

 <properties>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 </properties>

 <dependencies>
  <dependency>
   <groupId>com.google.android</groupId>
   <artifactId>android</artifactId>
   <version>2.2.1</version>
   <scope>provided</scope>
  </dependency>
 </dependencies>

 <build>
  <plugins>
   <plugin>
    <groupId>com.jayway.maven.plugins.android.generation2</groupId>
    <artifactId>android-maven-plugin</artifactId>
    <version>3.0.0-alpha-14</version>
    <configuration>
     <androidManifestFile>${project.basedir}/AndroidManifest.xml</androidManifestFile>
     <assetsDirectory>${project.basedir}/assets</assetsDirectory>
     <resourceDirectory>${project.basedir}/res</resourceDirectory>
     <nativeLibrariesDirectory>${project.basedir}/src/main/native</nativeLibrariesDirectory>
     <sdk>
      <platform>8</platform>
     </sdk>
     <deleteConflictingFiles>true</deleteConflictingFiles>
     <undeployBeforeDeploy>true</undeployBeforeDeploy>
    </configuration>
    <extensions>true</extensions>
   </plugin>

   <plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
     <source>1.6</source>
     <target>1.6</target>
    </configuration>
   </plugin>

  </plugins>
 </build>

Ich werde an dieser Stelle nicht auf die einzelnen Teile eingehen. Es geht jetzt darum, wie man Resources austauschen kann. Dazu verwendet man in Maven Profile. Ich verwende z.B. ein Profil namens "demo".

<profile>
 <id>demo</id>
 <activation>
  <property>
   <name>config</name>
   <value>demo</value>
  </property>
 </activation>
 <build>
  <plugins>
   <plugin>
    <artifactId>maven-resources-plugin</artifactId>
    <version>2.5</version>
    <executions>
     <execution>
      <id>copy-assets</id>
      <phase>initialize</phase>
      <goals>
       <goal>copy-resources</goal>
      </goals>
      <configuration>
       <outputDirectory>${basedir}/assets</outputDirectory>
       <resources>
        <resource>
         <directory>${basedir}/templates/assets/demo</directory>
         <filtering>false</filtering>
        </resource>
       </resources>
       <overwrite>true</overwrite>
      </configuration>
     </execution>
     <execution>
      <id>copy-res</id>
      <phase>initialize</phase>
      <goals>
       <goal>copy-resources</goal>
      </goals>
      <configuration>
       <outputDirectory>${basedir}/res</outputDirectory>
       <resources>
        <resource>
         <directory>${basedir}/templates/res/demo</directory>
         <filtering>false</filtering>
        </resource>
       </resources>
       <overwrite>true</overwrite>
      </configuration>
     </execution>
    </executions>
   </plugin>
  </plugins>
 </build>
</profile>

Hierbei sind zwei Dinge zu beachten:

1. Das Kopieren der Ressourcen muss vor der Ausführung das Android-Plugins passieren. Da das Android-Plugin in der Phase "generate-sources" ausgeführt wird, habe ich "initialize" als Phase gewählt (Warum erschließt sich bei der Betrachtung des Maven Livecycle).
2. Per Default überschreibt das maven-resource-plugin nicht bestehende Resourcen, wenn diese neuer sind. Dies ist für den gegebenen Anwendungsfall natürlich unpraktisch.

Damit kann jetzt jeder seine App auch als Demo ausliefern. Es bleibt dem Entwickler überlassen, ob er die Vollversion in den res und assets-Ordnern pflegt oder diese auch als Profile realisiert. Ich habe letzteres verwendet, damit ich mir nicht aus Versehen teile der Demo in die Vollversion stecke (oder umgekehrt). Man sollte in diesem Fall darauf achten, dass die Daten nicht ins Versionskontrollsystem eingecheckt werden. Dies kann dann allerdings zur Folge haben, dass wenn kein Profil aktiv ist, die Daten fehlen und der Android-Buildprozess fehlschlägt. Als Lösung bietet sich an, entweder ein Profile auf "activeByDefault" zu stellen, oder in der Entwicklungsumgebung das Profil zu aktivieren.

Man kann mit Eclipse und den dazugehörigen ADT sehr elegant für Android entwickeln. Allerdings bin ich darüber gestolpert, dass man damit nicht ohne weiteres "Demos" einer vollwertigen Applikation (d.h. ein APK, dass gewisse Einschränkungen gegenüber einer Vollversion der selben Software hat) aus den gleichen Sourcen erzeugen kann.

Es wäre evtl. möglich dass in den Ant-basierten Build einzubinden, allerdings habe ich gleiches bereits für Maven konzipiert und will das Rad nicht neu erfinden. Bei einer kurzen Internetrecherche bin ich über das android-maven-plugin gestolpert. Es erlaubt einem, dass Ant-basierte Buildsystem durch Maven zu ersetzen. Nachdem ich diesen Schritt vollzogen hatte, ließ sich unter Verwendung der Maven-Profiles problemlaus eine Demo erzeugen.

Ich habe heute beschlossen, meine Experimente mit Enticore zu beenden. Ich hatte das System ursprünglich erdacht, um ein leichtgewichtiges und modulares CMS zu erstellen. Zum damaligen Zeitpunkt gab es zwar schon diverse in PHP entwickelte Open-Source-CMS, aber keines davon war "mal auf die Schnelle" eingerichtet. Von Leichtgewichtig ganz zu schweigen.

Aber die Zeiten ändern sich. Ich habe vor ca. einem Jahr Drupal 6 kennen gelernt und viele Grundideen von Enticore dort wiedergefunden. Insbesondere die Modularität ist in Drupal sehr gut umgesetzt. Allerdings hatte Drupal 6 in meinen Augen eine gravierende Schwäche: Der Kern des CMS konnte zu wenig und musste durch Module erst einmal nutzbar gemacht werden. Dieser händische Aufwand entfiel mit Drupal 7, weil dieses schon einige essentielle Module mitbringt. Ich konnte diese Seite mit wenig Arbeit in Drupal 7 umsetzen und bin zufrieden damit.

Frei nach dem Motto "Code, den ich nicht selbst pflegen muss, ist guter Code", läute ich hiermit das langsame aber sichere Ende von Enticore ein. Die Plugins von Enticore, für die es in Drupal noch keine Entsprechung gibt, werde ich portieren.

Ein kurzer Tipp, wie man sich das Leben mit angepassten Projekten vereinfachen kann. Dazu nehme man ein beliegiges Open Source Projekt, dass man anpassen muss, bevor man es benutzen möchte. Das Problem dabei: Wie integriert man eventuelle neue Versionen?

Die Lösung dazu: git (das Versionskontrollsystem). Die Idee ist so einfach wie genial. Zuerst importiert man den initialen Stand der Software. Diesen Stand brancht man in 2 Richtungen ab:

1. Der offizielle Stand der Software (upstream)
2. Meine eigenen Änderungen (master)

Jetzt kann im "master" Branch wie gewohnt angepasst werden. Sobald eine neue Version der Software erscheint wechselt man in den "upstream" Branch und importiert die neue Version. Sobald man mit git den Branch "upstream" wieder in den "master" merged, bekommt man die Änderungen, die durch die neue Version hinzugekommen sind.

Aber was macht man, wenn man erst zu spät feststellt, dass man sich das Leben mit git so einfach machen kann?

Ganz einfach: Man erstellt den Branch "upstream" indem man ihn vom "master" abspaltet. Jetzt wechselt man in diesen Branch, löscht den gesamten Inhalt und importiert den offiziellen Stand der Sotware (der zu dem Stand im "master" Branch passt, d.h. wenn master eine angepasst Version von 3.4.8 ist, würde man die offizielle Version 3.4.8 importieren). Jetzt würde bei einem Merge natürlich das schlimmste Chaos entstehen. Daher muss man git ein wenig helfen. Wir behaupten einfach, dass alles, was derzeit im "upstream" Branch steckt, bereits zurück in den "master" gemerged wurde:

git checkout master
git merge -s ours upstream

Damit kann man dann genauso wie oben beschrieben arbeiten, also in "upstream" immer den aktuellen Stand importieren und in den master mergen.

Dieser kleine Trick reduziert d die Dauer von 4 Stunden im händischen Vergleich (die damals ein Kollege durchgeführt hat) auf 10 Minuten durch diese Automatisierung. Ein anschließendes Testen ist allerdings trotzdem angebracht.

Ich habe heute ein Problem mit der Seitengenerierung von Maven gehabt. Für die Seitengenerierung verwende ich unter Anderem das maven-project-info-reports-plugin. Dieses Plugin erzeugte bei jeden Aufruf eine Exception, die nicht direkt einleuchtend war:

java.lang.ArrayIndexOutOfBoundsException: 1
    at org.apache.maven.doxia.module.xhtml.XhtmlSink.tableCell(XhtmlSink.java:791)
    ....

Das Problem dabei war, dass die Version des maven-site-plugins zu alt war. Nachdem ich folgendes in die pom.xml des Projekts eingetragen hatte, funktionierte es:

 <build>
  <plugins>
   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-site-plugin</artifactId>
    <!-- Version 2.3 oder neuer wird für das maven-project-info-reports-plugin benötigt -->
    <version>2.3</version>
   </plugin>
  </plugins>
 </build>

Diese kleine Änderung ist durchaus entscheidend

Nachdem mein alter Druckern, ein Canon i3000, leider kaputt gegangen ist, wurde er durch einen Netzwerkdrucker ersetzt. Damit ist es möglich, von meinem Rechner oder meinem Netbook zu drucken. Aus Kostengründen bin ich beim Brother DCP-585CW gelandet, der neben einer WLAN-Karte auch einen Scanner besitzt. Diesen hatte ich bisher nicht in Benutzung, weil mein alter Epson 3590 Perfection immer gut funktionierte. Doch auch dieser scheint nicht mehr so ganz zu wollen.

Daher habe ich versucht den Scanner des Brother unter Linux zu benutzen. Brother stellt direkt offizielle Treiber für Linux zur Verfügung und beschreibt im Detail, wie man den Treiber installiert. Doch dieser weigerte sich mit Händen und Füßen. Auch die Anleitung von Ubuntuusers brachte nicht den Durchbruch. Nach längerer Recherche fand ich die Lösung im Gentoo Forum:

In der /etc/sane.d/dll.conf fehlte bei mir die folgende Zeile:

brother3

Danach funktionierte der Scanner endlich. Allerdings musste ich dann herausfinden, dass die Optionen von "scanimage" wohl proprietär sind. Der alte Scanner kannte '--mode=Lineart', der neue Scanner verwendet '--mode="Black & White"'.

Für den zuvor beschriebenen Mailserver wird neben dem Empfang natürlich auch der Versand benötigt. Bisher hatte ich meine E-Mail-Clients so eingestellt, dass sie beim Versand direkt an den E-Mail-Server der E-Mail-Adresse senden. Dies hat den Nachteil, dass man in jedem Client die Passwörter neu eingeben muss. Daher war die Idee einen zentralen Server auf Postfix-Basis auf dem gleichen Rechner wie dem IMAP-Server zu betreiben, der dann SMTP-Relay macht.

Dieses Setup hatte ich vor mehreren Jahren bereits ausprobiert und hatte die Annahme, dass die Einrichtung genauso funktioniert. Allerdings ist SMTP-Relay heute auf Grund des Spam-Aufkommens bedeutend restriktiver. So erlaubt z.B. der Mailserver der Domain "christophbrill.de", das ausschließlich E-Mail mit Absenderadressen von "@christophbrill.de" weitergereicht werden. Da ich auch im Besitz einer Freemail-Adresse bin, würden diese E-Mail immer abgelehnt. Also war die einzige Option einen Relay pro Absender zu verwenden. Glücklicherweise kann Postfix dies von Hause aus.

In der Datei /etc/postfix/main.cf wird zusätzlich folgendes benötigt

smtp_sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_mechanism_filter = plain, login

Damit wird das Relaying pro Sender aktiviert. Jetzt müssen natürlich noch die Absender und relayhosts konfiguriert werden. In der Datei /etc/postfix/sender_relay stehen dann Einträge der Form

emailadress1@irgend-ein-provider.de   smtp.irgend-ein-provider.de

und in der /etc/postfix/passwd stehen dann die zugehörigen Zugangsdaten

emailadress1@irgend-ein-provider.de   benutzername:passwort

Bei mir sind dabei folgende Fehler aufgetreten, die man in /var/log/mail.err:

fatal: open database /etc/postfix/sender_relay.db: No such file or directory

Das passiert dann, wenn man postmap hash:/etc/postfix/sender_relay noch nicht aufgerufen hat

Relay access denied

Dieser Fehler tritt auf, weil Postfix per Default in mynetworks nicht mein privates Netzwerk stehen hat und in der Standardkonfiguration nur Hosts aus dem privaten Netzwerk einen Relay machen dürfen.

SASL authentication failed; .... no mechanism available

Dieser Fehler tritt auf, weil Postfix per Default keinen SASL-Mechanismus vorgibt. Mit Hilfe des Parameters smtp_sasl_mechanism_filter lässt sich dies leicht steuern.

Alles in Allem war das SMTP-Relay in weniger als einer halben Stunde eingerichtet und funktioniert jetzt problemlos. Meine E-Mail Clients "reden" jetzt nur noch mit dem zentralen Server, was den Konfigurationsaufwand pro Arbeitsplatz minimiert (ok, es ist nur Desktop-Rechner und ein Netbook, aber es geht ja ums Prinzip ;-).

Ich habe vor kurzem ein IMAP-Mailserver auf Basis von Dovecot installiert. Dieser dient als Ersatz für mein vorheriges Setup auf Basis von Courier-IMAPd + Procmail. Der Hauptbewegrund war Sieve, eine modernes Mail-Sortier-und-Filter-System.

Bisher funktionierte mein Server so: fetchmail ruft die E-Mails ab, übergibt sie an den SMTP-Server postfix, der übergibt sie an procmail (der sie mit Hilfe der .procmailrc sortiert) und sie können dann über courier-imapd abgerufen werden. Das klingt nicht nur kompliziert, sondern ist es auch.

Jetzt funktioniert es einfacher: fetchmail ruft die E-Mails weiterhin ab, übergibt sie aber an dovecot (an den deliver LDA um genau zu sein) und wir sind fertig. Kürzer. Weniger fehleranfällig. Konfigurierbar über die managesieve-Erweiterung für Thunderbird (was der Hauptbeweggrund war, um von .procmailrc weg zu kommen).

Eigentlich sind dafür relativ wenig Konfigurationsoptionen notwendig:

1.) In der dovecot.conf im protocol lda as Sieve-Plugin aktivieren.

2.) In die /etc/fetchmailrc

mda "HOME=/home/%T /usr/bin/sudo -u %T /usr/lib/dovecot/deliver"

eintragen

3.) Mittels visudo folgenden Filter eingeben:

fetchmail ALL=(ALL) NOPASSWD:/usr/lib/dovecot/deliver

Der einentliche Trick dabei ist es, dass fetchmail bei mir als globaler Service ausgeführt wird, und zwar als eigener Benutzer 'fetchmail'. Ein direkter Aufruf von deliver allerdings hat zur Folge, dass die E-Mails im Ordner des Fetchmail-Benutzers landen und nicht dem in der fetchmailrc konfigurierten(!). Diese kleine Information ist extrem entscheidend für das erfolgreiche Abrufen von E-Mails und hat mich ein paar Stunden des Grübelns gekostet. Jetzt funktioniert alles und ich kann endlich wieder E-Mails abrufen... und vor allem sortieren :-)

Ich bin derzeit mal wieder dabei an Opengate rumzuexperimentieren. Dazu benötige ich ogreopcode, einen Wrapper der Ogre (eine 3D Engine) mit Opcode (einer Bibliothek zur Kollisionserkennung). Allerdings war dieser nicht mit der neuesten Ogre Version (1.7.1) kompatibel. Daher habe ich folgende Ändernungen gemacht:

===================================================================
--- src/IOgreCollisionShape.cpp (revision 417)
+++ src/IOgreCollisionShape.cpp (working copy)
@@ -264,7 +264,7 @@
                if(!mHasCostumTransform)
                {
                        getParentSceneNode()->_update(true, true);
-                       getParentSceneNode()->getWorldTransforms(&mFullTransform);
+                       mFullTransform = getParentSceneNode()->_getFullTransform();
                }
                return mFullTransform;
        }
Index: src/OgreBoxCollisionShape.cpp
===================================================================
--- src/OgreBoxCollisionShape.cpp       (revision 417)
+++ src/OgreBoxCollisionShape.cpp       (working copy)
@@ -204,7 +204,7 @@

                calculateSize();

-               mParentNode->getWorldTransforms(&mFullTransform);
+               mFullTransform = mParentNode->_getFullTransform();
                //mFullTransform = mParentNode->_getFullTransform();

                return true;
Index: src/OgreMeshCollisionShape.cpp
===================================================================
--- src/OgreMeshCollisionShape.cpp      (revision 417)
+++ src/OgreMeshCollisionShape.cpp      (working copy)
@@ -287,8 +287,7 @@
                }

                mParentNode = mDummyNode;
-               //mFullTransform = mEntity->getParentSceneNode()->_getFullTransform();
-               mParentNode->getWorldTransforms(&mFullTransform);
+               mFullTransform = mParentNode->_getFullTransform();
                return rebuild();
        }

Das ist einer der großen Vorteile von Open Source: Wenn es nicht funktioniert, hat man die Chance herauszufinden warum nicht.

Nerdy-Lines sind Icons für den Linux Desktop, die einen zeichnerischen Stil verwenden.

Ich habe eben gesehen, dass meine Nerdy-Lines Icons mittlerweile mehr als 100000 Mal heruntergeladen wurden. Ich hatte sie eigentlich nur für mich erstellt und dachte nicht, dass das Interesse so groß ist. Daher freue ich mich um so mehr, dass die Icons eine sinnvolle Verwendung haben.

Da das Design sich leicht auf Enticore portieren ließ, hatte ich dies bereits 2 Tage nacht der esten Ankündigung migriert. Allerding scheute ich mich davor die Inhalte zu migrieren. Zum Einen fehlte mir ein Downloadplugin, zum anderen die Zeit. Das Downloadplugin habe ich jetzt geschrieben und die Zeit habe ich mir genommen.

Im Idealfall sollte es keinen Unterschied zu Seite vorher geben, rein von der Bedienung. Falls doch Probleme auftreten, kann mir das gerne mitgeteilt werden.

Nachdem enticore mitlerweile einen durchaus produktiven Stand erreicht hat, habe ich damit begonnen diese Webseite in das CMS zu portieren. Derzeit bin ich dabei, das Design zu migrieren. Anschließend kommen die Inhalte. Dabei ist die Downloadsektion noch ein offener Punkt. Derzeit lässt sich diese Funktionalität nicht mit Enticore abbilden und es scheint mir, dass es sich dabei nicht gerade um eine wiederverwertbare Funktion handelt. Außerdem stellt sich die Frage: Braucht noch jemand meine Mitschriften von vor 5 Jahren?

Es freut mich immer wieder zu sehen, dass meine Arbeit nicht vollkommen ungenutzt bleibt. So habe ich heute abend folgendes bei Spiegel TV entdeckt.

Wie dort zu sehen ist, wurde ein Haus, dass ich für Lincity-NG entworfen habe, dort verwendet.

Ich habe für den Fenstermanager metacity einen Rahmen entworfen, der dem von Windows Vista ähnelt. Damit ist es möglich, GNOME aussehen zu lassen wie Windows Vista. Den Rahmen findet ihr bei GNOME ART.

Ich bin gerade durch Zufall über diese Seite von McAfee gestolpert. Laut deren Aussagen ist meine Seite unbedenklich. Wer das nicht glaubt, kann sich selbst überzeugen:
http://www.siteadvisor.com/sites/egore911.de/

Ich habe beschlossen meine (nicht existente) Freizeit sinnvoll zu nutzen und begonnen ein Spiel zu schreiben. Dabei handelt es sich um ein Remake des Klassikers Jumpgate. Ich habe ihn, kreativ wie ich bin, Opengate getauft und entwickele ihn unter GPL auf opengate.sourceforge.net. Derzeit gibt es noch nicht viel zu sehen außer ein paar Screenshots von den Modellen der Schiffe, die ich erstellt habe. Es sind auch schon erste Gehversuche mit OGRE3D dort zu finden.



An dieser Stelle muss ich einfach auch nochmal meiner Freundin danken, dass sie so viel Verständnis hat mich bis spät abends an so einem Blödsinn arbeiten zu lassen. Ich liebe dich, Luba!

Inspiriert durch einen Kommentar meiner Schwester, dass sie bei dem Namen "egore" immer an ein Quitsche-Entchen denken muss, hab ich mir ein Logo gezeichnet. Ich fand die Idee einfach zu genial, um sie zu verwerfen :-)

Anmerkung: Dieses Logo unterliegt meinem ganz persönlichen Copyright und jegliche Verwendung bedarf meiner Erlaubnis. Zu deutsch: proprietär