Ich will ja jetzt nicht trollen aber ich mag es nicht wen leute so reden. Ich kenne viele nicht ganz so erfahrene linux user die schon auf kde 4.0.1 setzten und bis jetzt keine probleme haben. viele denken an manchen sachen das es bugs sein dabei ist es nur eine änderung. Das soll nicht heißen Bug = Feature das soll nur heißen das man kde 4.0 und kde 3.5 nicht miteinader vergleichen kann. es sind 2 verschiedene sache und kde 4.0 wurde da komplett von neu auf aufgebaut. bitte teste mal kde 4.0.1 ein oder 2 tage lang internsiv und dann poste nochmal was :)
KDE 4.x hat sehr gute Ansätze und wird in ein bis zwei Jahren die 3.x überholt haben. Es mag unbedarfere Anwender mehr oder weniger zufriedenstellen aber für den harten Arbeitsalltag wenn man dann noch an Netzwerke mit mehr als einer Handvoll Rechner denkt ist es "noch" nicht so weit. Ich hätte es immer noch als Option hineingeschrieben und qt3 als Standard.
2. Für Qt3 gibt es _keinen_ Support von Trolltech/Nokia mehr. Es ist undenkbar, solche Software verpflichtend zu machen, wo Niemand mehr Probleme behebt. Dazu kommt, dass Qt4 ohnehin viel mächtiger und besser ist.
3. Auch KDE4-User kommen auf absehbare Zeit nicht ohne Qt3 aus (KDE PIM, KOffice und vieles mehr). Viele KDE-Teilprojekte werden auch bei KDE 4.1 noch nicht so weit sein. Ich lese die KOffice-Mailingliste, und es ist traurig. KWord ist nicht release-fähig und "keiner" kann/will das so bald ändern (also mit Geld oder Code).
4. Der LSB-Standard ist auch nicht für die Distribution selbst gedacht. Er beschränkt und entscheidet nicht, was eine Distribution so alles macht. Natürlich kann auch eine KDE 3.x oder eine Gnome-Distribution die Qt4-Bibliotheken enthalten. Warum auch nicht? Beim Standard geht es darum, was externe Software-Anbieter voraussetzen können, wenn ein System sich "LSB 3.2 konform" nennt.
5. Der LSB-Standard braucht keine Optionen, da er nichts verbietet, sondern per se nur auf das Minimum der Gemeinsamkeit abhebt (das immer stärker wächst).
6. Der LSB-Standard wird nicht von Dir, sondern von Distributoren erstellt. Vielleicht weil diese solche Sachen verstehen?
Es ist doch ganz einfach: Mit QT3 kann man LSB 3.1 konform sein, will man aber LSB 3.2 erreichen, braucht man dazu in Zukunft qt4.0. Der LSB Standard muss da jetzt anziehen, damit die Distributionen sich darauf einstellen können und beim nächsten/übernächsten/... Release die Kriterien erfüllen zu können.
Von Kevin Krammer am Di, 19. Februar 2008 um 14:32 #
Das wäre eine unnötige Verzögerung gewesen.
Mit diesem Update sind sicher beide Versionen enthalten und werden es auch einige Versionen lang bleiben. Die Empfehlung sagt lediglich aus, dass es vermutlich nicht zielführend ist, ein neues Produkt auf der älteren Version zu beginnen, weil sie im Rahmen des "Deprecation" Prozesses irgendwann nicht mehr garantiert vorhanden sein wird.
Ich frage mich, warum das noch nicht erwähnt wird. Ich habe gesehen, dass es für die LSB 4.0 vorgesehen ist, aber DBus ist immerhin schon 1.0 und wird ein immer integralerer Bestandteil von linux.
Von Kevin Krammer am Di, 19. Februar 2008 um 14:37 #
Das Fixieren der Spezifikation, besonders das Erstellen und Verifizieren der Konformitätstests, ist einfach ein zeitintensiver Prozess.
Im Fallen von D-Bus müssen neben dem eigentlichen Protokoll vermutlich auch Sachen wie Standardverzeichnisse für .service Dateien, Format der Introspectiondaten und vielleicht auch die Basisbibliothek libdbus fixiert werden.
Heute noch scheint es mir, als wären diverse Services von KDE und Gnome noch nicht auf gemeinsame Namensräume eingeschwenkt. Solange ich nicht den Screensaver mit einem D-Bus Befehl anwerfen kann, ist der Nutzen von D-Bus als Standard rein akademisch.
Also solange nicht klar ist, welche Kommandos garantiert verfügbar sein müssen, nützt D-Bus NICHTS.
Ich bin mir bewusst, dass es Bemühungen gibt, diese Dinge zu regeln. Aber das braucht stets Zeit, so auch in diesem Fall.
Von Kevin Krammer am Di, 19. Februar 2008 um 18:14 #
Die Vereinheitlichung von Service APIs ist ein zusätzlicher Schritt.
Die Verfügbarkeit von D-Bus ansich wäre schon für sich interessant, weil Hersteller dann zum Beispiel ihrerseits Funktionalität via D-Bus zur Verfügung stellen können, zum Beispiel um die Anwendung über ein Script zu steuern.
Warum wird Qt fest vorgeschrieben und nicht etwa gtk+? Was ist mit Gnome-Usern? Wird denen jetzt auch Qt nur wegen LSB-Konformität vorgesetzt? Grrr....
Ja ok, hätte ich besser mal erst in den Standard geschaut. ^^' Ich formuliere um: Warum Qt UND gtk+!? Nach LSB muss man also sowohl gtk+ als auch Qt haben? Naja wenn sich die Qt-Programme wenigstens in den Desktop einfügen würden... (Oder kann Qt4 endlich so wie gtk+ pixmapbasierende Themes? Es gibt ja eine Engine damit gtk-Programme ein Qt-Theme benutzen aber umgekehrt konnte es ja nicht gehen..)
Jepp, genau das hatte ich im Sinn. Als ich mich mal damit beschäftigt hatte eine Qt-Anwendung "ansehnlich" zu bekommen bin ich auch nur immer wieder darüber gestolpert. Damals hatte ich auch gelesen, dass eine Umkehrung (gtk-Theme in Qt) nicht machbar ist.
Ist für sowas nicht qtcurve zuständig? Ich benutze soetwas nicht, dashalb auch die Frage, aber wenn ich das richtig verstanden habe macht qtcurve das...
Klar ich hätte ein Theme nehmen können das mir zwar nicht gefällt aber bei dem wenigstens alle Programme gleich (schlecht) aussehen... Ich hatte nach 'nem Qt-Theme geschaut - wegen des vorhandenen Wrappers - aber mir hat nicht mal ansatzweise was gefallen. Geschmackssache eben. Und qtcurve gab es da wohl auch noch nicht, das sieht nämlich tatsächlich ganz ansehnlich aus. Teilweise können da auch Inkompatibilitäten eine Rolle gespielt haben (32bit Qt-Binärprogramm in 64bit-Umgebung), so dass ich die schönen Themes nicht nutzen konnte.
Kann ich mir ja mal anschauen. Geht aber eh derzeit nur noch um ein Programm und das wird wohl eher Qt3 sein, müsste ich aber an 'nem anderen Rechner nachschauen. Der Name kommt mir aber dunkel bekannt vor, kann sein dass ich das auch nicht für mein 32bit-Qt installieren konnte.
Also zumindest der Vergleich mit ATI und Nvidia hinkt. Also ich hab nur einen Grafikkartentreiber installiert, nämlich den der auf meine Hardware passt. Ähnlich sehe ich das auch mit gtk+/Qt. Ich benutze fast ausschließlich gtk-Programme und jedes Qt-Programm wirkt dort deplatziert - hauptsächlich weil es kein ähnliches Qt-Theme geben kann.
C/C++ hinkt auch. Ich hab ja nichts dagegen dass es Qt/KDE und gtk/GNOME gibt. Ich verstehe nur nicht ganz warum ein Standard vorschreibt *beides* installieren zu müssen. Am ehesten trifft noch der Vergleich Python/Perl. Aber als Anwender brauche ich normalerweise gar nicht zu bemerken ob gerade Perl oder Python werkelt, genau wie bei C/C++. Es fällt mir also insbesondere nicht auf wenn ich viele Perl und viele Python-Programme mische. Wie gesagt, bei gtk/Qt sehe ich den Unterschied deutlich.
Von Kevin Krammer am Di, 19. Februar 2008 um 15:21 #
...hauptsächlich weil es kein ähnliches Qt-Theme geben kann.
"Geben kann" hört sich so nach technischer Limitierung an, aber soweit mir bekannt ist, dürften die Styleengines ziemlich die gleichen Möglichkeiten bieten.
Ich verstehe nur nicht ganz warum ein Standard vorschreibt *beides* installieren zu müssen.
Der Standard schreibt nicht vor "beides" zu installieren, sondern aus der Auswahl aller zur Zeit verwendeten, nur die zwei am häufigsten benutzen Bibliotheken für GUI Programme.
Das deckt zwar nicht alle Anwendungen ab, aber für die meisten Hersteller ist es nun möglich, sich auf das Vorhandensein ihres Softwarestacks zu verlassen.
Würde man für Standardkonformität sowohl Nur-GTK oder Nur-Qt zulassen, wäre das als garantierte Basis relativ unbrauchbar, weil dann trotz Konformität die jeweilig verwendete Bibliothek mit geliefert werden müsste, weil ja im ungünstigen Fall die jeweils andere installiert wäre.
Das wäre praktisch äquivalent zu den LSB Versionen zuvor, wo keine dieser Bibliotheken garantiert vorhanden war.
"Geben kann" hört sich so nach technischer Limitierung an, aber soweit mir bekannt ist, dürften die Styleengines ziemlich die gleichen Möglichkeiten bieten.
Anscheinend leider, zumindest früher, nicht. Es gibt ein Modul um Qt-Themes in gtk-Programmen zu benutzen aber eine Suche nach einer gtk-in-Qt-Theme-Engine ergab einen Kommentar, dass dies nicht möglich sei. Ich weiß nicht mehr woran es lag, ich glaube an der fehlenden Pixmap-Engine. Eventuell wäre es möglich gewesen das gtk-Theme dass ich verwenden wollte in Qt nachzubauen. Umgekehrt wäre es jedoch trivial gewesen ein Qt-Theme in gtk zu benutzen.
Zugegeben für die Hersteller ist das wohl praktisch einfach für gtk oder Qt entwickeln zu können und relativ sicher zu sein, dass es läuft. Aber ob damit ein einheitlicher Desktop erreicht werden kann sehe ich noch nicht so recht...
weil dann trotz Konformität die jeweilig verwendete Bibliothek mit geliefert werden müsste,
Iiiihhh, nein! Dann lieber optional und an das Programm dranschreiben: "benötigt optionales LSB-Modul bla", wobei die Anzahl solcher optionaler Module nicht zu groß werden sollte. Noch besser - wenn auch viel Aufwand - wäre es den GUI-Code so zu kapseln, dass eine gtk- und eine Qt-Version angeboten werden können.
Von Kevin Krammer am Di, 19. Februar 2008 um 16:04 #
Ich weiß nicht mehr woran es lag, ich glaube an der fehlenden Pixmap-Engine.
Ich habe keine Ahnung was eine Pixmap-Engine sein soll, aber nachdem ein Qt Style vollen Zugriff auf die QPainter API hat, kann er auch jederzeit Pixmaps benutzen.
Technisch dürfte daher keine Limitierung bestehen, vermutlich hat es einfach nur noch niemand gemacht, weil es ohnhin Styles gibt, die für beide Stylesysteme verfügbar sind.
Aber ob damit ein einheitlicher Desktop erreicht werden kann sehe ich noch nicht so recht...
Die Zielsetzung der LSB ist auch nur das Vereinheitlichen der Plattform für Softwarehersteller, d.h. das garantierte Vorhandensein bestimmter Versionen von Bibliotheken, usw.
Dann lieber optional und an das Programm dranschreiben: "benötigt optionales LSB-Modul bla", wobei die Anzahl solcher optionaler Module nicht zu groß werden sollte.
Optional ist praktisch äquivalent zu selbst mit liefern, weil sich der Hersteller eben nicht darauf verlassen kann, eben wie in dem vorher genannten Beispiel, wo das Vorhandensein einer der beiden Bibliotheken schon für Konformität reichen würde.
Die Zielsetzung der LSB ist ja eben, diese "Zufälligkeit" zu reduzieren, also die am häufigsten verwendeten Bibliotheken praktisch zu garantieren.
Noch besser - wenn auch viel Aufwand - wäre es den GUI-Code so zu kapseln, dass eine gtk- und eine Qt-Version angeboten werden können.
Das lässt sich durchaus machen, zum Beispiel über Wrapper wie wxWidgets oder SWT. Viele Entwickler arbeiten aber lieber direkt mit den eigentlichen Toolkits, manchmal um nicht von kleinere Ungleichheiten in Wrapperimplementierungen überrascht zu werden.
Pixmap-Engine: So wie ich das verstanden habe unterstützt gtk eine Art Plugins für Themes. Diese nennen sich "(Theme-)Engines" und die Pixmap-Engine ist sehr verbreitet und gehört wohl auch zum Lieferumfang. Als ich mich damit beschäftigt habe - es ist eine Zeit her, das wird also hoffentlich mittlerweile alles etwas anders aussehen - war es für ein Qt-Theme nicht möglich z.B. für den Fensterhintergrund ein Pixmap zu verwenden während die von mir verwendeten gtk-Themes das eigentlich immer machten.
Nochmal zu optional: Mein Vorschlag wäre man definiert Module, z.B. das Modul "gtk+" und das Modul "Qt". Damit wäre fest definiert, wie eine LSB-konforme gtk- bzw. Qt-Installation auszusehen hat. Man könnte dann eine Installation nach "LSB" haben, ohne gtk und Qt. Für Qt-Programme benötigt man dann eine Installation nach "LSB + Modul Qt". Wenn ein Hersteller Qt nutzen möchte schreibt er an sein Programm dran "Benötigt LSB-Modul Qt". Ein daraufhin installiertes Qt sieht dann für alle Hersteller gleich aus. So etwas automatisch zusätzlich zu installieren sollte eigentlich jeder Paketmanager automatisch hinbekommen.
hast Du gesehen/gelesen, was mit Plasma in Qt 4.4 (also KDE 4.1) alles gemacht wird? Es gibt keinen Zweifel, dass Qt alles nötige für solche Engines kann. Sie können neuerdings Painter und funktionale Widgets ganz frei mischen.
Ich persönlich hatte eher den Eindruck, dass es technisch nicht lohnend wäre, solche Engines zu machen, weil der umgekehrte Weg erfolgreicher ist. Das kommt davon, dass in Gnome die Button-Reihenfolge zwingend festgeschrieben ist und in KDE nicht. Ich vermute, das sind die technischen Hinderungsgründe, die Du meintest?
Damit hat man unter Gnome mit einer Theme-Engine, die Qt wie GTK (in Gnome) aussehen lässt, einen konsistenten Desktop. Unter KDE kann keine GTK-Engine jemals erreichen, dass fest kodierte Positionen von "OK/Abbruch" Buttons in Gnome-Programmen (bei mir freeciv, ein GTK-Spiel) automatisch passend korrigiert werden.
Dazu kommt, dass der KDE-User in der Regel auch mal das zweitbeste Programm vorzieht, wenn es nur eine KDE-Oberfläche hat. KDE hat schon länger und erfolgreicher die Integration aller Programme vorangetrieben, während unter Gnome lange auch Programme wie Firefox, OpenOffice.org (das praktisch garkeinen Code von Gnome nutzt), etc. dabei waren, es also insgesamt akzeptabler war, dass alles irgendwie immer ein wenig anders von Programm zu Programm war.
Mir erscheinen heute schon reine Qt3/Qt4 Programme als intolerable Fremdkörper, ob ihrer schwachen Dialoge, komischer Menubezeichner, etc.
Nein, mit Qt 4.x habe ich mich nicht beschäftigt und ich glaube auch ernsthaft, dass Qt mittlerweile nicht mehr so beschränkt ist. Ich meine mich aber wie bereits geschrieben zu erinnern, dass Qt-Themes *damals* schon rein grafisch nicht flexibel genug waren. Ich glaube es ging um Qt 3.x, bin mir aber nicht sicher. Und es hilft mir ja leider auch nicht, dass Qt 4.4 super ist, wenn ich mich mit einem Programm herumschlage, das noch auf Qt3 basiert.
Die Qt-sieht-wie-GTK-aus Theme-Engine gab es eben als ich mich das letzte mal damit ernsthaft beschäftigt habe nicht und in einem Forenpost o.ä. stand auch der Kommentar dass es nicht nur noch keiner gemacht hat. Hingegen über die Qt-Theme-mit-gtk-nutzen Theme-Engine bin ich mehrfach gestolpert.
Bei mir ist es auch entsprechend umgekehrt, ich ziehe ein gtk-Programm auch mit Abstrichen gegenüber einem Qt-Programm grundsätzlich vor. Leider ist mir z.B. kein TeamSpeak-Client für gtk bekannt. Und so wie es aussieht ist das *nichtmal Qt3*. Mit ein wenig Mischung kann ich auch leben, das Theme ist mir wichtiger als eine identische Menüstruktur. Mir ging es nur auf den Keks dass das Qt-Programm - damals glaube ich noch Skype - richtig hässlich aussah und ich per Theme nichts daran ändern konnte.
KDE habe ich schon lange nicht mehr gesehen oder benutzt, aber ich denke auch mal, dass in einer fast reinen KDE-Umgebung entsprechend gtk-Programme genauso wie ein Fremdkörper wirken wie bei mir die Qt-Programme. Aber KDE4 schaue ich mir gelegentlich auf nem Knoppix oder so mal an...
Mir ging es nur auf den Keks dass das Qt-Programm - damals glaube ich noch Skype - richtig hässlich aussah und ich per Theme nichts daran ändern konnte. Skype verwendet (inzwischen) Qt4. Dafür brauchst du auch Qt4-Themes.
Von Kevin Krammer am Di, 19. Februar 2008 um 18:25 #
So wie ich das verstanden habe unterstützt gtk eine Art Plugins für Themes
Qt Styles sind auch Plugins.
Die ganze Sache hört sich für mich eher nach einer Ausrede an.
Man könnte dann eine Installation nach "LSB" haben, ohne gtk und Qt.
Ich denke es gibt eine LSB Variante für Server, ohne des "Desktop" Teil.
Wenn ein Hersteller Qt nutzen möchte schreibt er an sein Programm dran "Benötigt LSB-Modul Qt".
Der Punkt ist, dass in so einem Fall der Hersteller praktisch immer auf die Sicherheit zurückgreifen wird, die ihm das selber mitliefern bringt.
Die wesentliche Idee hinter der LSB ist eben, das zu vermeiden, in dem man das Vorhandensein von Bibliotheken mit großer Verbreitung spezifiziert.
So etwas automatisch zusätzlich zu installieren sollte eigentlich jeder Paketmanager automatisch hinbekommen.
Um das zu tun, müsste zumindest das Paket immer am System vorhanden sein, d.h. nur halt nicht entpackt und installiert. Diese zusätzliche Komplexität, auch wenn sie vielleicht klein ist, ist einfach unnötig, denn sie hat praktisch keinen Vorteil (Größe dürfte entpackt sehr ähnlich sein und die paar Verzeichniseinträge sind auch nicht gerade problematisch)
Um das zu tun, müsste zumindest das Paket immer am System vorhanden sein, d.h. nur halt nicht entpackt und installiert. Nein, das LSB-RPM muss nur z.B. von lsb-desktop (hängt von Gtk+, Qt, etc. ab) abhängig sein. Jeder halbwegs brauchbare Paketmanager sollte es schaffen, diese simple Abhängigkeit aufzulösen.
Auch zertifizierte Distributionen sind "von Haus aus" nicht unbedingt LSB-konform. Ubuntu 6.06 z.B. ist LSB-zertifiziert, installiert aber standardmäßig kein Qt.
Von Kevin Krammer am Mi, 20. Februar 2008 um 12:05 #
Pakettechnisch schon richtig, aber wenn das Paket nicht schon vorhanden ist, kann es unter Umständen nicht automatisch installiert werden.
Für einen Softwarehersteller ist es nur interessant, wenn seine Software ganz sicher installiert werden kann.
Wenn das System die externe Verfügbarkeit des nicht installierten Pakets garantieren kann, zum Beispiel weil es auf der Installations-CD drauf ist und vom Benutzer ohnehin erwartet wird, dass er sie bei Bedarf zu Hand hat, dann geht das natürlich schon.
Ubuntu 6.06 z.B. ist LSB-zertifiziert, installiert aber standardmäßig kein Qt.
Interessant. D.h. das wenn ich als Benutzer unter Ubuntu ein LSb-RPM installiere, dass dann ein automatischer Mechanismus im Ubuntu Basissystem dafür sorgt, dass zusätzlich zum LSB-Basis Paket auch das LSB-Desktop Paket installiert wird? Ist das nicht aufwendiger und weniger zuverlässig als es gleich zu installieren?
> "benötigt optionales LSB-Modul bla", wobei die Anzahl solcher optionaler Module nicht zu groß werden sollte Genau das ist halt der Punkt: Die Fixierung darauf, unbedingt auf das Vorhandensein des "feindlichen" Toolkits verzichten zu können und "die reine Lehre" zu genießen dürfte im realen Umfeld der tagtäglichen Systeme eher zweitrangig sein und besitzt in dieser Form bis auf die Diskussion GTK/GNOME/Qt/KDE eigentlich keine anderen Beispiele.
Aber nehmen wir mal Qt: Das Basis-Set an Qt-Bibliotheken samt dazugehöriger, GTK-fremder Bibliotheken belegt auf meinem System (unoptimiert) etwa 20MB. Wenn man die Dokumentation und ein paar andere Dinge wegstreicht, kommt man sicher auf 15 oder weniger. Ähnlich wird es sich bei GTK verhalten. Angesichts dieser Tatsache und heutiger Leistungsfähigkeiten der verwendeten Systeme grenzt es fast an Arbeitsbehinderung, separate GTK/Qt-Module für die LSB samt "unsere Anwendung benötigt LSB-Qt/GTK" auf den Verpackungen und in den Anleitungen zu fordern, wobei gleichzeitig der Nutzen der Aktion gegen null tendiert und die angestrebte Einfachheit der Spezifikation pervertiert wird.
Ich denke wer ein Gentoo nutzt und die USE-Flags entsprechend ausreizt, der weiß, wie man Abhängigkeiten auch ohne LSB-"Metapackete" in den Griff bekommt. (falls Du das meintest) ;)
Von Gentoorianer am Di, 19. Februar 2008 um 17:41 #
Eigentlich nicht. Ich meinte eher das "sind ja nur 20MB". Ein 20MB Binärpaket ist schnell installiert aber Qt oder den gtk-Krams zu kompilieren dauert halt ein Weilchen. Aber die USE-Flags sind es in der Tat wert. *G*
Nichtsdestotrotz muss Qt kompiliert werden. Aber wer Gentoo benutzt und ein LSB-konformes System haben will, d.h. nach jedem emerge die LSB-Testsuite drüber laufen lassen, ists halt selbst schuld.
> Also ich hab nur einen Grafikkartentreiber installiert, nämlich den der auf meine Hardware passt.
Dir traue ich höchstens zu, daß einen (binären) Grafikkartentreiber *nach*installiert hast, aber nie und nimmer alle nicht benötigten GraKa-Treiber aus Xorg deinstalliert hast...
Kann mir jemand vielleicht erklären, ob die prozedur zum starten von Dämonen vom lsb abgeedeckt werden?
Mich stört nämlich schon lange, das die init skript zwischen den distributionen nicht austauschbar sind (startproc bei SuSE, oder start-stop-daemon bei debian)?
Hört sich für mich erstmal so an als wäre startproc von SuSe nicht standardkonform. Debian kenne ich und das Verhalten der init-scripts deckt sich mit der Spezifikation von LSB.
das "stabile" KDE 3.5x basiert doch auf Qt3 während KDE 4.0x für Otto Normalverbraucher noch nicht in Frage kommt.
Ich kenne viele nicht ganz so erfahrene linux user die schon auf kde 4.0.1 setzten und bis jetzt keine probleme haben. viele denken an manchen sachen das es bugs sein dabei ist es nur eine änderung. Das soll nicht heißen Bug = Feature das soll nur heißen das man kde 4.0 und kde 3.5 nicht miteinader vergleichen kann. es sind 2 verschiedene sache und kde 4.0 wurde da komplett von neu auf aufgebaut. bitte teste mal kde 4.0.1 ein oder 2 tage lang internsiv und dann poste nochmal was :)
Danke
2. Für Qt3 gibt es _keinen_ Support von Trolltech/Nokia mehr. Es ist undenkbar, solche Software verpflichtend zu machen, wo Niemand mehr Probleme behebt. Dazu kommt, dass Qt4 ohnehin viel mächtiger und besser ist.
3. Auch KDE4-User kommen auf absehbare Zeit nicht ohne Qt3 aus (KDE PIM, KOffice und vieles mehr). Viele KDE-Teilprojekte werden auch bei KDE 4.1 noch nicht so weit sein. Ich lese die KOffice-Mailingliste, und es ist traurig. KWord ist nicht release-fähig und "keiner" kann/will das so bald ändern (also mit Geld oder Code).
4. Der LSB-Standard ist auch nicht für die Distribution selbst gedacht. Er beschränkt und entscheidet nicht, was eine Distribution so alles macht. Natürlich kann auch eine KDE 3.x oder eine Gnome-Distribution die Qt4-Bibliotheken enthalten. Warum auch nicht? Beim Standard geht es darum, was externe Software-Anbieter voraussetzen können, wenn ein System sich "LSB 3.2 konform" nennt.
5. Der LSB-Standard braucht keine Optionen, da er nichts verbietet, sondern per se nur auf das Minimum der Gemeinsamkeit abhebt (das immer stärker wächst).
6. Der LSB-Standard wird nicht von Dir, sondern von Distributoren erstellt. Vielleicht weil diese solche Sachen verstehen?
Gruss,
Kay
Der LSB Standard muss da jetzt anziehen, damit die Distributionen sich darauf einstellen können und beim nächsten/übernächsten/... Release die Kriterien erfüllen zu können.
Mit diesem Update sind sicher beide Versionen enthalten und werden es auch einige Versionen lang bleiben. Die Empfehlung sagt lediglich aus, dass es vermutlich nicht zielführend ist, ein neues Produkt auf der älteren Version zu beginnen, weil sie im Rahmen des "Deprecation" Prozesses irgendwann nicht mehr garantiert vorhanden sein wird.
Im Fallen von D-Bus müssen neben dem eigentlichen Protokoll vermutlich auch Sachen wie Standardverzeichnisse für .service Dateien, Format der Introspectiondaten und vielleicht auch die Basisbibliothek libdbus fixiert werden.
Also solange nicht klar ist, welche Kommandos garantiert verfügbar sein müssen, nützt D-Bus NICHTS.
Ich bin mir bewusst, dass es Bemühungen gibt, diese Dinge zu regeln. Aber das braucht stets Zeit, so auch in diesem Fall.
Gruss,
Kay
Die Verfügbarkeit von D-Bus ansich wäre schon für sich interessant, weil Hersteller dann zum Beispiel ihrerseits Funktionalität via D-Bus zur Verfügung stellen können, zum Beispiel um die Anwendung über ein Script zu steuern.
Ich formuliere um: Warum Qt UND gtk+!? Nach LSB muss man also sowohl gtk+ als auch Qt haben? Naja wenn sich die Qt-Programme wenigstens in den Desktop einfügen würden... (Oder kann Qt4 endlich so wie gtk+ pixmapbasierende Themes? Es gibt ja eine Engine damit gtk-Programme ein Qt-Theme benutzen aber umgekehrt konnte es ja nicht gehen..)
Tut das denn GTK oder gnome?
Ich benutze soetwas nicht, dashalb auch die Frage, aber wenn ich das richtig verstanden habe macht qtcurve das...
Klar ich hätte ein Theme nehmen können das mir zwar nicht gefällt aber bei dem wenigstens alle Programme gleich (schlecht) aussehen... Ich hatte nach 'nem Qt-Theme geschaut - wegen des vorhandenen Wrappers - aber mir hat nicht mal ansatzweise was gefallen. Geschmackssache eben. Und qtcurve gab es da wohl auch noch nicht, das sieht nämlich tatsächlich ganz ansehnlich aus. Teilweise können da auch Inkompatibilitäten eine Rolle gespielt haben (32bit Qt-Binärprogramm in 64bit-Umgebung), so dass ich die schönen Themes nicht nutzen konnte.
Warum Python UND Perl, warum C und C++, warum ATI UND Nvidia Treiber?
Ist heute Dein schlechter Tag?? So einen Schwachsinn hab ich schon lange nicht mehr gelesen!
C/C++ hinkt auch. Ich hab ja nichts dagegen dass es Qt/KDE und gtk/GNOME gibt. Ich verstehe nur nicht ganz warum ein Standard vorschreibt *beides* installieren zu müssen. Am ehesten trifft noch der Vergleich Python/Perl. Aber als Anwender brauche ich normalerweise gar nicht zu bemerken ob gerade Perl oder Python werkelt, genau wie bei C/C++. Es fällt mir also insbesondere nicht auf wenn ich viele Perl und viele Python-Programme mische. Wie gesagt, bei gtk/Qt sehe ich den Unterschied deutlich.
"Geben kann" hört sich so nach technischer Limitierung an, aber soweit mir bekannt ist, dürften die Styleengines ziemlich die gleichen Möglichkeiten bieten.
Ich verstehe nur nicht ganz warum ein Standard vorschreibt *beides* installieren zu müssen.
Der Standard schreibt nicht vor "beides" zu installieren, sondern aus der Auswahl aller zur Zeit verwendeten, nur die zwei am häufigsten benutzen Bibliotheken für GUI Programme.
Das deckt zwar nicht alle Anwendungen ab, aber für die meisten Hersteller ist es nun möglich, sich auf das Vorhandensein ihres Softwarestacks zu verlassen.
Würde man für Standardkonformität sowohl Nur-GTK oder Nur-Qt zulassen, wäre das als garantierte Basis relativ unbrauchbar, weil dann trotz Konformität die jeweilig verwendete Bibliothek mit geliefert werden müsste, weil ja im ungünstigen Fall die jeweils andere installiert wäre.
Das wäre praktisch äquivalent zu den LSB Versionen zuvor, wo keine dieser Bibliotheken garantiert vorhanden war.
Anscheinend leider, zumindest früher, nicht. Es gibt ein Modul um Qt-Themes in gtk-Programmen zu benutzen aber eine Suche nach einer gtk-in-Qt-Theme-Engine ergab einen Kommentar, dass dies nicht möglich sei. Ich weiß nicht mehr woran es lag, ich glaube an der fehlenden Pixmap-Engine. Eventuell wäre es möglich gewesen das gtk-Theme dass ich verwenden wollte in Qt nachzubauen. Umgekehrt wäre es jedoch trivial gewesen ein Qt-Theme in gtk zu benutzen.
Zugegeben für die Hersteller ist das wohl praktisch einfach für gtk oder Qt entwickeln zu können und relativ sicher zu sein, dass es läuft. Aber ob damit ein einheitlicher Desktop erreicht werden kann sehe ich noch nicht so recht...
weil dann trotz Konformität die jeweilig verwendete Bibliothek mit geliefert werden müsste,
Iiiihhh, nein! Dann lieber optional und an das Programm dranschreiben: "benötigt optionales LSB-Modul bla", wobei die Anzahl solcher optionaler Module nicht zu groß werden sollte. Noch besser - wenn auch viel Aufwand - wäre es den GUI-Code so zu kapseln, dass eine gtk- und eine Qt-Version angeboten werden können.
Ich habe keine Ahnung was eine Pixmap-Engine sein soll, aber nachdem ein Qt Style vollen Zugriff auf die QPainter API hat, kann er auch jederzeit Pixmaps benutzen.
Technisch dürfte daher keine Limitierung bestehen, vermutlich hat es einfach nur noch niemand gemacht, weil es ohnhin Styles gibt, die für beide Stylesysteme verfügbar sind.
Aber ob damit ein einheitlicher Desktop erreicht werden kann sehe ich noch nicht so recht...
Die Zielsetzung der LSB ist auch nur das Vereinheitlichen der Plattform für Softwarehersteller, d.h. das garantierte Vorhandensein bestimmter Versionen von Bibliotheken, usw.
Dann lieber optional und an das Programm dranschreiben: "benötigt optionales LSB-Modul bla", wobei die Anzahl solcher optionaler Module nicht zu groß werden sollte.
Optional ist praktisch äquivalent zu selbst mit liefern, weil sich der Hersteller eben nicht darauf verlassen kann, eben wie in dem vorher genannten Beispiel, wo das Vorhandensein einer der beiden Bibliotheken schon für Konformität reichen würde.
Die Zielsetzung der LSB ist ja eben, diese "Zufälligkeit" zu reduzieren, also die am häufigsten verwendeten Bibliotheken praktisch zu garantieren.
Noch besser - wenn auch viel Aufwand - wäre es den GUI-Code so zu kapseln, dass eine gtk- und eine Qt-Version angeboten werden können.
Das lässt sich durchaus machen, zum Beispiel über Wrapper wie wxWidgets oder SWT.
Viele Entwickler arbeiten aber lieber direkt mit den eigentlichen Toolkits, manchmal um nicht von kleinere Ungleichheiten in Wrapperimplementierungen überrascht zu werden.
Nochmal zu optional: Mein Vorschlag wäre man definiert Module, z.B. das Modul "gtk+" und das Modul "Qt". Damit wäre fest definiert, wie eine LSB-konforme gtk- bzw. Qt-Installation auszusehen hat. Man könnte dann eine Installation nach "LSB" haben, ohne gtk und Qt. Für Qt-Programme benötigt man dann eine Installation nach "LSB + Modul Qt". Wenn ein Hersteller Qt nutzen möchte schreibt er an sein Programm dran "Benötigt LSB-Modul Qt". Ein daraufhin installiertes Qt sieht dann für alle Hersteller gleich aus. So etwas automatisch zusätzlich zu installieren sollte eigentlich jeder Paketmanager automatisch hinbekommen.
hast Du gesehen/gelesen, was mit Plasma in Qt 4.4 (also KDE 4.1) alles gemacht wird? Es gibt keinen Zweifel, dass Qt alles nötige für solche Engines kann. Sie können neuerdings Painter und funktionale Widgets ganz frei mischen.
Ich persönlich hatte eher den Eindruck, dass es technisch nicht lohnend wäre, solche Engines zu machen, weil der umgekehrte Weg erfolgreicher ist. Das kommt davon, dass in Gnome die Button-Reihenfolge zwingend festgeschrieben ist und in KDE nicht. Ich vermute, das sind die technischen Hinderungsgründe, die Du meintest?
Damit hat man unter Gnome mit einer Theme-Engine, die Qt wie GTK (in Gnome) aussehen lässt, einen konsistenten Desktop. Unter KDE kann keine GTK-Engine jemals erreichen, dass fest kodierte Positionen von "OK/Abbruch" Buttons in Gnome-Programmen (bei mir freeciv, ein GTK-Spiel) automatisch passend korrigiert werden.
Dazu kommt, dass der KDE-User in der Regel auch mal das zweitbeste Programm vorzieht, wenn es nur eine KDE-Oberfläche hat. KDE hat schon länger und erfolgreicher die Integration aller Programme vorangetrieben, während unter Gnome lange auch Programme wie Firefox, OpenOffice.org (das praktisch garkeinen Code von Gnome nutzt), etc. dabei waren, es also insgesamt akzeptabler war, dass alles irgendwie immer ein wenig anders von Programm zu Programm war.
Mir erscheinen heute schon reine Qt3/Qt4 Programme als intolerable Fremdkörper, ob ihrer schwachen Dialoge, komischer Menubezeichner, etc.
Gruss,
Kay
Die Qt-sieht-wie-GTK-aus Theme-Engine gab es eben als ich mich das letzte mal damit ernsthaft beschäftigt habe nicht und in einem Forenpost o.ä. stand auch der Kommentar dass es nicht nur noch keiner gemacht hat. Hingegen über die Qt-Theme-mit-gtk-nutzen Theme-Engine bin ich mehrfach gestolpert.
Bei mir ist es auch entsprechend umgekehrt, ich ziehe ein gtk-Programm auch mit Abstrichen gegenüber einem Qt-Programm grundsätzlich vor. Leider ist mir z.B. kein TeamSpeak-Client für gtk bekannt. Und so wie es aussieht ist das *nichtmal Qt3*. Mit ein wenig Mischung kann ich auch leben, das Theme ist mir wichtiger als eine identische Menüstruktur. Mir ging es nur auf den Keks dass das Qt-Programm - damals glaube ich noch Skype - richtig hässlich aussah und ich per Theme nichts daran ändern konnte.
KDE habe ich schon lange nicht mehr gesehen oder benutzt, aber ich denke auch mal, dass in einer fast reinen KDE-Umgebung entsprechend gtk-Programme genauso wie ein Fremdkörper wirken wie bei mir die Qt-Programme. Aber KDE4 schaue ich mir gelegentlich auf nem Knoppix oder so mal an...
Skype verwendet (inzwischen) Qt4. Dafür brauchst du auch Qt4-Themes.
Qt Styles sind auch Plugins.
Die ganze Sache hört sich für mich eher nach einer Ausrede an.
Man könnte dann eine Installation nach "LSB" haben, ohne gtk und Qt.
Ich denke es gibt eine LSB Variante für Server, ohne des "Desktop" Teil.
Wenn ein Hersteller Qt nutzen möchte schreibt er an sein Programm dran "Benötigt LSB-Modul Qt".
Der Punkt ist, dass in so einem Fall der Hersteller praktisch immer auf die Sicherheit zurückgreifen wird, die ihm das selber mitliefern bringt.
Die wesentliche Idee hinter der LSB ist eben, das zu vermeiden, in dem man das Vorhandensein von Bibliotheken mit großer Verbreitung spezifiziert.
So etwas automatisch zusätzlich zu installieren sollte eigentlich jeder Paketmanager automatisch hinbekommen.
Um das zu tun, müsste zumindest das Paket immer am System vorhanden sein, d.h. nur halt nicht entpackt und installiert.
Diese zusätzliche Komplexität, auch wenn sie vielleicht klein ist, ist einfach unnötig, denn sie hat praktisch keinen Vorteil (Größe dürfte entpackt sehr ähnlich sein und die paar Verzeichniseinträge sind auch nicht gerade problematisch)
Nein, das LSB-RPM muss nur z.B. von lsb-desktop (hängt von Gtk+, Qt, etc. ab) abhängig sein. Jeder halbwegs brauchbare Paketmanager sollte es schaffen, diese simple Abhängigkeit aufzulösen.
Auch zertifizierte Distributionen sind "von Haus aus" nicht unbedingt LSB-konform. Ubuntu 6.06 z.B. ist LSB-zertifiziert, installiert aber standardmäßig kein Qt.
Für einen Softwarehersteller ist es nur interessant, wenn seine Software ganz sicher installiert werden kann.
Wenn das System die externe Verfügbarkeit des nicht installierten Pakets garantieren kann, zum Beispiel weil es auf der Installations-CD drauf ist und vom Benutzer ohnehin erwartet wird, dass er sie bei Bedarf zu Hand hat, dann geht das natürlich schon.
Ubuntu 6.06 z.B. ist LSB-zertifiziert, installiert aber standardmäßig kein Qt.
Interessant.
D.h. das wenn ich als Benutzer unter Ubuntu ein LSb-RPM installiere, dass dann ein automatischer Mechanismus im Ubuntu Basissystem dafür sorgt, dass zusätzlich zum LSB-Basis Paket auch das LSB-Desktop Paket installiert wird?
Ist das nicht aufwendiger und weniger zuverlässig als es gleich zu installieren?
Genau das ist halt der Punkt: Die Fixierung darauf, unbedingt auf das Vorhandensein des "feindlichen" Toolkits verzichten zu können und "die reine Lehre" zu genießen dürfte im realen Umfeld der tagtäglichen Systeme eher zweitrangig sein und besitzt in dieser Form bis auf die Diskussion GTK/GNOME/Qt/KDE eigentlich keine anderen Beispiele.
Aber nehmen wir mal Qt: Das Basis-Set an Qt-Bibliotheken samt dazugehöriger, GTK-fremder Bibliotheken belegt auf meinem System (unoptimiert) etwa 20MB. Wenn man die Dokumentation und ein paar andere Dinge wegstreicht, kommt man sicher auf 15 oder weniger. Ähnlich wird es sich bei GTK verhalten. Angesichts dieser Tatsache und heutiger Leistungsfähigkeiten der verwendeten Systeme grenzt es fast an Arbeitsbehinderung, separate GTK/Qt-Module für die LSB samt "unsere Anwendung benötigt LSB-Qt/GTK" auf den Verpackungen und in den Anleitungen zu fordern, wobei gleichzeitig der Nutzen der Aktion gegen null tendiert und die angestrebte Einfachheit der Spezifikation pervertiert wird.
lg
Erik
lg
Erik
Oh Gott, jetzt hab' ich das auch mit "ck" geschrieben. Man steinige mich bitte.
lg
Erik
Dir traue ich höchstens zu, daß einen (binären) Grafikkartentreiber *nach*installiert hast, aber nie und nimmer alle nicht benötigten GraKa-Treiber aus Xorg deinstalliert hast...
ob die prozedur zum starten von Dämonen
vom lsb abgeedeckt werden?
Mich stört nämlich schon lange, das die init skript zwischen den
distributionen nicht austauschbar sind (startproc bei SuSE, oder start-stop-daemon bei debian)?
Hört sich für mich erstmal so an als wäre startproc von SuSe nicht standardkonform. Debian kenne ich und das Verhalten der init-scripts deckt sich mit der Spezifikation von LSB.