Posted on

Neues KDE Fensterdekorationen Einrichtungsmodul

Es gibt wenige Bestandteile in KDE’s Desktop Shell, die sich seit langer Zeit nicht verändert haben. So erinnere ich mich, dass die erste KDE Version, die ich nutzte (das war ein 3.x mit x << 5), das gleiche Einrichtungsmodul für Fensterdekorationen verwendete wie aktuell in der KDE Software Compilation 4.4. Die Benutzeroberfläche besteht aus einem Auswahlfeld mit den Namen der verfügbaren Dekorationen, einem Konfigurationsabschnitt für die ausgewählte Dekoration und einer Vorschau. Dies führt zu so wunderbaren Oberflächen mit Unterfenstern in Unterfenstern – werft einfach mal einen Blick auf die Oxygen Konfiguration in 4.4.

Mit KDE SC 4.5 wird es ein neues Konfigurationsmodul geben, das man auch als Qt 4 Portierung bezeichnen könnte. Das Auswahlfeld wird durch eine Liste ersetzt welche eine Vorschau für jede Dekoration enthält. Der Konfigurationsabschnitt ist in ein Dialogfenster verschoben welches man durch eine Konfigurationsschaltfläche neben der Vorschau erreicht.

Neues Dekorationen KCM

Da ich der Meinung bin, dass man ehren sollte wem Ehre gebührt, wurde eine Informationsschaltfläche zum Anzeigen der Autorinformationen hinzugefügt. Hier müssen die Entwickler und Künstler noch die Informationen nachtragen – aktuell fehlen sie noch.

Aurorae Designs sind in der Liste wie „normale“ Dekorationen aufgeführt. Die Tatsache, dass Aurorae eine Theme Engine ist, ist eigentlich für den Nutzer ein unbedeutendes Implementierungsdetail und sollte verborgen sein. Und damit erhält KWin endlich Unterstützung für Get Hot New Stuff bei Fensterdekorationen (für die Nicht-KDE-Nutzer: GHNS bietet die Möglichkeit Themes und ähnliches direkt von kde-look.org herunterzuladen und zu installieren oder mit anderen Worten „die beste Erfindung für Moddingkinder seit Reis in Beuteln“) – und das ist einfach umwerfend. Ich hoffe, dass wir deKorator Themes in der gleichen Art und Weise integrieren können.

Leider habe ich das nicht mehr für KDE SC 4.4 fertigstellen können und wird erst in 4.5 integriert sein, also z.B. in Kubuntu 10.10 enthalten sein. (Ja Vorfreude auf neue Versionen ist immer wichtig)

=-=-=-=-=
Powered by Blogilo

Posted on

Wie man Entwicklern bei Bugs helfen kann

Gestern hab ich ja darüber geschrieben wie der Weg von Bug zu Fix ist. Nun hab ich einen wichtigen Punkt vergessen: Du, ja genau Du, kannst den Entwicklern dabei nämlich helfen. Du brauchst dazu nicht mal programmieren zu können.

Ich hatte ja erwähnt, dass etwa 40 % aller Bugs die für KWin gemeldet werden, bereits gemeldet sind. D.h. ich gehe hin suche den korrekten und markiere ihn als Duplicate. Ein Beispiel aus der Beta 1: KWin crashed after a Konqueror crash Uns ist kurz vor Beta 1 eine Regression in den Code gekommen und wie man an meinem Commit (erster Kommentar) sieht, war es eine Trivialität. Dieser Crash hat uns durch die ganze Beta 1 verfolgt und er hat entsprechend viele Duplicates. Aber alle Duplicate Markierungen sind von Entwicklern gesetzt und das muss eigentlich nicht sein. Das könnten die Nutzer übernehmen. In so einem Fall ist es wirklich einfach: der Backtrace ist immer gleich und DrKonqui hängt die möglichen Duplikate sogar an (einfach auf einen der Duplikate klicken).

Ein anderer Fall sind normale Bugs – auch hier kann uns jeder Nutzer eigentlich helfen. Wenn ein Bug aufgemacht wird, steht er zuerst auf "UNCONFIRMED". Hier könnte nun ein Nutzer eigentlich schauen ob das überhaupt stimmt. Ist die Beschreibung korrekt, lässt sich der Bug reproduzieren, etc. Also den Bug soweit aufbereiten, dass der Entwickler damit etwas anfangen kann. Typischer Fall eines Bugs: KWin is slow – please improve. Toll hilft nichts. Hier müsste nachgefragt werden, welche Hardware er benutzt, welche Anwendungen, ob Compositing aktiviert ist, etc. Für mich als Entwickler ist so eine allgemeine Beschreibung natürlich wertlos und in der Zeit die ich nachfrage, könnte ich Entwicklungsarbeit leisten.

Und selbst bei Crashes kann der Nutzer sehr einfach mithelfen. Viele Crashes werden ohne die Debug Pakete installiert zu haben gepostet. Da können wir dann gar nichts machen. Hier gibt es die Möglichkeit nachzufragen oder wenn ein Weg angegeben ist, wie man KWin crashen lassen kann, einfach reproduzieren und einen guten Crash anhängen.

Dennoch muss ich nachfragen um meine Bugliste sauber zu halten. KWin hat aktuell etwa 360 offene Bugs. Wenn ich die Liste durchgehe und manuell Duplicates suche dann bekomme ich idR in einer Stunde 10 Bugs weg. Nicht gerade viel. Viele Bugs haben einen Kommentar wie "Is this still an issue in KDE SC 4.3.3?" und danach ein halbes Jahr keine Antwort mehr. In so einem Fall kann der Bug zugemacht werden – scheint niemanden zu interessieren und war entweder nie ein Bug oder ist behoben. Auch das ist etwas was Nutzer übernehmen können.

