> Freedesktop, ist das nicht die "hier haben wir halbfertigen Gnome-Schrott, das soll > jetzt unser desktopübergreifender Standard sein" Sache?
nein, das ist nur die fud die kde user verbreiten, wenn sie sich nicht erklären können warum gnome features unterstützt welche kde noch nicht unterstützt.
> warum gnome features unterstützt welche > kde noch nicht unterstützt.
Du kannst bestimmt Beispiele nennen.
Freedesktop.org ist eine Plattform zur Kooperation, wo _Vorschläge_ gemacht werden und Technologien entwickelt werden. fdo definiert aber keine Standards. Damit es de-facto-Standard wird, muss es zuerst zumindest von Gnome und KDE implementiert werden. Nur weil etwas auf fdo gehostet wird (da ist auch viel fragwürdiges dabei), ist niemand verpflichtet, es bedenkenlos zu implementieren.
Ja cairo und glitz, fribidi etc. außerdem harfbuzz das in die pango-14.x serie eingeflossen. Ich weiß KDE4 wird das auch alles können nur gnome ist echt ein bisschen weiter....
> Ich weiß KDE4 wird das auch alles können > nur gnome ist echt ein bisschen weiter....
Wenn ein Gnome-Entwickler etwas neues entwickelt, um eine Gnome-Problem zu lösen und das ganze als Library konzipiert und diese auf fdo veröffentlicht, ist das eine gute Sache. Nur ist Gnome deshalb nicht "weiter". Dasselbe mit DBUS: Gnome war mit seinem overengineered Bonobo/Corba-Krempel unzufrieden, und DBUS sollte das lösen (zufällig sehr ähnlich zu DCOP). Fein. Nur ist Gnome hier nicht weiter, nur weil es eines seiner Probleme löst, das KDE so gar nicht hatte (DCOP lief und das wunderbar). Dass KDE sich da natürlich nicht so sehr beeilen muss, seine schon existierende Lösung zu ersetzen, sollte klar sein.
Zu fribidi: Da würde ich gerne wissen, ob das nun das BIDI-Problem besser löst als aktuelle Qt3-Implementierungen.
Kannst du mir erkären wozu man als Qt/KDE-Nutzer Cairo benötigt? Cairo ist eine Lösung für GTK-Probleme nicht für KDE/Qt-Probleme. Es soll da gerüchterweise eine Lösung in KDE geben die älter als Cairo ist und angeblich sogar perfekt funktionieren soll...
Dasselbe gilt für Glitz. Braucht man als Qt/KDE-Nutzer ebenfalls nicht, weil Qt4 und somit das künftige KDE diese Funktionalität bereits beinhaltet.
Des weiteren wozu braucht der Mensch in KDE Pango, wenn das I18n von KDE schon immer funktionierte?
Angeblich beschäftigt man sich in Gnome gerade mit dem Problem der zigtausend Minilibs die doppelt und dreifach redundant Funktionalität bereitstellen. Sicher wird man hinterher dann auch sagen, dass KDE da aber langsam war, dabei hat KDE dieses Problem von vornherein nie gehabt... Ja Glauben und Nachplappern kann manchmal echt den Blick auf die Realität vernebeln.
Ach ja dumme Frage, kann man eigentlich in Gedit per ssh ne Datei auf nem Server öffnen und wieder abspeichern?
Natürlich gibt es eine Reihe sinnvoller Dinge die man gemeinsam auf fdo gelöst hat und löst. Nur löst man das eben in KDE nicht indem man eine C-Lib irgendwo hinklatscht, sondern gelegentlich auch noch weiter als Gnome und KDE denkt und auch an ganz andere Desktops denkt (Soll da auch noch XFCE usw. geben). Und genau diesem Umstand, dass es auf weit mehr Oberflächen funkionieren muss trägt Portland Rechnung.
Außerdem legt KDE legt großen Wert darauf, dass Gnomeprogramme sich in KDE eben nicht wie Fremdkörper anfühlen. Analog ist mir wenig Engagement auf Gnomeseite für Integration von KDE-Programmen bekannt, obwohl es Bedarf gäbe (K3b ist da mal nur ein Beispiel).
> jetzt unser desktopübergreifender Standard sein" Sache?
nein, das ist nur die fud die kde user verbreiten, wenn sie sich nicht erklären können warum gnome features unterstützt welche kde noch nicht unterstützt.
> kde noch nicht unterstützt.
Du kannst bestimmt Beispiele nennen.
Freedesktop.org ist eine Plattform zur Kooperation, wo _Vorschläge_ gemacht werden und Technologien entwickelt werden. fdo definiert aber keine Standards. Damit es de-facto-Standard wird, muss es zuerst zumindest von Gnome und KDE implementiert werden. Nur weil etwas auf fdo gehostet wird (da ist auch viel fragwürdiges dabei), ist niemand verpflichtet, es bedenkenlos zu implementieren.
> nur gnome ist echt ein bisschen weiter....
Wenn ein Gnome-Entwickler etwas neues entwickelt, um eine Gnome-Problem zu lösen und das ganze als Library konzipiert und diese auf fdo veröffentlicht, ist das eine gute Sache. Nur ist Gnome deshalb nicht "weiter". Dasselbe mit DBUS: Gnome war mit seinem overengineered Bonobo/Corba-Krempel unzufrieden, und DBUS sollte das lösen (zufällig sehr ähnlich zu DCOP). Fein. Nur ist Gnome hier nicht weiter, nur weil es eines seiner Probleme löst, das KDE so gar nicht hatte (DCOP lief und das wunderbar). Dass KDE sich da natürlich nicht so sehr beeilen muss, seine schon existierende Lösung zu ersetzen, sollte klar sein.
Zu fribidi: Da würde ich gerne wissen, ob das nun das BIDI-Problem besser löst als aktuelle Qt3-Implementierungen.
Dasselbe gilt für Glitz. Braucht man als Qt/KDE-Nutzer ebenfalls nicht, weil Qt4 und somit das künftige KDE diese Funktionalität bereits beinhaltet.
Des weiteren wozu braucht der Mensch in KDE Pango, wenn das I18n von KDE schon immer funktionierte?
Angeblich beschäftigt man sich in Gnome gerade mit dem Problem der zigtausend Minilibs die doppelt und dreifach redundant Funktionalität bereitstellen. Sicher wird man hinterher dann auch sagen, dass KDE da aber langsam war, dabei hat KDE dieses Problem von vornherein nie gehabt... Ja Glauben und Nachplappern kann manchmal echt den Blick auf die Realität vernebeln.
Ach ja dumme Frage, kann man eigentlich in Gedit per ssh ne Datei auf nem Server öffnen und wieder abspeichern?
Natürlich gibt es eine Reihe sinnvoller Dinge die man gemeinsam auf fdo gelöst hat und löst. Nur löst man das eben in KDE nicht indem man eine C-Lib irgendwo hinklatscht, sondern gelegentlich auch noch weiter als Gnome und KDE denkt und auch an ganz andere Desktops denkt (Soll da auch noch XFCE usw. geben). Und genau diesem Umstand, dass es auf weit mehr Oberflächen funkionieren muss trägt Portland Rechnung.
Außerdem legt KDE legt großen Wert darauf, dass Gnomeprogramme sich in KDE eben nicht wie Fremdkörper anfühlen. Analog ist mir wenig Engagement auf Gnomeseite für Integration von KDE-Programmen bekannt, obwohl es Bedarf gäbe (K3b ist da mal nur ein Beispiel).