Archive for the 'Virtuelle Welt' Category

Malspaß mit MyPaint

Nach dem Anpassen des Linuxkernels für das eigene System, ist mir nun etwas Zeit geblieben, um sich mit etwas Kreativen zu entspannen. Samstags bin ich dann auch über die 1.0.0 Version von MyPaint, was ich bis dahin nicht kannte, gestolpert.
Was ich so in den Gallerien zu MyPaint gesehen hatte, beeindruckte mich derartig, dass ich das Programm unbedingt antesten wollte.
Die vorhandenen Pinsel haben mir in ihrer Anpassbarkeit gefallen und dass man verschiedene Strukturen auf die virtuelle Leinwand malen konnte.

Und das ist bei mir heraus gekommen. Wahrscheinlich wäre man mit einem Grafiktablet besser gefahren als mit einer Lasermouse, aber derartiges ist mir leider noch nicht in die Hände gefallen.

Wüste - erstellt mit MyPaint

Wüste - erstellt mit MyPaint

Neuer Kernel, neues Glück

Vor einiger Zeit habe ich das Läppi ein bisschen aufgeräumt und frisch Slackware 13.37 installiert. Lief auch alles prima – oder wie man gern sagt: out of the box – nur fror das System gerne mal komplett ein, wenn man entweder aus dem Standby (Suspend, Suspend to RAM) oder dem Ruhezustand (Hibernate, Suspend to Disk) kam. Da ging nix mehr und ich konnte am Ende nur auf den Knopf zur Zwangsabschaltung drücken.

Das trat so sporadisch und willkürlich auf, dass dieses Fehlverhalten keiner bestimmten Anwendung zu zuschreiben war. Ein Blick in die Logfiles ergab nichts genaueres, so dass ich Google fragen musste.

Try and Error

Meine erste Anlaufstelle führte das Problem auf einen falsch ausgewählten Mousestreiber zurück, was ich aber schnell als Ursache ausschließen konnte. Ein weiterer Beitrag in einem einschlägigen Forum führte dann dazu, dass ich mich auf die Grafikkarte bzw. dessen Treiber als Störfaktor einschoss. Schließlich habe ich auch eine Intel-Grafikarte am Laufen. Ich machte mich an die Konfiguration des Xservers, installierte Mesa, libdrm und später den Intel-Treiber in einer neueren Version. Resultat war in allen Fällen, dass mir früher oder später das System einfror.
Gut, das haste jetzt alles durch, jetzt kannst du nur noch einen anderen Kernel kompilieren, dachte ich an dieser Stelle.

Kernel Wahl

Zuerst lud ich mir die Kernelversion 3.1.1 runter und bastelte mir diese zurecht. Mit dieser Variante hatte ich wenigstens das Problem mit dem wilkürlichen Einfrieren erschlagen, nur merkte ich dann, dass mir alle naselang die verschlüsselte Netzwerkverbindung abriss – arrgh! Ok, ich hätte besser nicht den zu damaligen Zeitpunkt neuesten Kernel nehmen sollen. Schlussendlich griff ich dann zu 3.0.9 und testete wieder.

Aktuell kann ich sagen, dass das System in dieser Variante tadellos läuft.
Continue reading ‘Neuer Kernel, neues Glück’

Kleiner Tapetenwechsel

Kurz vor dem Wochende habe ich eine Auffrischung des Bloglayouts vorgenommen. Seit 2008 habe ich designtechnisch nicht viel unternommen, so dass ein Tapetenwechsel im Grunde längst überfällig war.

Ich hoffe es gefällt dem ein oder anderen. ;-)

wxWidgets für MinGW

Wie angekündigt, sorge ich nun für eine Anleitung, wie man wxWidgets kompiliert und in einem einfachen Programm verwendet.

Vorbereitung:

wxWidgets Version: 2.18.12
MinGW Version: 3.4.5
MSYS Version: 1.0.11
Netbeans Version: 6.8 mit Plugin für C/C++

wxWidgets 2.18.12 bzw. aktuelles Stable Release als tar.gz herunterladen und in einen beliebigen Ordner mit Schreibrechten für den aktuellen User entpacken.

wxWidgets Bibliotheken kompilieren