Wenn ein Bug überprüft ist, dann kann er von "UNCONFIRMED" auf "NEW" geändert werden. Dies könnte von den Entwicklern nun genutzt werden um zuverlässig nach Bugs zu suchen. Die unnützen Bugs erscheinen gar nicht und der Entwickler kann sich einen Bug schnappen und ihn beheben ohne großen Verwaltungsaufwand. Ja das wäre die ideale Welt 🙂

Nun muss man natürlich nicht alleine als Nutzer plötzlich anfangen hier die Bugs zu durchforsten, sondern es gibt den KDE Bug Squad, der genau das macht. Regelmäßig veranstaltet die Gruppe Bug Days und aktuell gibt es auf forum.kde.org Bug Weeks. Der Bug Squad braucht übrigens immer Nachwuchs da viele Bug Jäger plötzlich abtrifften in die Entwicklung. So wurde die Überarbeitung von DrKonqui von einem Bug Squad Mitglied durchgeführt – Dario hatte einfach gesehen was nötig ist. Das Team beißt nicht und hilft immer weiter und Entwickler sind wirklich dankbar für die Arbeit. Also nichts wie los nach #kde-bugs.

Ach und natürlich braucht nicht nur KDE Nutzer, die bei Bugs helfen, sondern jedes Projekt.

=-=-=-=-=
Powered by Blogilo

Posted on

Vom Bug zum Fix

Angesichts der aktuellen Vorbereitung auf das Release der KDE Software Compilation in Version 4.4 hab ich gedacht ich beschreibe mal die Schritte, die ich gehen muss um einen gemeldeten Bug in KWin zu beheben. Denke das könnte ganz interessant sein, vor allem wenn man nicht so vertraut mit der Entwicklung ist 😉

Am Anfang steht der Bugreport. Im IRC channel #kwin gibt es einen kleinen bot, der neue Bug reports meldet. Da ich auch ein highlight auf das Wort "kwin" habe und dieses zufälligerweise in jeder Bug Meldung enthalten ist, erhalte ich eine schöne Benachrichtigung. Im Channel ist dann auch gleich die URL zum draufklicken enthalten. Wenn ich nicht am Rechner sitze, dann bekomme ich neue Bugs trotzdem mit: alle Bugzilla Mails werden auch an die kwin Mailingliste gesendet und zusätzlich hab ich in Akregator einen RSS feeds für neue Bugs (eigentlich überflüssig).

Ein Bug fällt in eine von drei Kategorien:

  • Wishlist
  • Bug
  • Crash

Wishlist ist ein Wunsch und so etwas wird idR erst einmal ignoriert. Gerade in der Zeit, in der man sich auf das Beheben von Bugs konzentriert, dürfen neue Wünsche eh nicht implementiert werden. Viele der Wünsche sind auch einfach nun ja Traumkonzert und lassen sich zwischen schwer bis gar nicht umsetzen.

Ein Bug ist ein Fehlvehalten der Anwendung. Im Falle von KWin beziehen sich die Meisten auf irgendwelche Probleme mit den Desktop Effekten. Viele der Meldungen sind sehr ungenau und nur unter bestimmten Fällen zu reproduzieren. Für einen Bug gilt eigentlich, dass er nicht besonders priorisiert ist. Außer es ist wirklich ein gravierender Bug.

Crash ist nun eine Sonderform eines Bugs: die Anwendung hat einen Nullpointer dereferenziert und ist abgestürzt. Bei KWin nicht so schlimm, da es sich automatisch neustartet, aber trotzdem unangenehm. Zum Glück sind mittlerweile die Anzahl der Crashes zurückgegangen, so dass im Normalfall keiner auftritt.

Bei allen drei Arten gilt, dass wir zuerst überprüfen müssen, ob der Bug schon existiert. In etwa 40 % der Fälle ist das so. Bei Crashreports ist das am Einfachsten: DrKonqui findet die automatisch und hängt die Nummer des Duplikats gleich dran. Leider reporten die User häufig trotzdem. In so einem Fall ist der Bug schnell weg: Nummer rein, und abschicken. Ansonsten wird die Suchmaschine im Hirn eingeschaltet und überlegt, ob man so einen Crash nicht schon mal gelesen hatte und wenn ja dann wird geschickt über die Suche von Bugzilla den passenden gefunden.

Natürlich ist es hilfreich den Bug reproduzieren zu können. Leider ist das nicht immer möglich, weil ganz bestimmte Bedingungen vorliegen müssen. Hatte aktuell so einen Fall, dass es nur crashed, wenn man Present Windows als Alt+Tab Effekt verwendet, während er aktiviert ist die Anzahl der Fenster auf 0 geht und man dann im richtigen Augenblick mit der Maus klickt. In dem Fall war dann zum Glück der Quellcode eindeutig und konnte sehr leicht auch ohne Reproduzierung behoben werden 😉

Die Crash Reports enthalten einen automatisch generierten Stacktrace, der Aufschluss darüber gibt an welcher Stelle im Code der Crash auftrat. Dabei werden die Code Zeilen sogar genannt und manchmal sogar die Werte übergebener Variablen. Für die Datenschutzfanatiker: nein daraus lassen sich keine privaten Daten rückverfolgen. Im Falle von KWin ist das maximal, dass man erfährt auf welchen Desktop der User gerade wechselte. Komplizierte Daten werden als Zeiger auf eine Datenstruktur übergeben – aus der Adresse kann man nichts rauslesen außer, dass sie vllt. 0 war. Ist der Bug gegen KDE SC 4.3 reportet worden so stimmen sehr häufig die Zeilennummern nicht mehr. Hier ist es dann hilfreich, wenn man den Crash selbst reproduzieren kann, weil man dann die passenden Zeilennummern erhält.

