Artikel mit Tag projekt
Verwandte Tags
android LG G3 emulation framework lg g3 linksammlung nachhaltigkeit stresstest sustaphones touchpad wileyfox überwachung feedtragón ice-prefer icewm ice-win flame-design snapforx idesk-helper image-sacon izulu listsearch serendipity pc-kombo dsnblog ruby rsspusher autotitle bartleby blogs buzz commentedit dbclean markupcomment nl2p photo pubsubhubbub reallivecomment realtimecomments spamblock_bayes template_editor ursprung simdockSustaphones: Eine Seite für lang nutzbare Smartphones
Sustaphones ist ein von mir gebautes Mashup. Die Seite listet zum einen Telefone auf, die von alternativen Android-Distributionen wie LineageOS unterstützt werden. Außerdem zeigt sie via verlinkten Anleitungen von iFixit wie einfach ihre Batterien auswechselbar sind.
Motivation
Mir geht die Wegwerfkultur bei den Smartphones gegen den Strich. Smartphones sind kleine Computer und mittlerweile unheimlich leistungsstark. Computer wie PCs werfen wir allerdings nicht einfach weg. Am Anfang war es ja noch logisch sie nach maximal zwei Jahren auszuwechseln, zu groß waren die Sprünge der neuen Modelle bei Software, Bildschirmqualität, Speicherplatz und Prozessorleistung. Doch seit schon mehreren Jahren sind die gestern gebauten Telefone für eine lange Zeit konkurrenzfähig. Oder: Sie wären es, wenn sie nicht bewusst als Wegwerfprodukte konzipiert würden. Das passiert auf zwei Wegen. Zuerst mit ausbleibenden Sicherheitsupdates, wodurch es schnell unverantwortlich wird ein ansonsten einwandfreies Gerät weiterzuverwenden. Dann mit dem nicht auswechselbaren Akku, der unweigerlich nach wenigen Jahren seinen Geist aufgeben wird, woraufhin das Gerät dann Schrott ist – falls das Wechseln des Akkus doch möglich ist, ist es oft zu teuer.
Anfang des Jahres hatte ich mich nach Lösungsmöglichkeiten umgesehen. Die Überlegungen landeten dann auch hier im Blog. Linux auf Smartphones könnte ein Ausweg sein, aber war damals noch nicht praxistauglich und ist es wohl auch heute noch nicht. Kommerzielle Android-Telefone mit Nachhaltigkeit als Ziel, wie das Fairphone, sind nicht nur teuer, sondern auch keine komplette Garantie für langfristige Unterstützung. Firmen können pleitegehen. Und das Fairphone 3 zum Beispiel hatte zu dem Zeitpunkt nichtmal Android 10, was mich abschreckte (mittlerweile wurde das Update nachgereicht).
Android mit Communityunterstützung erschien wie die beste Möglichkeit, womit ich auch schon Erfahrung hatte. Doch welche moderne Hardware taugt? Denn selbst wenn ein Gerät von LineageOS oder einem anderen Rom unterstützt wird hilft das ja noch nicht viel, wenn der eingeklebte altersschwache Akku das Gerät in naher Zukunft unnutzbar macht. Ich landete erst beim LG G3 und dann beim LG G5, aber mir fehlte die Übersicht über mögliche Alternativen.
Jedes Android-Projekt wie LineageOS führt zwar Listen welche Hardware es unterstützt, aber welche davon ist reparierbar?
Genau diese Übersicht stellt sustaphones her. Denn es listet viele Smartphones mit Unterstützung für alternative Android-Distributionen, das heißt mit Updates weit über die minimale Herstellerunterstützung hinaus. Und zudem, wie schwierig ein Akkuwechsel ist.
Datenquellen
Die Daten werden von den verlinkten Projekten bereitgestellt, mal mehr, mal weniger direkt.
LineageOS hat ein Wiki mit einer Hardwareliste. Schon die wäre auslesbar, aber noch besser ist, dass sie aus einer Yaml-Datei gewonnen wird die auf Github lebt. Damit hat die Seite direkt Infos zu vielen Geräten, wobei LineageOS auch noch die größte und bekannteste Alternative zum Herstellerandroid ist.
MoKee ROM kenne ich weniger gut. Es ist scheinbar ein asiatisches Projekt, was es interessant macht, da es einige Geräte unterstützt die bei LineageOS fehlen. Leider fand ich hier keine so direkt maschinenlesbare Liste. Aber es gibt auf der Webseite eine Übersicht samt Hardwareinformationen, die lud ich in meine Datenbank.
Bei iFixit war ich überrascht, sogar eine API für genau solche Projekte zu finden. Hervorragend gemacht lieferte sie alle notwendigen Informationen, die Anleitungen, ihre Bewertung und sogar Bilder. Die Arbeit bestand vor allem darin die Namen zuzuordnen, da die sich bei den drei Projekten gerne mal unterscheiden und gerade iFixit mit den eindeutigen Codenamen der Geräte nichts anfangen konnte (falls ich nichts übersah...).
Die zu kombinierbaren Daten für eine hilfreiche Seite waren also vorhanden.
Es gibt noch mehr Möglichkeiten: Wie schwierig ein Bildschirm zu reparierbar ist wäre auch eine interessante Information, und es gibt noch weitere Android-Projekte wie /e/, Paranoid Android und Resurrection Remix OS. Ob ich die Seite in diese Richtung erweitere wird vom Interesse abhängen. Meinungen dazu?
Technik
Sustaphones ist eine statische Seite, die von mehreren handgeschriebenen Ruby-Skripten gebaut wird. Jeweils ein Skript ist dafür zuständig, die Daten von den unterstützten Projekten zu holen und in die Datenbank zu schreiben. Ein zusätzliches baut mit den Daten das HTML der Seite.
Netlify ist derzeit der Hoster, was für solche statischen Seiten superkomfortabel und noch dazu kostenlos ist. Netlify holt sich das generierte HTML direkt von Gitlab.
Beim Design habe ich mich wieder zurückgenommen und ein CSS-Framework eingesetzt, diesmal fiel die Wahl auf Bulma. Die Such- und Filterfunktion ist mit List.js gebaut. Abgesehen davon wird keinerlei Javascript genutzt.
Einige Zeit ging für die Optimierung der Performance drauf, ich orientierte mich dabei an der Bewertung von Chromiums Lighthouse. Dass es eine statische Seite ist half, aber andererseits ist es eine lange Liste, daher war die Performance nicht direkt super. Jetzt werden die Bilder erst nachgeladen wenn sie sichtbar werden, mittels der relativ neuen Browserfunktion. Zudem stammen die Bilder direkt von der iFixit-API, die dafür ein CDN benutzt, das wird preconnectet. Schließlich wird das Javascript mit defer
eingebunden und List.js erst initialisiert wenn der Besucher die Suchfunktion benutzen will. All die Optimierungen zusammengenommen sollte die Seite ziemlich schnell laden.
Fazit und Ausblick
Ich empfand sustaphones direkt als hilfreich. Vorher hatte ich keinen klaren Überblick über Alternativen zum LG G5. Jetzt weiß ich, dass es tatsächlich kaum neuere Telefone mit Lineage-Unterstützung (gleiches gilt für MoKee) und einfachem Akkuwechsel gibt. Die letzten sind aus 2016, besser als das G5 zum Beispiel das hierzulande seltene LG V20. Neuer ist nur das 2017 veröffentlichte Xiaomi Mi A1, das zwar keinen direkt auswechselbaren Akku hat, aber eine angeblich leicht nachvollziehbare Anleitung – die aber nicht mehr aufrufbar ist.
Ein neues Android-ROM auf ein gewöhnliches Smartphone aufzuspielen ist wirklich eine Möglichkeit, der Wegwerfkultur entgegenzuwirken. Denn jede Lebenszeitverlängerung hilft. Aber darauf jetzt zu setzen, um sich für ein Telefon zu entscheiden und das jahrelang zu benutzen? Das ist schwierig, wenn seit vier Jahren keine reparierbare moderne Hardware nachkam. Das G5 ist klasse, aber wie lange wird es davon noch gute Modelle geben?
Das alles macht das mittlerweile mit Android 10 erhältliche Fairphone 3 attraktiver.
Wenn ich die Seite nochmal erweitere wäre daher eine zweite Unterseite mit kurzen Vorstellartikeln zu Linux- und fairen/nachhaltigen Telefonen ganz oben auf der Todo-Liste.
Davon abgesehen, gibt es Vorschläge oder Feedback für die Seite?
feedtragón
Ich habe heute meinen Feedreader auf github gepusht. Frische Alpha-Software, das momentane Ziel ist, ihn zu einem vollwertigen Digg-Reader Ersatz zu machen, meinen jetzigen Feedreader. Also bin ich absolut noch nicht fertig.
Aber er kann schon ein bisschen was. Feeds können abonniert werden, Einträge werden angezeigt und beim Scrollen als gelesen markiert, Blog-Updates kommen an.
Je nachdem wo man anfängt hat dieser Feedreader eine lange Geschichte oder ist zwei Tage alt. Vor einigen Jahren stolperte ich über pubsubhubbub und wollte das für Serendipity. Ich war und bin kein Gläubiger des damaligen realtime-Hypes, glaubte aber doch und immer noch, dass einige nette Dinge mit solchen Mechanismen umgesetzt werden können. Und es war einfach völlig einleuchtend für mich, wieviel effektiver es sein muss, wenn Blogs bei Updates den Reader anpingen und nicht der Reader alle 5 Minuten den Feed herunterladen muss.
Wie auch immer, ich scheiterte damals daran das ordentlich umzusetzen, aber es blieb in meinem Hinterkopf.
Ein ganzes Stück später versuchte ich mich nochmal daran, zweimal sogar, und diesmal funktionierte es. Zum einen implementierte ich es in dsnblog auf Blogseite. Und - wichtiger noch - daraufhin in rsspusher als Hubclient. Was fehlte war das User-Frontend, eben der Feedreader den ich nun gebaut habe.
Entsprechend der Hintergrundgeschichte hat feedtragón eine Besonderheit: Im Gegensatz zu tt-rss und anderen selbstgehosteten Readern betreibt er kein Polling. Updates der abonnierten Blogs werden zum Reader gepusht, dieser soll sie nur anzeigen und den externen Dienst notdürftig verwalten.
Das erspart, mit einem poll-daemon den Server unnötig zu belasten, für den kleinen Preis der Erreichbarkeit von außen. Derzeit übernimmt superfeedr diese Aufgabe, 10000 kostenlose Benachrichtigungen sollten völlig ausreichen und die Rack-Middleware funktioniert hervorragend. Sollte das doch mal ein Problem werden, steht mit rsspusher eine (solange viel zu arbeitsintensive) Alternative bereit.
Ich werde den Reader auf jeden Fall für mich vervollständigen. Wer helfen will sei eingeladen.
Rsspusher
Rsspusher ist für mich etwas in letzter Zeit ungewöhnliches: Ein Projekt ohne GUI, mehr ein Service als eine Webseite oder ein Programm. Schickt man ein json-Objekt mit der URL einer oder mehreren Webseiten und eine Callback-URL, wird rsspusher neue Einträge auf den ersten URLs an den Callback schicken, falls diese einen RSS-Feed haben (oder einer sind).
Besser erklärt ist das auf der wunderschön gestalteten Demoseite.
Zwei verschiedene Motivationen führten dazu, dass ich dieses Tool baute.
Zum einen funktioniert der Bau des Freundes-Aktivitätenstreams im dsnblog derzeit, indem der eine Blog den Feed des anderen zieht. Doch wie soll ein Blog mitkriegen, dass der andere neue Artikel hat? Ich wollte keinen Code schreiben, der alle paar Minuten den Feed zieht und auf neue Einträge prüft, weshalb ich anfing, pubsubhubbub zu implementieren. Der Code wird viel schöner, wenn der eine dsnblog jedes mal per POST benachrichtigt wird, wenn der andere einen neuen Eintrag schreibt. Und eigentlich sollte das mit jedem beliebigen Feed funktionieren, selbst wenn sie wie auch immer funktionierenden keinen Hub angeben und anpingen. Eigentlich sollte man sich in diesem Projekt gar nicht darum kümmern müssen, wie man an die Information kommt, dass es ein Update gab - und genau diese Auslagerung, das ist rsspusher.
Zum anderen wird Google Reader ja bald abgeschaltet, weshalb auf dem eigenen Server laufende RSS-Reader mehr Aufmerksamkeit bekommen und sicher auch einige neue gebaut werden. Baut man so etwas selbst, ist die Polling-Infrastruktur zum Holen der Feeds - und das Verwalten von pubsubhubbub- und rsscloud-Abonnements - ein nicht kleiner Teil der Aufgabe. Vielleicht hilft es jemanden, wenn rsspusher das übernimmt oder kann zumindest etwas Hilfe aus dem Code ziehen.
Im Grunde ziemlich ähnlich zu superfeedr, nur frei und selbsthostbar und nicht ansatzweise so ausgereift. Ich hatte Spaß, das zu bauen, und nebenbei rausbekommen, warum das pubsubhubbub-Plugin für Serendipity wahrscheinlich nicht funktionierte. Netter Bonus: Samstag nachmittag habe ich es als Submission bei Hackernews eingereicht und als ich nachts wiederkam, war es auf der Frontpage (unten, und bis ich meinen Kommentar fertig geschrieben hatte, war es auf Seite 2 und der Kommentar blieb daher unbeachtet, aber trotzdem toll). Gehörte zu den Dingen, die ich mal hinbekommen haben wollte.
Simdock weiterentwickelt
Simdock ist ein ziemlich simples Dock für Linux. 2007 war der letzte Commit im svn, der Autor antwortet nicht auf Mails, das Projekt ist also tot. Simdock ist aber auch relativ hübsch und ausreichend und es war das einzige Dock, das mir Transparenz bot - die ganzen Compositing-Docks wie Cairo-Dock hatten bei mir nur einen schwarzen Hintergrund. Ausnahme war Kiba, das Pseudo-Transparenz simulieren kann, aber das stürzte wiederholt ab. Also wählte ich Simdock für meinen Desktop.
Tot wie das Projekt nunmal war fehlten dann aber doch ein paar Features, wie das Hinzufügen von Startern ohne Anpassen der Konfigurationsdatei. Vor allem aber war der Hintergrund an gconf gebunden, ein Wechseln des Desktophintergrunds ohne Änderung dort wurde nicht bemerkt, was ohne Gnome etwas unpraktisch ist. Daher habe ich das Projekt geforkt und versucht, die Mängel auszubessern. Zu finden ist das neue Simdock auf github.
Installation
Entweder man kompiliert es selbst:
Zuerst installiert man die Pakete libwxgtk2.8-dev libwxgtk2.8-0
Dann:
git clone git://github.com/onli/simdock.git cd simdock ./configure make sudo checkinstall oder sudo make install
Alternativ kann man unter 32-Bitsystemen auch dieses per checkinstall erstellte .deb versuchen:
Änderungen
- Statt gconf zu beobachten wird das Hintergrundbild von X direkt ausgelesen und Änderungen dort beobachtet
- Drag & Drop der Icons direkt aktiviert
- Tooltipps mit den Programmnamen beim Hovern der Icons
- Offene Programme können per Rechtsklick-Menü in einen Starter umgewandelt werden (wie bei Unity)
- Bugfix: Icons konnten verschwinden, wenn sie während des Verblassens angeklickt wurden
- Bugfix: Die id mancher Prozesse wurde nicht richtig gespeichert, sodass kein Icon gefunden wurde (z.B. Amarok)
Update für PC-Kombo
Das wichtigste am Update für den Hardwareempfehler ist wahrscheinlich die hinzugefügte Hardware. So sind die ganzen Core iX-2Y00k, also die neuen Intelprozessoren mit Grafikchips, enthalten. Mir wurde das Warten auf shopping.com zu doof und nun greift pc-kombo zusätzlich (aktuelle) Daten von Amazon ab, mit denen die Datenbank gefüttert wird.
Außerdem wurden die Kritikpunkte von Timo umgesetzt, bis auf die Erweiterung um Mainboards. Das heißt: Icons weg, Schriftart geändert (Lato), Impressumslink versperrt nichts mehr. Und Matthias hatte ein paar HTML-Fehler entdeckt.
Was ist noch zu verbessern?
Listenansicht für Serendipitys Suchergebnisse
Die Suchfunktion von Serendipity zeigt derzeit alle gefundenen Artikel in voller Länge. Bei wenigen gefundenen Artikeln ist das auch nicht abwegig. Es gibt aber Gründe gegen ein solches Verhalten: Zum einen ist man es von Suchmaschinen gewöhnt, erstmal nur eine Liste von Auszügen zu bekommen. Zum anderen machen diese Suchmaschinen das ja aus gutem Grund, nicht nur weil sie nicht einfach die Artikel spiegeln dürfen, sondern auch weil aus einer langen Liste von Ergebnissen so leichter gewählt werden kann. Genau das ist auch ein gewichtiges Argument bei Serendipity, wenn mehr als drei Artikel gefunden wurden.
Das Listsearch-Plugin erledigt zwei Dinge: In der Seitenleiste erscheint eine Suchbox, die genauso aussieht und fast genauso funktioniert wie das Quicksearch-Plugin. Es sendet den Suchbegriff aber nicht (sofort) an die normale Suchfunktion, sondern (erstmal) an das eigentliche Listsearch-Plugin. Dieses führt dann die Suche durch und zeigt die Ergebnisse als Liste.
Die Ergebnisseite ist eine .tpl, also per Smarty anpassbar. Meinungen, Vorschläge?
Edit: Ein vertrackter Fehler wurde danke Yellowleds Hilfe schon behoben, der Download wurde angepasst.
Image-sacon: Bilder von Flickr holen
Image-sacon ist ein unter der BSD-Lizenz stehendes Javaprogramm, das Bilder von Flickr lädt. Der Gedanke war, nicht einfach nur 10 Bilder zu markieren und die zu ziehen, sondern mit dem Programm wirklich sehr viele Bilder holen zu können. Dabei sollen die Lizenzen wählbar sein, die Oberfläche einen Eindruck vermitteln, ob die Suchbegriffe (Tags) stimmten, und die zu den Bildern gehörenden Informationen mitgespeichert werden. Zum Speichern der Informationen wird eine sqlite-Datenbank genutzt, die Bilder selbst landen im Dateisystem.
Grundsätzlich ist das Programm dafür ausgelegt erweitert zu werden. Neben Flickr könnten also auch weitere Bilderplattformen eingebunden werden. Bis jetzt ermöglicht es aber nur die Suche dort und in der eigenen Datenbank.
Izulu: Den Bildschirmhintergrund dem Wetter anpassen
Bei beyondserenity hatte ich von wetterabhängigen Wallpapern gelesen, die es bei KDE geben soll. Das wollte ich auch.
Izulu fragt bei Google nach dem derzeitigen Wetter in der angegebenen Stadt. Mit dieser Information kann dann automatisch das passende Bild als Hintergrund gesetzt werden. Da das ganze nur ein kleines Skript ist funktioniert es desktopunabhängig, Standardeinstellungen passen für GNOME, ich habe es damit und mit IceWM getestet. Izulu kann einmal oder auch dauerhaft ausgeführt werden. Im "deamon-mode" überprüft es alle 15 Minuten das Wetter, dieser Intervall kann nach Belieben angepasst werden.
Nutzung
Einmal installiert kann das Skript wie jedes andere Programm auch gestartet werden, der Befehl lautet izulu.
Konfiguration
Es gibt bisher drei Parameter, die direkt übergeben werden können:
- -c city: Hiermit kann der Standort angegeben werden. Es funktioniert natürlich nicht jede Stadt, Google muss die passenden Daten ausliefern. Überprüfen kann man das auf der iGoogle-Seite beim Wetter-Widget. Was dort in der Liste steht kann auch bei izulu eingetragen werden.
- -d: Aktiviert den daemon-mode.
- -i intervall: Wenn der daemon-mode aktiviert ist kann hiermit der Abfrageintervall eingestellt werden (in Sekunden).
Die Stadt kann auch im Homeverzeichnis in .izulu/config eingestellt werden. Standard ist Berlin. In dieser Datei wird ebenfalls der Befehl zum Setzen des Hintergrundes gespeichert - nutzt man kein GNOME muss man diesen anpassen, z.B. auf Esetroot -scale abändern wenn Eterm installiert ist.
Sonstige Hinweise
Entwicklung
Das Skript ist als frühe Alpha zu betrachten. Da kann natürlich immer was nicht funktionieren wie gewünscht, die meisten Fehler werden nicht gefangen und die Bedienung ist ebenso natürlich noch nicht ausgereift. Ich bitte um Rückmeldung wie das Skript funktioniert (deswegen das frühe Release) oder wenn man generell weiterhelfen will, z.B. indem eine GUI geschrieben wird (um mit ihr die Stadt zu wählen, die spezifischeren Bilder auszuwählen und die gegeben zu ersetzen) oder das Skript verbessert wurde.
Wetterzustände
Google unterscheidet zwischen vielen verschiedenen Wetterzuständen. Ich habe versucht diese alle abzubilden. Da die API keine offiziell freigegebene ist und also die Dokumentation fehlt ist das wahrscheinlich noch nicht perfekt. Die Grundzustände sonnig, bewölkt, regnerisch und schneiend sind als generelle Kategorien zusammengefasst, für diese werden Bilder mitinstalliert. Es kann aber auch feiner unterschieden werden, z.B. zwischen "leicht bewölkt" und "Wolkendecke". Dazu bei Interesse später mehr.
Bilder
Die großartigen Bilder sind nicht von mir, sondern wurden von anderen Menschen bei Flickr hochgeladen: Sonne, Wolken, Regen, Schnee und Nebel.
Download
ice-prefer
Ice-prefer ist ein Konfigurationsprogramm für IceWM. Es wurde in Bash geschrieben und nutzt als Oberfläche Xdialog und damit GTK+. Durch diese Kombination sollte es auch auf schwächeren Computern problemlos laufen.
Anlass für diese Vorstellung ist die neue Version 0.6. Denn sie vereinigt einige Verbesserungen. Die wichtigsten gleich sichtbaren: Das Programm spricht nun deutsch und es wurden neue Dialoge integriert, z.B. ein Farbauswahldialog. Aber auch unter der Haube wurde einiges verbessert, leistungskritische Stellen entschärft und einige Bugs beseitigt. Neue Optionen, z.B. die TaskBarShowCollapseButton-Einstellung, komplettieren das Release. Das Changelog nennt auch nicht alle Interna, vermittelt aber einen tieferen Einblick.
ice-prefer ist das Schwesterprogramm von ice-win und ihm auch sehr ähnlich, nur das ice-win die winoptions (die Einstellungen eines Fensters) editiert, ice-prefer dagegen die preferences (die Einstellungen von IceWM insgesamt).
Rückmeldung jedweder Art, insbesondere aber Bugreports, sind willkommen.
Download bei SourceForge, ein .deb und ein .tar.gz samt Installer stehen bereit.
ice-win verbessert
Da das Programm hier noch nicht erwähnt wurde, kurz eine Vorstellung: ice-win soll dabei helfen, die winoptions von IceWM zu konfigurieren. Damit kann man dann z.B. einstellen, auf welcher Arbeitsfläche welches Fenster erscheinen soll.
Geschrieben wurde es ursprünglich 2007. Inzwischen habe sogar ich etwas dazugelernt ;)
Da das Programm in Sachen Benutzerführung noch etwas Nachhilfe gebrauchen konnte und ich in der Zwischenzeit zwei Bugs entdeckte, habe ich mich nochmal daran gesetzt und ein paar Verbesserungen eingebaut, z.B. das Ausgrauen von derzeit nicht nutzbaren Optionen.
Zu finden ist die neue Version auf der Projektseite.
idesk-helper 0.1
Idesk ist ein Programm, das Desktopicons zeichnen kann. Normalerweise machen das die Dateimanager gleich mit, nutzt man aber keinen und will auf die Desktopsymbole nicht verzichten, ist idesk eine gute Lösung.
idesk-helper habe ich ein kleines Skript getauft, das Idesk zur Hand gehen soll. Es erstellt für jede Datei im Desktop-Ordner eine Verknüpfung und wandelt dabei *.desktop-Dateien in Idesks *.lnks-Format um. Dafür muss man das Skript nicht jedes Mal neu starten, man kann es auch im "Monitor"-Modus laufen lassen, dann reagiert es direkt auf Änderungen im Desktopordner.
Durch Black- und Whitelist ist es trotz des Automatismus noch möglich den Desktop manuell anzupassen, also z.B. eigene Starter zu erstellen oder bestimmte Dateien nicht als Desktopicon anzuzeigen.
Das Skript steht ab jetzt unter der GPL. Dies ist die erste Erwähnung des Projekts, ich weiß noch nicht, ob ich ihm eine richtige Projektseite widmen werde. Bis dahin gibt es hier das Skript als Debian-Paket:
Version 0.1
idesk-helper-0-1 (deb, 25 KB)
Update: Version 0.1.1
idesk-helper-0-1-1 (deb, 25 KB)
idesk-helper verbessert
Insbesondere dank Dirks Hilfe konnte ich einige Aspekte des hier bereits vorgestellten Skriptes verbessern. Funktional ändert sich nichts, aber es ist nun etwas schneller und der Code besser zu lesen.
Danke nochmal.
idesk-helper-0-1-1 (deb, 25 KB)