Der Einfachheit halber sollte man MinGW im Ganzen – vor allem mit gcc und g++ – installiert haben. Daneben benötigt man die MSYS Umgebung. Beides installiert man, um Fehler zu vermeiden unter C: bzw dem aktuellen Laufwerk mit Windows. Es empfielt sich danach die bin-Verzeichnisse von msys und MinGW in die PATH Umgebungsvariable aufzunehmen.

Configure und make:

Man sollte nun nachdem wxWidgets entpackt ist die MSYS eigene Shell msys.bat (welche man im Installationsordner von msys findet) starten. Dort wechselt man nun in das wxWidgets-Verzeichnis.

cd /C/Users/AUser/wxWidgets-2812

In dem jeweiligen Ordner sollte sich eine Datei mit dem Namen configure befinden. Auf der msys-Shell gibt man zum Vorbereiten der Quellen folgendes ein:

./configure --enable-optimise --enable-static --disable-shared --enable-monolithic

Dann erhält man eine im Code optimierte, statische Bibliothek. Wer anderes konfigurieren möchte erhält mittels ./configure --help Infos zu weiteren Optionen. Ist alles ohne Abbrüche über die Bühne gegangen, so beginnt man die Buildvorgang mit einem einfachen make auf der msys-Shell.

Die Bibliotheken:

Die Bibliotheken liegen innerhalb des lib-Ordners des wxWidgets-Verzeichnis und haben hier die Endung auf .a .

Weiter gehts auf der nächsten Seite:
Continue reading ‘wxWidgets für MinGW’

Frisch kompiliert: wxWidgets

Das vergangene Wochenende habe ich genutzt um den Einstieg in wxWidgets wagen. Dazu war es erst einmal nötig aus den Quellen die Bibliotheken von wxWidgets zu erstellen. Ich persönlich habe dafür den MinGW in Kombination mit MSYS benutzt. Mit Cygwin sollte es aber auch möglich sein. Das Erstellen war an sich kein Problem, allerdings ein einfacheres wxWidgets-Programm kompilieren brachte einige Schwierigkeiten mit sich. Oft konnte der eingebundene Header trotz gegebener Includeverzeichnisse nicht gefunden werden. War dieses Problem gelöst, tauchten plötzlich Probleme beim Kompilieren des Programms – z.B. dass die Definition von strdup nicht auffindbar sei, um einen Ausschnitt aus den über 100 Fehlern zu geben – auf.

Dass ich da noch alle Haare auf dem Kopf und nicht vor Zorn ausgerissen habe, ist ein Wunder. Schließlich habe ich dann einen aller letzten Versuch gestartet, der unter der Bedingung lief, wenn’s jetzt immer noch nicht nach all den Versuchen funktioniert, dann lasse ich es. Das regt mich zwar auch übel auf, weil ich dann gescheitert bin, aber ich kann mir nicht vorwerfen lassen, dass ich es nicht versucht hätte.

Zum Glück ließ sich mit dem letzten Versuch das Programm erstellen. Damit ich mich bei späteren Ansätzen nicht erneut ärgere, habe ich mir vorsorglich eine Anleitung geschrieben, die ich dann noch hier rauf stellen werde.

C++ und grafische Oberflächen

Wenn ich in C bzw. C++ unterwegs bin, dann meist im Bereich von Konsolenanwendungen – also Programme, die in einem kleinen, schwarzen Fenster mit weiser Schrift ausgeführt werden. Programme mit bunten Buttons und sonstigen grafischen Komponenten sind bei mir bisher Mangelware.
Mir fehlt in dieser Hinsicht ein Einstiegspunkt, vor allem weil es neben den durch (kommerzielle) IDE’s bereitgestellte GUI Toolkits auch viele eigenständige Pakete. Was Windows angeht, bin ich mir unsicher zwischen MFC [1] und WinForms [2]. Schließlich gibt es noch eine freie, für verschiedene Plattformen verfügbare Alternative namens wxWidgets [3].
In Java hatte sich diese Frage mir nie gestellt, da es schließlich entsprechende Bibliotheken in der Standardbibliothek von Java bereits gibt und man daher nicht nach externen Paketen suchen muss. Drei Wahlmöglichkeiten und ich stehe mittendrin. Ich weiß auch nicht, woran ich eine Entscheidung fest machen soll. Es sollte für den Einstieg nicht zu kompliziert sein.