Mit der Zeilennummer bewaffnet, geht es dann in die Entwicklungsumgebung und man schaut sich den Quellcode an. In den meisten Fällen macht es schlicht und ergreifend "Aha" und der Crash ist offensichtlich. Nun die berechtigte Frage: Warum trat er dann auf? Nehmen wir das Beispiel von oben mit Present Windows: es wurde nicht daran gedacht, dass es vorkommen kann, dass man mit der Maus klickt, wenn kein Fenster da ist. Der Code ist ja gedacht ein Fenster auszuwählen. Ja eine falsche Annahme. Über den Stacktrace und den übergebenen Werten ist dann erkennbar welcher Zeiger auf 0 zeigt und man kann den Code anpassen, so dass dieser Fall entweder nicht mehr auftritt oder abgefangen wird.

Der nächste Schritt ist das neubauen von KWin (zum Glück direkt aus der IDE) und testen ob der Crash behoben ist. Wenn dem so ist, dann kann der veränderte Code in das Quellcodeverwaltungssystem eingespielt werden. KDE verwendet eigentlich SVN, was aber für mich eher unpraktisch ist, deswegen nutze ich selbst git und habe einen über git-svn verwalteten Checkout von kwin. Zuerst überprüfe ich die veränderten Code Zeilen mittels git diff – das zeigt mir in der Konsole an, was sich genau verändert hat. Eine wichtige Überprüfung um nicht irgendwelchen Müll durch das Testen (debug Ausgaben u.ä.) ausversehen einzuspielen. Auch eine gute Überprüfung ob der Coding Style eingehalten wurde. Der nächste Schritt ist die Änderung mittels git add und/oder git commit (-a) als lokalen Commit einzuspielen. Hierbei gibt man eine aussagekräftige Commit Message ein und trägt mittels BUG: NUMMER den Bug ein, welcher dadurch behoben wird. Nun muss der Code mittels git svn dcommit in das KDE SVN übertragen werden. Dabei wird dank dem BUG Schlüsselwort der zugehörige Bugreport automatisch geschlossen und ein Kommentar eingefügt.

Die Änderung wurde nun aber nur in trunk eingespielt – dem Hauptentwicklungszweig und das was in mehr als einem halben Jahr mal KDE SC 4.5 werden soll. Natürlich möchte ich den Bug auch in 4.4 behoben haben und dazu muss der Patch in den branch zurückportiert werden. Würde ich nicht git verwenden, wäre das richtig einfach, denn es gibt ein Skript dafür. Würde KDE git verwenden wäre es noch einfacher. Für mich bedeutet es manuelle Arbeit. Also mittels git show den letzten Commit in eine temporäre Datei speichern und in mein Verzeichnis wechseln, in dem der 4.4 Code rumliegt. Hier kann ich mit patch -i die Änderungen lokal einspielen. Bei 4.4 geht das noch ohne irgendwelches meckern, da es im Prinzip noch der identische Code ist. Nun müsste ich eigentlich die Änderung einspielen, hab aber mein Konsolen SVN Wissen dank git verlernt und nutze nun Dolphins SVN Integration. Dolphin öffnen, an die passende Stelle navigieren, über das Kontextmenü noch mal den Diff anzeigen lassen (lieber einmal zu viel kontrolliert, als einmal zu wenig) und die Datei committen. Als Commit Message wird die gleiche Meldung wie zuvor in git verwendet, jedoch mit dem Zusatz "Backport rev SVN-Nummer" und CCBUG anstatt BUG. Dadurch wird einfach nur eine Meldung an den Bug angehängt. Und da wir ja fleißig sind, machen wir das ganze für 4.3 auch noch mal sofern der Code passt.

So wie lange dauert so etwas? Beispiel von gestern abend: Um 20:54 Uhr hat mir ein User im IRC einen Crash gemeldet, er klang komisch und ich hab sofort ausprobiert und ihn reproduzieren können. Kdevelop war bereits mit der passenden Datei geöffnet (ist eigentlich immer offen) und ich konnte direkt an die Quellcodezeile springen. Um 21:06 konnte ich dem User melden, dass der Crash in trunk und branch behoben ist. Für den Backport in einen Branch brauche ich etwa 2 min – insgesamt alse 4 (IRC Log von CIA Bot). Zum Reproduzieren, Crashen und Testen, dass es wirklich behoben ist also gerade mal vier bis fünf Minuten. Ja der war wirklich einfach 😉 Heute saß ich an einem, bei dem ich nach etwa einer Stunde erst mal aufgehört habe, weil ich ihn nicht beheben konnte. Wird aber definitiv in 4.4 (notfalls über Würgaround) behoben sein.

=-=-=-=-=
Powered by Blogilo

Posted on

Wechsel auf KDE SC 4.4

Einige werden es ja wissen, dass ich aktuell an meiner Masterthesis arbeite und dafür Akonadi aus der KDE Plattform in Version 4.4 einsetze. Es ist für meine Aufgabenstellung die perfekte Lösung. Nun nutze ich viele der Neuerungen in KDE SC 4.4 – nicht nur von Akonadi, sondern auch die neu Lösung des Systemabschnitts (Status Notifiers).

