lxqt - ein paar Fragen

[holgerw]

Hallo Alf,

Der zarte Hinweis mit dem Pull-Request ist die aktuelle Abwandlung von "Sende einen Patch"

Danke, das verstehen auch wir Nutzer

Und wir haben permanent zu wenig Leute, die Code beitragen.

Das finde ich Schade, denn da können dann noch soviele gute Anregungen von Nutzern kommen ...

Den Link zu unserem Bugtracker werf ich mal hier rein: https://github.com/lxde/lxqt/issues - Wenn Sachen auffallen, die verdächtig nach Fehler oder Schlamperei aussehen, dann wäre da der Ort zum Issue malen. Oder halt mal kurz im IRC fragen: freenode #lxde

Danke für den Link, das geht hier aber unter, Alf. Es gibt in siduction den lxqt Flavour, warum gibt es dann kein Unterforum zu lxqt, wo so etwas gepinnt wird? Unter Manjaro ist das gut gelöst, da gibt es zu jedem Flavour ein Unterforum. Kein Vorwurf, sondern eine Anregung ...

Was Du zu kf5 schreibst: Ich mag KDE / kf5, meine Frau, mein Vater, ein Freund und ich nutzen es mittlerweile. kf5 fühlt sich auch schlanker und geschmeidiger an trotz aktivierter Effekte, als KDE4. Aber meine Kritik zu KDE / kf5 und Applikationen geht doch in eine andere Richtung und das hat nichts mit Bleeding Edge zu tun.

Sorry, es dauert immer eine Weile, bis man als User davon was mitbekommt, das ist aber auch gut so. Wenn man die Entwicklungszweige benutzt, dann bekommt man so was auch hautnahe mit, muss nicht in jedem Fall Spass machen oder - so man von den allfälligen Regressionen betroffen ist - zu Freuensprüngen reizen - aber ok.

Und:

Es ist also nicht immer die günstigste Variante, wenn man zu nahe an jedweder neuer Entwicklung klebt - aus Usersicht - und es gibt nichts, was wir dagegen tun können oder wollen. Das ist halt das Spannende an Bleeding Edge, man bekommt alle Neuerungen, aber auch alle Fehler, egal wo sie passieren, hautnah mit. Und bestimmte Sachen werden halt ausgesessen.

Na ja, was kmail angeht, vergeht vielen Nutzern die Freude schon seit Jahren, ob nun mit Debian Stable, siduction, openSUSE oder anderen Distributionen. Und was digikam angeht, habe ich hier schon vor einiger Zeit mal ähnlich Kritik geübt und Du hast mir mit noch viel drastischeren Worten Recht gegeben.

Viele Grüße,
  Holger

[melmarker]

Und nu sieh den Scheiss mal aus Entwicklersicht: Es gab da ein Qt 5.4.0, was zum Glück in debian in experimental versauert ist - ehrlich gesagt war dieses Stück Software auch zu nichts anderem zu gebrauchen. Arch hat es ausgerollt. Und da das die Basis für unsere Arbeit ist (wie auch für KDE) herrscht dann große Freude vor. Und jetzt gibt es halt 2 Varianten: Den eigenen Code richtig und sauber schreiben - und auf Regressionen keine Rücksicht nehmen (in Form von #ifdefs) oder halt auf jeden Fehler in unserem Upstream eingehen - Wir haben uns bei LXQt für eine Mischform entschieden, mit der klaren Priorität auf aussitzen, wenn ein Fixing zu aufwendig wäre. Klappt auch ganz gut, in der Zeit ist aber die Software fehlerhaft. Damit muss man dann leben. Eine andere Variante ist es auch, bestimmte Änderungen zurückzustellen, wenn in neuen Versionen des zugrunde liegenden Frameworks neue Funktionalitäten noch fehlerhaft sind und das früh genug auffällt - da das oft Cornercases sind, ist das nicht immer ganz so einfach, da melden wir und die Jungens von KDE auch Fehler an Qt und schicken Fixes so möglich. Alles nicht schön, aber Realität.

Und dann gibt es noch digikam - die sind immer bleeding edge, da wird jede neue Funktionalität in allen zugrundeliegenden Komponenten genutzt - ohne Rücksicht auf Verluste. Auch eine Variante, die Endbenutzer in die Entwicklung einzubinden. Die Enduser lieben so was Fakt ist aber, dass auch diese Vorgehensweise zu besserer Software führt, ich möchte aber digikam trotzdem nicht wirklich in der jeweils aktuellen Version nutzen, wenn ich davon abhängig wäre.