[1] Wikipedia: Microsoft Foundation Classes
[2] Wikipedia: Windows Forms
[3] wxWidgets Projektseite

Bluescreen: Wie lang ist das her?

Just for fun grabe ich die alte Digitalkamera (eine Rollei dp300) aus, um deren Funktionalität als Webcam-Verschnitt zu testen. Die Treiber waren nach kleinerem Gefummel von der CD installiert. (Treiber für aktuellere Windows Versionen über XP hinaus, lassen sich auf der Herstellerseite leider nicht downloaden.) Dem Setup fehlt plötzlich eine JPEGCODE.dll, die sich aber auf der Installations-CD im Ordner driver\jpegcode findet.
Zum Aufnehmen eines Videos musste ich die Kamera vor einschalten in einen speziellen Modus (PC Kamera) geschalten, bevor ich mit dem VLC erste Bilddaten abgreifen konnte. Funktionierte auch so weit, nur die Auflösung von 160 zu 120 (Breite x Höhe) war da nicht so ganz berauschend. Ok, versuchste es mal mit anderen Einstellungen direkt an der Kamera, dachte ich mir da. Kamera wieder abgestöpselt, die Auflösung von 3.0M (fein) nach 5.0M (normal) und die ISO von 100 nach 200 gewechselt. Wieder im PC Kamera Modus die Rollei dp300 angeschlossen, angeschaltet und dann passiert’s: Bluescreen!

Bluescreen PAGE_FAULT_IN_NONPAGED_AREA

Windows zeigt mir mit einem PAGE_FAULT_IN_NONPAGED_AREA seine kalte Schulter

A problem has been detected and Windows has been shut down to prevent damage to your computer.
PAGE_FAULT_IN_NONPAGED_AREA
….

Ziemlich verdutzt vorm Läppi sitzend, gab ich von mir: „Bluescreen. Das hatte ich schon lange nicht mehr.“
Ist bei mir schon ein paar Jahre her, dass Windows mich derart hat abblitzen lassen.
Nach einem zweiten Versuch mit diesen Einstellungen und einem erneuten Bluescreen, blieb mir nix anderes übrig, die Einstellungen der Kamera wieder zurück zunehmen, was wieder zu einem normalen Funktionieren führte.

LXDE: Ich versuch’s mit selbst bauen