Nun hatte ich das Problem, dass ich das ganze schlecht testen konnte. Da die Status Notifier in KDE SC 4.3 nur experimentell waren und die API sich geändert hat, konnte meine 4.4 Anwendung nicht mit dem 4.3 Workspace „sprechen“ und die Funktionalität war nicht vorhanden. Meine Lösung für das Problem ist eigentlich ein zweiter X Server in dem eine reine 4.4 Sitzung läuft. Unglücklicherweise meint mein System aktuell sich aufzuhängen, wenn ich zwischen X Sessions wechsel. So auch heute als ich wieder testen wollte.

Da ich mittlerweile soweit bin, dass ich über den Einsatz im Produktivsystem nachdenke (d.h. ich vertraue meiner Implementierung so weit, dass ich sie auf meine E-Mails loslassen werde und keine Angst mehr vor Datenverlust habe) brauche ich eine 4.4 Sitzung. Also nach dem freeze bedingten Neustart hat es mir gereicht und anstatt in die 4.3 Sitzung hab ich zum ersten Mal mein Produktivsystem in das selbstkompilierte 4.4 gestartet.

Bisher hatte ich 4.4 immer nur zum Testen eingesetzt und das ist ja nicht wirklich vergleichbar. Nun sehe ich also zum ersten Mal im produktiven Einsatz die Früchte der Arbeit des letzten halben Jahres. Und ich bin wirklich begeistert. Das System fühlt sich bedeutend flüssiger an, die leichten Animationen fallen nicht störend auf, sondern machen das System angenehmer. Auch meine eigenen Implementierungen machen sich sehr gut: Alt+Tab ist eine tolle Verbesserung im Vergleich zu vorher und auch Aurorae gefällt mir gerade sehr gut – mittlerweile gibt es ja einige nette Themes. Von den anfänglichen Performance Problemen merke ich auch nichts mehr. Generell ist das Vergrößern der Fenster bedeutend angenehmer geworden.

Insgesamt fühlt sich 4.4 schon sehr rund an. Die Veränderungen sind größtenteils gering aber sehr nützlich. Hier sei bespielhaft die Verbesserungen von KRunner erwähnt: das Interface erscheint nun von KWin animiert an der oberen Bildschirmkante, die Einstellungen sind direkt in das Interface integriert und es gibt bedeutend mehr und sinnvolle Runner (auch einen von mir 😉 ).

Mit der jetzt von mir eingesetzten Version, die in etwa der Beta 2 entspricht, bin ich sehr zuversichtlich, dass 4.4 ein tolles und rundes Release wird. Wenn man mal überlegt wo die Community vor zwei Jahren stand… Nun haben wir die Säulen mit Nepomuk und Akonadi endlich integriert und der KDE Plasma Desktop ist einfach nur umwerfend. Ich war ja schon von 4.0 begeistert (vom technischen Standpunkt aus gesehen), aber dass sich das Produkt so hervorragend entwickelt, hätte ich dann doch nicht für möglich gehalten. Wer jetzt noch KDE 3.5 will, ist selber Schuld 😉

=-=-=-=-=
Powered by Blogilo

Posted on

Der Schäfer verliert seine Schafe

Die aktuelle Diskussion in der GNOME Community, ob GNOME aus GNU aussteigen soll, finde ich interessant und möchte hier meine Gedanken dazu äußern. In diesem Post wird die FSF und RMS kritisiert werden. Diese Kritik betrifft aber nicht den europäischen Ableger FSFE.

Zuerst einmal die Frage: „Was würde sich durch den Austritt ändern?“ Eigentlich nichts. GNOME als GPL lizensierte Software bleibt natürlich freie Software. Auch dürfte weder die GNOME noch die GNU Community dadurch Schaden nehmen. Beide sind groß genug um sich alleine tragen zu können und GNOME scheint sowieso nicht sehr in GNU integriert zu sein. Das einzige was passieren könnte, ist dass es schlechte Presse gibt. Hier kann man nur hoffen, dass die Communities es schaffen einen Rosenkrieg zu vermeiden.

Persönlich bin ich von der Entwicklung nicht überrascht – auch nicht, dass auf die versuchte Einmischung von Stallman mit der Diskussion über den Austritt aus GNU diskutiert wird. Für mich ist das nun die Zuspitzung einer sich seit langem abzeichnenden Entwicklung. Man denke nur an Stallmans Mono-Bashing oder die Rede auf dem Desktop Summit (die nun wohl noch in den Köpfen derjenigen rumschwirrt, die am Ende entscheiden). Stallman versucht sich in die Belange der GNOME Community einzumischen, ja sogar Forderungen zu stellen und diese mit der GNU Zugehörigkeit zu begründen. Dass dann in der Community der Gedanke aufkommen könnte die ungewollte Einmischung los zu werden, ist nachvollziehbar.

Über die Frage, ob proprietäre Anwendungen auf planet GNOME erwähnt werden dürfen, lässt sich natürlich diskutieren. Persönlich stören mich z.B. die vielen Mono Posting auch – besonders wenn es um irgendwelche Anwendungen auf proprietären Systemen geht. Aber betrachtet man sich die Zielsetzung des Planets, so sind diese Beiträge klar erlaubt. Gerade die Posts zu VMWare (der Stein des Anstoßes) halte ich sogar für recht wichtig, da es zeigt, dass bei VMWare Leute aus der Community arbeiten, Leute, die die Firma von innen heraus öffnen können. Verbietet man ihnen über ihre Arbeit zu bloggen, zerstört man am Ende vielleicht den kleinen Pfad, um VMWare zur Open Source Community zu führen.

