Grischa

Ein weiteres kleines Detail Problem mit Unity konnte ich auch lösen. Wenn man weiß, wie es geht, ist die Lösung sogar ziemlich simpel. Ich hatte mir einige eigene Desktop Dateien für den Launcher erzeugt, welche ich auch über das Dash aufrufen wollte. Dies funktionierte jedoch nicht z.B. bei selbst kompilierten Anwendungen.

Das Dash sucht seine Einträge u.a. im Verzeichnis /usr/share/applications., in welches normal installierte Programme ihre Startkonfigurationen ablegen. Man kann die Starter Dateien des Systems für seinen Benutzer überschreiben, indem man eine gleichlautende Desktop Datei in sein Home Verzeichnis unter ~/.local/share/applications ablegt.

In dieses Verzeichnis hatte ich z.B auch die Magicdraw Datei abgelegt, die ich mir für den Launcher konfiguriert hatte. In dieser Datei hatte ich Anwendungskatgorien hinterlegt, in der Hoffnung, dass das Programm so in der Dash Suche und in den entsprechenden Kategorien des Dashs erscheint. Dies war nicht der Fall, die Anwendung wurde nicht gefunden.

Die neue Oberfläche von Ubuntu, Unity, kann mir im großen durchaus gefallen, in Details geht sie mir teilweise aber ganz schön auf die Nerven. Eines dieser Details konnte ich jetzt für mich lösen: Manche Java Programme machen Probleme im Launcher. Man kann diese genauso wie andere Programme problemlos über die bekannten Mittel in den Unity Launcher packen, sie verhalten sich dort aber sehr untypisch: Wenn man diese aus dem Launcher startet wird ein neuer Eintrag mit dem Namen win0 im Launcher sichtbar, der kein Icon sondern nur ein Fragezeichen hat.

Man kann dieses Programm dann auch nicht wie gewohnt über das eigentliche Launcher Icon verwalten: Es hat keine Markierung für eine gestartete Instanz des Eintrags, ein Klick auf dieses Icon macht nicht die Instanz sichtbar, sondern startet eine neue, die wieder einen weiteren temporären Eintrag im Launcher erzeugt. Unity erkennt also offenbar nicht, dass das gestartete Programm zu dem ursprünglichen Launcher Eintrag gehört, sondern hält es für ein anderes Programm und erstellt nach Unity Launcher Logik einen entsprechend neuen temporären Eintrag.

In diesen Fällen muss man Unity also expliit mitteilen, wie der Thread heißen wird, der von diesem Launcher gestartet wird.

Neulich fand ich diesen Tweet, der mein Interesse weckte:

Screencasts sind Videos, mit denen man z.B. Arbeitsabläufe am PC vorstellen kann, indem man die Vorgänge auf seinem Monitor aufnimmt und dabei per Audio Kommentar beschreibt, was man gerade tut. Ich war etwas erstaunt, dass dies mit Linux Bordmitteln wirklich so einfach gehen soll, ich kannte für Screencasts vor allem (teilweise kostenpflichtige) Programme, die dies taten. Somit habe ich das mal ausprobiert.

Der Trick bei obigem Kommando ist der -i Parameter. Hier wird als Eingabe für das Video einfach der Bildschirm abgegriffen. Bei mir klappte der im Tweet genannte Aufruf allerdings leider nicht korrekt, außerdem erzeugt dieser keinen Ton. Der Aufruf, der bei mir funktionierte, war folgender:

dimension=1600x900
aspect=1.7777
ffmpeg -f alsa -i plughw:0 -f x11grab -s $dimension -r 24 -b 100k -bf 2 -g 300 -i :0.0 -ar 22050 -ab 128k -acodec libmp3lame -vcodec libxvid -aspect $aspect -sameq screencast.avi

Wobei dimension die Auflösung meines Monitors und aspect die dazu passende Aspekt Ratio ist (16:9).

Das Resultat, das dabei entsteht, war nicht ganz, wie ich das gerne hätte:

• Das Video war in der vollständigen Auflösung meines Monitors, also viel zu groß für einen normalen Screencast
• Mein internes Micro ist ein wenig leise, wenn ich mich nicht direkt davor setze, also musste die Lautstärke ein wenig angehoben werden
• Durch das Anheben der Lautstärke trat das Rauschen allerdings auch deutlicher hervor, weshalb ich eine Rauschunterdrückung benötigte.