Mein zweiter Anlauf in Richtung des selbst Kompilieren einer Desktopumgebung für Linux, heißt LXDE. Der Versuch mit Gnome war ja nicht wirklich mit Glück beschieden. Ich hatte zwar ein automatisiertes Werkzeug zum Erstellen von Gnome (jhbuild), dennoch traten immer wieder Probleme auf und zum Schluss war die Festplatte voll. :-(
Ok, dann versuche ich es mal mit dem „schönen Kleinen“, wir mir mal ein Freund vorgeschlagen hat. Das schöne Kleine hört auf den Namen LXDE und ist nach einigen Versuchen lauffähig. Zuerst hatte ich mir den Code aus einem git Repository (git://git.sourceforge.net/lxde/[...]) geholt und musste feststellen, dass dieser eher mehr zur Entwicklung als für den Gebrauch gedacht ist. Stattdessen soll man auf der entsprechenden SourceForge Seite die Pakete herunterladen.
Die Pakete habe ich dann in einen Ordner entpackt. Danach muss man jedes Paket mittels

./configure --sysconfdir=/etc && make && make install

kompilieren. Dabei ist eine kleine Reihenfolge der zu bauenden Pakete zu beachten.

  1. menu-cache
  2. libfm
  3. pcmanfm

Daneben muss man auch ein paar Abhängigkeiten zu beachten. Für Slackware 13.1 habe ich folgende zusätzliche Pakete installieren müssen:

Hat man alles beisammen, kann es auch los gehen. Allerdings habe ich bei einigen Paketen feststellen müssen, dass sich make leicht in einer Endlosschleife verliert, wenn es Dinge im po Unterordner einiger Pakete abarbeiten muss. Indem ich po aus SUBDIRS entfernt habe – ich spreche hier vom Makefile, was im selben Ordner wie der po-Ordner liegt – bin ich um dieses Problem herum gekommen. Ich liste am besten gleich auf, bei welchen Paketen dieses Problem auftritt:

  • lxrandr
  • lxsession-edit
  • lxlaucher
  • lxshortcut

Besondere Vorsicht ist beim kompilieren von lxdm, dem Displaymanager von LXDE, geboten. Dieses Paket nutzt PAM, was man auf einem Slackware System allerdings nicht finden wird. Man hat zwar über den Schalter –-without-pam im configure-Skript eine scheinbare Möglichkeit auch ohne PAM zu kompilieren, nur wird dann beim Durchgang mit make dieser Fehler auftauchen:

gcc -DHAVE_CONFIG_H -I. -I..    -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -DCONFIG_FILE=\"/etc/lxdm/lxdm.conf\" -DXSESSIONS_DIR=\"/usr/local/share/xsessions\" -DLXDM_DATA_DIR=/usr/local/share/lxdm -DLXDM_NUMLOCK_PATH=\"/usr/local/libexec/lxdm-numlock\" -I/usr/include/ConsoleKit/ck-connector -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include   -Werror-implicit-function-declaration -Wall  -g -O2 -DLXDM_XCONN_XCB -MT lxdm_binary-lxdm.o -MD -MP -MF .deps/lxdm_binary-lxdm.Tpo -c -o lxdm_binary-lxdm.o `test -f 'lxdm.c' || echo './'`lxdm.c
lxdm.c:152: error: expected ')' before '*' token
make[2]: *** [lxdm_binary-lxdm.o] Error 1

Wie gut, dass ich auch ein paar Brocken C kann. Also den vi geschnappt und an diese Stelle gegangen:

static void close_pam_session(pam_handle_t *pamh)

Auf mich machte der Code einen schlüssigen Eindruck. Beim Überfliegen des Quelltextes wusste ich auch gleich, dass die Header nur unter bestimmten Voraussetzungen eingebunden werden. Wahrscheinlich war pam_handle_t dem gcc unbekannt. Weil ich nicht gerade Bock darauf hatte, PAM einzurichten, nur damit die Authentifizierung der Benutzer darüber laufen kann, habe ich kurzum die oben genannte Funktion auskommentiert. Tja, dann hieß es erstmal wieder compile and pray, wie ich so schön zu sagen pflege. Resultat davon war ein fertig kompiliertes und installierbares lxdm.

Da diese Klippe umschifft und die Pakete vorerst unter /usr/local installiert sind, muss noch ein Symlink erstellt werden:

ln -s /usr/local/bin/startlxde /etc/X11/xinit/xinitrc.lxde

Über xwmconfig lässt sich dann xinitrc.lxde auswählen und man kann einen Versuch mittels startx machen. Startet man in Runlevel 4, so übernimmt XDM die Rolle des grafischen Logins.

Gnome unter Slackware 13.1 bauen – Teil 2

gtk+ und seine Dokumentation

Wie zuletzt angekündigt, macht mir nun nach dem NetworkManager, gtk+ im Sinne seiner Dokumentation Probleme. Die Bibliothek gtk+ scheint wohl zu kompilieren, doch wenn die Doku ins Verzeichnis gepackt werden soll, muss jhbuild den Build-Vorgang abbrechen.

mv: cannot stat `gtk-tut': No such file or directory
mkdir: cannot create directory `html/images': No such file or directory
cp: target `html/images' is not a directory

liest es sich über den Ausgaben vom make. Auf die Doku. kann ich der Einfachheit halber verzichten. Ich habe versucht das configure-Skript mit anderen Optionen auszuführen, was auch nach mehreren Durchgängen fehlschlug.
Gefixt habe ich es dann mit Anpassen des Makefiles in checkout/gnome/gtk+/docs, wo ich die Ordner faq, reference und tutorial in der SUBDIRS Anweisung gelöscht habe.

nspr und nss wird nicht heruntergeladen

Bei beiden hilft’s, wenn man auf die Shell wechselt und wget wie folgt aufruft und dabei das s aus https entfernt:

wget --no-check-certificate --continue http://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v4.8.6/src/nspr-4.8.6.tar.gz -O ~/checkout/gnome/nspr-4.8.6.tar.gz

nspr lies sich dann kompileren, nur bei nss musste ich aufgeben, da es verschiedene Header-Dateien wie z.B. prtypes.h vermisst.

glib-networking

Vom einen Problem stolperte ich zum nächsten. Diesmal wurde nach Zertifikaten verlangt. Da blieben dann schlussendlich nur zwei Möglichkeiten über.

  1. Die Zertifikate erstellen (für jemanden, der damit noch nie mit zu tun hatte, ein umständlicher Weg, der How-To lesen nach sich gezogen hätte)
  2. Die Option –without-ca-certificates verwenden (hier ohne zu wissen, welche Nachteile dadurch entstehen)

Ich habe mich dann für Lösung 2 entschieden, weil mir das mit openssl nich so geheuer war. Für einige Zeit lief dann auch die Build-Vorgang weitgehend ohne mich durch.

gnome-disk-utility

Bei diesem Stück Software musste ich anfangen Abhängigkeiten sowie deren Abhängigkeiten auf zu lösen. gnome-disk-utility fordert ein vorinstalliertes udisks was wiederum libatasmart >= Version 1.14 und libsgutils2 haben wollte. Die beiden Bibliotheken aufzutreiben war schwerer als erhofft. Vorallem, weils die Teile eben bevorzugt für Debian oder für Red Hat Systeme gibt. Slackware ist da weder das eine noch das andere, da es die älteste noch aktive Distri ist und damit vom Alter her noch vor Debian kommt.

gnome-keyring-3 bekomme ich nicht kompiliert

Der gnome-keyring-3 war das nächste Modul, dessen Build-Vorgang ich aufgeben musste. make vermutet in der /usr/include/sys/capability.h in Zeile 97 einen Fehler, den ich nicht ersehen konnte. Und bevor ich etwas verschlimmbessere, lasse ich es lieber.
So langsam geht mir auch der Festplattenplatz aus. Und das wird aller Wahrscheinlichkeit nach dazu führen, dass ich endgültig abbrechen muss. Immerhin habe ich es mal versucht und festgestellt, dass das kein Unterfangen ist, was sich so an einem Wochenende erledigen lässt. Dazu muss man dann doch nach den Fehlerquellen suchen und falls möglich beheben.

Gnome unter Slackware 13.1 bauen – Teil 1

So aus der Laune heraus, habe ich gestern Abend mal angefangen mit dem Tool jhbuild erste Pakete aus dem Kernpaket von Gnome zu kompilieren. Wie man jhbuild einrichtet und vorbereitet, ist dem jhbuild Manual zu entnehmen. Für Slackware fehlte noch automake in den Versionen 1.9 und 1.8.
Ab da zieht sich jhbuild die Pakete selbst vom git-Repository, legt sie in einen lokal angelegten Ordner – in meinem Beispiel heißt er checkout/gnome. Zusätzlich muss noch unter /opt ein weiterer Ordner namens gnome angelegt werden, auf dem man als normaler User Schreibrechte haben sollte, da jhbuild sich darüber beschwert, wenn es als root ausgeführt wird.

Während die einzelnen Pakete kompiliert wurden, musste ich bei ein oder dem anderen Paket noch etwas basteln. Zum einen wurde PAM notwendig. Slackware ist eines der wenigen Linux-Systeme auf denen PAM nicht zum Einsatz kommt.
Wesentlich trickier wurde es beim Kompilieren des unter Gnome verwendeten NetworkManagers, wo mir das configure-Skript dieses verkündete:

Libtool library used but `LIBTOOL' is undefined. The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' to `configure.in' and run `aclocal' and `autoconf' again. If `AC_PROG_LIBTOOL' is in `configure.in', make sure its definition is in aclocal's search path.

Häh? Was stimmt denn nicht, fragte ich mich nur. Ich begann zu googeln, doch die gegebenen Lösungsvorschläge zeigten bei mir keine Wirkung. Nur durch einen Zufall kam ich auf die Idee die Datei libtool.m4 (die in /usr/share/aclocal liegt) in /opt/gnome/share/aclocal zu kopieren.
Dann lief es erstmal wieder, zumindest für den NetworkManager. Inzwischen meldet sich gtk+ mit Schwierigkeiten.