Nun hatte ich ja im Juli das Glück eine Rede von RMS zu hören und seine Argumentation zu sehen. Für ihn gibt es schwarz und weiß, gut und böse. Freie Software gut, nicht freie (einschließlich OpenSource, d.h. z.B. BSD) böse. Gerade beim Beispiel Mono konnte man das recht gut sehen. Die Möglichkeit, dass sich Microsoft der OpenSource Welt hin öffnet, wird nicht gesehen. Microsoft ist böse, daher darf man nichts verwenden was von Microsoft kommt (sinngemäßes Zitat). Für die meisten Open Source Entwickler ist diese Argumentation natürlich nicht haltbar. Vor 20 Jahren konnte man freie Software mit dem Argument der Freiheit vermarkten. RMS hatte damals seine Jünger und eine Rede der Art hat perfekt gepasst. Heute sieht das anders aus. Freie Software muss nicht mehr die Freiheit hervorheben um sich gegen die Wettbewerber durchzusetzen, sondern kann nun auch die bessere Qualität als Argument liefern. Ich habe für mich selbst anlässlich der aktuellen Diskussion reflektiert, ob ich freie Software schreibe, weil sie frei ist oder weil es das beste Mittel zum Ziel ist. Letzteres ist der Fall. Ich möchte gute Software schreiben, die von vielen Menschen benutzt wird. Dass sie frei ist, ist toll, aber es ist nicht die Motivation die mich antreibt. Heißt auch, dass ich zum Beispiel kein Problem damit hätte an das LGPL lizensierte Qt Code beizusteuern oder an BSD lizensierte Projekte.

RMS hat seine Schafe verloren. War er früher der Hüter einer kleinen Gemeinde, die alle mit ihm übereinstimmen, so ist heute die Gemeinde viel größer. Sie läuft immer noch in die gleiche Richtung, aber braucht eigentlich keinen Schäfer mehr, der auf sie aufpasst und sie auf dem rechten Pfad führt. Versucht der Schäfer als Heiliger der Kirche von Emacs durch den Free Software Song seine Schafe zu sammeln, so wenden sie sich nur noch beschämt ab. Der Schäfer scheint aber noch nicht gemerkt zu haben, dass seine Herde gewachsen ist und ihn nicht mehr als Schäfer braucht und sich nicht mehr von ihm zurechtweisen lassen will. Natürlich ist es wichtig, dass es den Schäfer gibt, der auch mal auf Gefahren wie die Monoschlucht hinweist, aber er muss es so machen, dass seine neuen Schafe ihn verstehen. (viele der heutigen Entwickler lebten noch nicht einmal als das GNU Projekt gegründet wurde)

Die Verdienste von RMS sind natürlich wichtig. Aber in die heutige Zeit passt seine schwarz-weiß Argumentation nicht mehr. Die Entwickler können und wollen so eine Zielsetzung nicht akzeptieren, da sie tagtäglich zum Beispiel auch mit Open Source ihr Geld verdienen. Dass RMS und somit auch die FSF nicht mehr die Entwickler vertritt, merkt man an so vielen Kleinigkeite wie dem GNU/Linux Streit, Mono oder jetzt dem Planet. Ich hoffe, dass die FSF sich langsam aber sicher in gemäßigtere Wasser begiebt, so dass sich nicht die Entwickler von ihr abwenden und das wichtige Ziel des freien Software Gedanken auf der Strecke liegen bleibt. Ich denke die FSFE ist da ein gutes Vorbild.

=-=-=-=-=
Powered by Blogilo

Posted on

Fensterdekoration hinter transparenten Fenstern

Gestern kurz vor dem harten Feature Freeze für KDE SC 4.4 hat KWin noch ein tolles neues Feature erhalten: die Fensterdekoration kann hinter transparenten Fenstern gezeichnet werden. Seht selbst:

Aktuell wird dies in Aurorae, der einzigen transparenten Deko, unterstützt, aber noch von keiner Anwendung. Da dies aber als Erweiterung des Standards vorgeschlagen ist, dürfte es in Zukunft Anwendungen geben, die dies nutzen. So hab ich mal gelesen, dass Mozilla für Firefox ein solches Feature nutzen möchte. Dies ist nun die Lösung auf der X11 Plattform.

=-=-=-=-=
Powered by Blogilo

Posted on

Wie meldet man sich an seinem Rechner an

Man stelle sich vor zur Benutzung von Microsoft Windows 7 müsste man einen Webmail Account bei Microsoft haben und die Anmeldung am Betriebssystem erfolgt über diesen Account. Dabei wird natürlich über das Internet überprüft, ob Benutzername und Passwort passen. Ohne Internetverbindung also keine Anmeldung. Microsoft wüsste genau wer den Rechner benutzt, wann und wie lange. Um das ganze noch zu verbessern, kann man keine Anwendungen unter Windows 7 installieren – man hat ja den Internet Explorer und alle Webanwendungen der Welt.

Unvorstellbar – oder? Wie groß wäre der Aufschrei, wenn man ein MS Benutzerkonto bräuchte zur Anmeldung am Rechner? Was würde die EU Kommission dazu sagen oder die Medien? Es wäre wohl der größte Datenskandal denn es je gab. Wie komme ich also auf einen solchen Quatsch?

Ja dieser Quatsch nennt sich Google Chrome OS, wie es gestern vorgestellt wurde. Ohne Google Account kann man sich nicht einloggen. Ohne Internet kann man sich nicht einloggen. Anwendungen wozu? Es gibt doch den Chrome Browser. Alles was man macht geht direkt an Google. Ich hatte ja schonmal über Google Chrome OS gebloggt, aber das was jetzt vorgestellt wurde, ist ja noch schlimmer als was ich damals aus den geringen Infos rausgeholt hatte. Man muss sich das mal vorstellen: man besitzt die Hardware und ein dritter bestimmt ob ich sie nutzen darf. Toll das es OpenSource ist, das hilft da auch nicht mehr.

Es kommt selten vor, dass ich einem Open Source Projekt Misserfolg wünsche (ja selbst GNOME wünsche ich Erfolg 😉 ), aber Google Chrome OS stellt einen Angriff auf unser Recht auf informationelle Selbstbestimmung dar, wie es selbst Schäuble nicht schaffte. Gut OK, jeder kann sich selbst überlegen ob er Chrome OS nutzen will oder nicht. Jeder hat es selbst in der Hand. Was ist aber wenn es viele Leute nutzen und unser Staat dann sagt: Die Infos will ich auch. Wird das Verfassungsgericht noch nein sagen, wenn wir die informationelle Selbstbestimmung freiwillig aufgegeben haben? Ich bin da sehr skeptisch

=-=-=-=-=
Powered by Blogilo

Posted on

Neuer KWin Spaß

Heute war irgendwie der große “wir bereiten KWin auf KDE 4.4 vor” Tag. Es wurde der Window Tabbing Branch gemerged. D.h. KWin unterstützt nun Tabs für Fenster, man kann beliebige Fenster zu einer Gruppe zusammenfügen. Wer also wie in Chromium für jede Webseite einen eigene Browserinstanz haben will ohne viele Fenster, hat nun eine Lösung. (Natürlich hat KWin keine Ahnung, dass die Tabs z.B. ein Browser sind und bietet daher auch keine Unterstützung für Neu Laden, etc.)

Tabbing ist standardmäßig aktiviert, man muss nur die Fensterdekoration mittels mittlerer Maustaste Drag&Drop auf eine andere Deko ziehen. Mit Oxygen sieht das auch richtig toll aus. Andere Dekos unterstützen es noch nicht, ich hoffe die Zeit zu finden Unterstützung in Aurorae zu implementieren. Mehr Infos zu Tabbing findet man hier.

Ich hätte mich dieses Wochenende auch mit Tabbing beschäftigen können, stattdessen hab ich Present Windows und Desktop Grid verheiratet. D.h. wenn man Desktop Grid aktiviert, werden die Fenster mittels Present Windows angeordnet und das ganze sieht dann so aus:

Von KWin

Desktop Grid nutzt dabei Internas von Present Windows, leider ist es (noch) nicht möglich den Filter oder die Mauskürzel zu verwenden. Dazu müssten die Effekte schon verschmolzen zu werden, oder nach dem neuen Channel Topic:

One effect to rule them all. One effect to find them,
one effect to bring them all and in the darkness bind them
in the Land of KWin where the Wobbliness lies.

=-=-=-=-=
Powered by Blogilo

Posted on

Update auf Debian

Während die meisten Kubuntu Nutzer gerade ihr Upgrade auf Karmic machen, bin ich nach vier Jahren Kubuntu auf Debian Squeeze/Sid (und teilweise Experimental) gewechselt. Die Gründe hab ich eigentlich schon mal ausführlich hier aufgeführt. Um sie noch mal kurz zusammenzufassen:

  • Übersetzungen: ich weiß, dass es diesmal besser ist, dennoch war mit den 4.3 Paketen für Jaunty endgültig die Schmerzgrenze überschritten. Auch musste ich sehen, dass sämtliche Kubuntu Anpassungen, wie das Notify-OSD, nicht übersetzt sind. Ein Problempunkt auf den ich den zuständigen Entwickler vor mehr als einem Monat aufmerksam gemacht hatte, dass das passieren wird.
  • Ayatana: mich stören ganz stark die Anpassungen von Canonical an KDE. Es ist Canonicals gutes Recht ein neues Benachrichtigungssystem zu entwickeln und dies ohne Community Mitarbeit zu machen. Dies dann aber teilweise an die Nutzer auszuliefern (wie den MessageIndicator) finde ich aber nicht gut und das ist nichts was ich noch nutzen will (vor allem mit obigen Punkt). Hinzu kommt, dass der MessageIndicator als Plasmoid meiner Meinung nach völlig falsch implementiert ist (auch darauf hab ich den Entwickler hingewiesen). Dass man dies besser hätte mit KStatusNotifierItem umsetzen können, wurde diese Woche erneut auf den Mailinglisten diskutiert. Scheine hier also nicht ganz alleine mit meiner Meinung zu sein 😉
  • Plasma Netbook Shell: Kubuntu liefert in Karmic eine “technical Preview” der mit KDE 4.4 kommenden Plasma Netbook Shell aus. Dies ist aktuell pre-alpha und benötigt an vielen Stellen KDE 4.4 und ist daher nicht das was aktuell in trunk ist. Auch hier ist es wieder Canonicals gutes Recht das zu tun, aber ich denke nach dem 4.0 Debakel, an dem Distributionen nicht ganz unschuldig waren, hätte man so etwas besser sein lassen sollen. Wie man darauf 18 Monate Support geben soll, ist mir unklar. Aussagen wie “This is a supported release just like Kubuntu or Ubuntu” macht mir in dem Zusammenhang Angst für den allgmeinen Fall.

Interessant ist, dass ich zwei mal bisher die Distribution gewechselt habe und beide Male nicht ein Vorteil der neuen Distribution der ausschlaggebende Faktor war, sondern eher die Unzufriedenheit mit der zuvor verwendeten. Das letzte Mal war es SUSE und ich war nicht wirklich mit YAST und RPM zufrieden.

Die Debian Installation hatte mehr Probleme verursacht als ich erwartet hatte. Mein Testsystem funktionierte einwandfrei. Jedoch hatte ich nicht mehr an die Probleme mit EFI auf dem MacBook gedacht und konnte dann das System nicht starten. Erst nachdem ich mehrmals erfolglos war, kam ich auf die Idee mal im Internet zu schauen 😉 Danach funktionierte dann GRUB, nur um beim Update auf testing (hab mit einer Lenny CD installiert) erneut vor einem nicht bootenden System zu stehen wegen dem Update auf GRUB2. Da ich mittlerweile angenervt war und keine Lust hatte mich mit GRUB2 auseinanderzusetzen, wurde wieder grub-legacy installiert und System läuft wieder.

Nun konnte endlich auch mal eine grafische Oberfläche installiert werden und hab prompt vergessen apt-pinning einzurichten und hab nun mehr sid als squeeze. Da ich mittlerweile sehr angenervt war, bleibt es nun dabei 😉

In KDE selbst, gibt es wie bei Debian nicht anders zu erwarten keine negativen Erfahrungen. Nein ich bin sogar positiv – sehr positiv – überrascht. Die KWin Effekte fliegen geradezu. Ich hab es selten so flüssig erlebt. Ich weiß nicht ob das bei Karmic nun auch der Fall wäre aber es ist sehr angenehm. Selbst unter den harten Belastungen wie ich kompiliere gerade mal KDE und benutze den Würfel zum Wechseln der Arbeitsfläche treten keine Ruckler auf. Das ganze System fühlt sich viel reaktiver an und ich frage mich zum ersten Mal ob an dem ganzen “KDE ist in Kubuntu langsam” doch was dran ist. Nun mal abwarten wie das aussieht, wenn der Rechner ein paar Tage Uptime hat mit Kdevelop & Co. ständig geöffnet.

Die nächste unangenehme Überraschung trat am Folgetag (gestern) auf. Wegen Bauarbeiten in meinem Zimmer (neue Fenster) musste ich mit meinem Rechner umziehen nur um feststellen zu müssen, dass ich noch keine WLAN Treiber installiert hatte. Wie sich später rausstellte, ist dieser proprietär (also nicht überraschend). Ich wollte eigentlich an meinem “geheimen” Programmierprojekt arbeiten, aber zum Kompilieren von kdepimlibs fehlte mir noch ein Paket, daher können sich jetzt die KDE Nutzer freuen, denn ich hab mal wieder einen halben Tag KWin Bugs behoben – dank git und meinem guten Gedächtnis geht das auch ohne Internet. Und da ich dabei war, hab ich heute gleich weiter gearbeitet und es gibt nun einen schnellen Fenstervergrößerungsmodus (wie in Compiz) und ein MacOS like Alt+Tab (nur Anwendungen).

Mittlerweile ist das System ganz gut aufgesetz. Alles wichtige ist installiert. Leider musste ich häufiger zum selbst Handanlegen wechseln als mir Recht war. Da hat der Pragmatismus von Ubuntu zu proprietären Treibern doch Vorteile. (Ich muss unbedingt alle Treiber sammeln, damit ich nicht ohne X dastehe, beim nächsten Kernelupdate). Das einzige was mich aktuell stört, ist, dass ich den Bildschirm in der Helligkeit nicht verstellen kann. Unter Ubuntu ging das. Muss ich mich mal genauer auf die Suche des Problems machen. Der Treiber ist eigentlich im Kernel vorhanden.

=-=-=-=-=
Powered by Blogilo

Posted on

Wikipedia im Vergleich zum Ubuntuusers Wiki

Die aktuelle von Fefe angestossene Diskussion zur Lösch(un)praktik der Wikipedia ist für mich mal ein Grund die Wikipedia mit dem Wiki von Ubuntuusers zu vergleichen. Ich denke bei der Wikipedia – zumindest der Deutschen – läuft seit einiger Zeit einiges falsch. Es ist ja nicht die erste Löschdiskussion und gerade die “Relevanzkriterien” sind bei mir schon öfter mal sauer aufgestossen. Mittlerweile schaue ich bei jedem Artikel auch auf die Englische Wikipedia. Zum Vergleich: wenn ich ein Linux “Problem” habe, ist meine erste Anlaufstelle das Ubuntuusers Wiki und erst wenn ich dort nicht fündig werde, gehe ich zur Suchmaschine.

Nun lässt sich überhaupt die Wikipedia mit dem uu Wiki vergleichen? Auf den ersten Blick nein. Die Wikipedia ist eine Enzyklopädie, das uu Wiki ist eine kleine Sammlung von technischen Artikeln. Jedoch gibt es große Übereinstimmungen:

  • Beides sind Wikis
  • Beide leben vom Mitmachen der Leute
  • Beide sind freie Projekte
  • Beide haben eine selbstgeschriebene Softwarelösung
  • Beide sind in ihrem Umfeld die Nummer 1 in Deutschland
  • Bei beiden gibt es eine Gruppe Ausgewählter, die das letzte Wort haben

Ich denke bei Ubuntuusers läuft es besser. Aber warum? Ich sehe da zwei Gründe:

  1. MediaWiki eignet sich nicht zur Diskussion
  2. Ubuntuusers hat das Baustellen Konzept

Die Diskussion bei der Wikipedia erfolgt im Rahmen der Möglichkeiten von MediaWiki und das ist ein Wiki. Es gibt daher zu jedem Artikel einen Anhang als Diskussion, welcher wiederum eine Wiki Seite ist. Ein Wiki ist aber kein Diskussionsmedium. Schaut man sich die aktuell so schönen öffentlichen Diskussionen an, sieht man, dass man mit einer Wiki Seite keine sinnvolle Diskussion erreichen kann.

Ubuntuusers verwendet zur Diskussion verknüpfte Forenthreads. Ein Forum ist ein Diskussionsmedium und bietet damit eine gute Grundlage um konstruktiv und sinnvoll zu diskutieren. In einem Forum sieht man sofort wer wo wann gepostet hat, es steht nicht alles untereinander, sondern ist sinnvoll strukturiert. Man sieht bei ubuntuusers sofort ob der Schreiber gerade eine Wikimoderator, Supporter, ehemaliger oder sonstwas ist. Dazu gibt es noch den Postcounter und das Anmeldedatum, die angezeigt werden. Klar nicht wirklich aussagekräftig, aber es hilft doch die Sockenpuppen aufzudecken. Gäbe es bei uns eine Diskussion wie die zum Löschantrag von Fefes Blog würde sofort auffallen, dass es Sockenpuppen sind und wir könnten mit den Forenmoderatoren zusammen eine gute Reaktion ausarbeiten.

Den zweiten Vorteil von Ubuntuusers ist das Baustellenkonzept. D.h. neue Artikel können nicht direkt im Wiki angelegt werden, sondern nur in der Baustelle. Das ist bei einem technischen Forum essentiell wichtig, da nur so sichergestellt werden kann, dass keine fehlerhaften oder gefährliche Anleitungen ins Wiki eingebaut werden. Für den Schreiber hat es auch den Vorteil, dass er sich erst mal austoben kann und erst wenn er fertig ist, sich den Moderatoren stellen muss 😉 Ich denke dieses Konzept wäre auch für die Wikipedia nützlich. Der aktuelle Fall zeigt es ja wieder: würde zuerst der Artikel komplett erarbeitet werden inklusive der Relevanzbeweise, dann hätte man nicht schon nach wenigen Minuten eine Löschdiskussion. Größere Überarbeitungen werden übrigens auch nur in der Baustelle vorgenommen und solange wird der eigentliche Artikel gesperrt. Das hat den Vorteil für den Schreiber, dass er sich austoben kann und auch den kompletten Artikel erst mal kaputt machen kann und für den Wikimod, der die Änderungen korrigiert (vielen Dank an der Stelle noch mal an das Webteam für den RSS Fead – dafür gibt’s ein Bier beim nächsten Teamtreffen), dass er diese Änderungen erst mal ignorieren kann. Wäre für die Wikipedia auch interessant.

Nun klingt das alles ja ganz toll, aber woher soll man nun wissen, dass es wirklich besser ist? Dazu möchte ich einfach mal anmerken, dass wir in den etwa 1,5 Jahren, die ich im Wikiteam nun bin, keine einzige Seite sperren mussten wegen einem Editwars. Wir haben auch meines Wissens nach noch nie einen User sperren müssen. Gut wir zwingen die Anmeldung am Portal um Änderungen vornehmen zu können – muss aber auch sein, sonst könnte der User nicht mitdiskutieren.

Auch bietet uns die Software noch mehr nette Möglichkeiten. So haben wir – ja man glaubt es kaum – einen internen Diskussionsbereich und einen geschützten Wikibereich. Dass unsere interne Diskussion nach Außen getragen wird und plötzlich bei Fefe verlinkt ist, kann uns nicht passieren 😉 (Nein wir diskutieren nichts schlimmes intern, meistens geht es nur um Sachen wie Verbesserungen an unseren Vorlagen. Das geht im kleinen Kreis halt einfacher. Wikiartikel selbst diskutieren wir öffentlich).

Nun und jetzt noch etwas zum Löschen. Ja wir löschen auch. Aber nur ganz selten. Wir löschen eigentlich nie Artikel aus dem Wiki. Ist ein Artikel veraltet so wird er ins Archiv verschoben. D.h. er ist immer noch vorhanden. Gründe für so etwas ist nicht mehr vorhandene Software wie z.B. Beryl. Gelöscht werden maximal Artikel, die unsere “Relevanzkriterien” nicht erfüllen und das sind dann “nur” Artikel in der Baustelle. Das kommt sehr selten vor und wird immer nur nach dem Vielaugen Prinzip angewandt (und wir bieten dem Autor immer auch an den Artikel auf seine Benutzerseite zu stellen). Ein Beispiel wäre ein Artikel zu einem Windowsspiel welches ohne Anpassung mit Wine läuft. Dafür braucht man einfach keinen Artikel 😉

Auch wenn das uu Wiki viel kleiner ist, könnte die große Wikipedia meiner Meinung nach von uns Lernen. Ich hoffe auch dass die Löschdiskussion nicht abebbt, sondern zum Umdenken in der Wikipedia führt. Ich denke die Wikipedia schadet sich selbst. Wenn in der englischsprachigen Wikipedia mehr steht zu aktuellen deutschen politischen Ereignissen, dann ist das für mich ein deutliches Indiz dass was falsch läuft. Ich denke für die Wikipedia sollte gelten: “Verbessern statt Löschen”

=-=-=-=-=
Powered by Blogilo