*ROTFL* Also Kde ist bereits vollständig auf D-Bus umgestellt ? Ach so ja und die tolle Cairo-Unterstützung ist ja schon seit Jaaahren in KDE. Also ich kann da wirklich nichts finden was KDE schon hat und gnome nicht, lediglich Scrollkeeper ist echt besch***. Die großen Features sind doch vor allem, dass gnome-print nach gtk geht und gnome-vfs nach glib, alles recht kleine Dinge. Solange nieamdn was wirklich großes einfällt wird es wohl auch keinen Sprung auf 3.0 geben. Gnome hat eben langsam aber sicher wichtig Dinge wie cairo, d-bus, poppler etc eingebunden ohne gleich einen riesigen Versionssprung zu machen.
Ach so und "glohreiche" hätte dir deine Rechtschreibprüfung wohl anzeigen sollen, wenn du es schon nicht selber weißt, eine Feature das bei deinem ach so tollen KDE wohl immer noch nicht implementiert ist obwohl es Firefox nun schon seit fast einem Jahr kann.
Was hat dein Geschwafel mit dem Kontext zu tun ? Ich nutze hier im Übrigen GNOME 2.18.1 und Firefox 2.0.0.3, da muss demnach wohl die GNOME Fehlerkorrekturschnittstelle defekt sein. Vieleicht, solltest du dir erstmal die berechtigten Kommentare der einzelnen User durchlesen, bevor du solche Schnellschüsse leistest.
Ach ja, und warum passiert dir dann noch sowas hier: "nieamdn"?! Wie ineffizient ist es eigentlich, wenn jedes Programm seine eigene Rechtschreibprüfung mitbringt? Ein vernünftiger Desktop stellt diese Funktionalität Desktop-weit allen Anwendungen zur Verfügung. Behalt doch demnächst einfach diese dämliche Rechtschreibkritik für dich, dann bleiben dir auch solche Peinlichkeiten erspart...
kompletter Schrott, gnome konnte die gstreamer-API ändern, bonobo etc veralten lassen und durch DBUS ersetzen, das Printingframework über den Haufen werfen etc, alles OHNE die komplette API über den Haufen zu werfen. Sieh die mal die gnome-2.0-API an und das was wir heute haben. Da liegen Welten dazwischen, trotzdem laufen die alten Programme noch immer. gtk+-2.4 und gtk-2.12 (wenn es bald kommt) werden sicher weiter auseinanderliegen als qt3 und qt4 trotzdem hat man die alten Dinge (noch) nicht weggeworfen. So ganz schlecht ist die gtk+-api wohl also doch nicht. Hier mal der Vergleich: - Artur unter KDE komplett neu entwickelt, bei gtk+2 hat man langsam aber sicher cairo integriert und zahlreiche Backends, dabei sollte man sich echtmal ansehen was mittlerweile alles möglich wäre wenn die Entwickler ihre Programme schon alle vollständig auf cairo umgestellt hätten (das wird sicher noch vor KDE-4.0 der Fall sein) - Fonon, bei gnome hat man gstreamer eingeführt - Änderungen am icon-Theme, bei gnome sicher kein grund für ein Major release - Objectframework wurde bei gtk+2 auch heimlich still und leise umgestellt Besonders begeisterend sind allerdings die Dinge die sich um Gnome herum entwickeln: - libabiword - enchant/libsexy - die vielen gtk bindings für: ruby, php, tcl und wirklich vieele Sprachen. Zum Glück(!) hat man sich nämlich für C entschieden und ist dadurch offener auch für nicht OOP-Sprachen.
>kompletter Schrott, gnome konnte die gstreamer-API ändern, bonobo etc veralten lassen und durch DBUS ersetzen, das Printingframework über den Haufen werfen etc, alles OHNE die komplette API über den Haufen zu werfen. Sieh die mal die gnome-2.0-API an und das was wir heute haben.
Richtig, aber man hat dafür eben den Preis gezahlt, wie du weiter unten selber gesagt hast, dass man den ganzen alten Code in den Gtk+ libs gelassen hat. Es ist schon fast beängstigend wie oft man mittlerweile über den Tag "deprecated" stoßt, wenn man sich die API Doc ansieht.
Das ist mein persönlicher Wunsch für die mittelfristige Zukunft von GNOME. Selbst wenn man keine Bahnbrechende Ideen für ein 3.0 hat (was ich eher sogar gut finde, mir gefällt die evolutionäre Entwicklung). Nachdem mal alles von den gnome-libs in Gtk+, glib usw. implementiert hat was man wollte, wäre es imho Zeit für ein Gtk+3 und ein GNOME3, auch wenn es nur daraus besteht gnome-libs und bonobo endlich komplett raus zu schmeißen und den Gtk+ Code aufzuräumen indem mal alle veralteten Funktionen entfernt.
Ja da hast du Recht, das war auch das einzige Argument für einen 3.0 Zweig. Da die alten Api's zu maintainen immer schwerer wird. Aber Gnome wird von vielen Firmen eingesetzt und viele kommerzielle Anwendungen setzen auf GTK+ (keine Lizensgebüren ...), deswegen ist ein API-break immer schwierig.
Dürfte ansich kein Problem sein, zwei Versionen der Bibliothek parallel zu installieren.
Genau genommen ist das eine Bitte der proprietären Entwickler, also das beibehalten älterer Versionen über einen längeren Zeitraum. D..h. das wurde in dieser Form am Destop Architect Meeting 3 der OSDL/Linuxfoundation so von Industrievertretern vorbebracht. Ihnen ist natürlich klar, dass andere Entwickler, besonders die von Freier Software, die neueren Versionen benutzen werden, sobald sie verfügbar sind, aber sie hätten gerne so einen Art Phase-out Zeitrahmen, wo die alten Versionen noch sicher zur Defaultinstallation der Distrbutionen gehören und ihnen Zeit gibt, ihre Software anzupassen
Komisch, Qt von Trolltech wird auch von vielen namenhaften Firmen eingesetzt und die sind sogar dankbar, dass sie einen kommerziellen Support erhalten. Also anders als "Go, fix it yourself and sent patches" Gelaber. Vielen Unternehmen ist es wichtig, Ansprechpartner und offiziellen Support zu erhalten. Das verursacht am Ende weniger Kosten.
Auch die Qt Lizenz ist sehr lobenswert, da man dann als Unternehmen nicht ständig zu hören bekomme "You use GTK+ which is open source, so why is VMWare closed source" - solche Kommentare oder ähnlich.
> kompletter Schrott, gnome konnte die gstreamer-API ändern, bonobo etc veralten > lassen und durch DBUS ersetzen, das Printingframework über den Haufen werfen etc, > alles OHNE die komplette API über den Haufen zu werfen.
Also hat Gnome viele Altlasten, abgebrochenen Baustellen und frickelei.
> Artur unter KDE komplett neu entwickelt
Arthur gehört zu Qt.
> Fonon, bei gnome hat man gstreamer eingeführt
Phonon (und KDE allgemein) kann doch ein ganzes stück mehr als gstreamer (und Gnome).
> Änderungen am icon-Theme, bei gnome sicher kein grund für ein Major release
Bei KDE auch nicht, es sei denn man würde die komplette Namens-Struktur ändern. Wenn Gnome da einfach in Minor-Versionen umstellt, mit der alten vollgestopften API, dann wäre das ein Armutszeugnis und anzeichen für eine Miserable Entwicklungsführung.
KDE hat einen Grundsatz für Saubere Entwicklung. Innerhalb der Major-Version wird alles möglichst Stabil und Kompatibel gehalten. Grundlegende Änderungen die alten Code brechen sind nur bei Major-Versionen erlaubt. Das erlaubt sauberen und Stabilen Code, und kommt der Entwicklungsgeschwindigkeit zugute.
> die vielen gtk bindings für: ruby, php, tcl und wirklich vieele Sprachen. Zum
Mehr als Python, Ruby, Perl und JavaScript braucht man eh nicht :>
> Glück(!) hat man sich nämlich für C entschieden und ist dadurch offener auch > für nicht OOP-Sprachen.
Schmarn. Python ist C-Basiert, und hat trotzdem eine hervoragende Anbindung an die KDE- und Qt-Libs.
Von Ikone des guten Geschmacks am So, 27. Mai 2007 um 14:01 #
Phonon (und KDE allgemein) kann doch ein ganzes stück mehr als gstreamer (und Gnome). Echt? Phonon ganz allein kann mehr als Gstreamer alleine? Verrat das mal den KDE-Entwicklern, die denken nämlich es ist nur eine Abstraktionsschicht zu Multimediaframeworks wie z.B. gstreamer. :) Schenke ich dir: http://www.clueponbook.com/cluepon.html
Von Ikone des guten Geschmacks am So, 27. Mai 2007 um 15:05 #
heute (2007) Danke. Ich habe mich gerade gefragt welches Jahr wir haben. :p
ist es kaum einsetzbar, da einfach zu vieles nicht funktioniert. Also wenn die Gstreamer-Nutzung von zahlreichen Musikplayern (Rhythmbox, banshee, exaile....), Musikeditoren(Jokosher), Videoeditoren(pitivi), Rippern(soundjuicer,thoggen) und auf Embedded Devices (N770/800) bei dir "kaum einsetzbar" bedeutet... Soll man das jetzt als sprachliche Ungenauigkeit oder mangelndes Sachverständniss deinerseits einordnen? Naja, kannst ja selbst auswählen, oder? :)
* Rhythmbox, Totem usw. offerieren auch Xine als Backend. * GSTreamer ist dafür bekannt, von heute auf morgen ebend mal die API zu brechen. * Hat GStreamer von 1999 an bis einschliesslich 2007 mit oben genannten Probleme. * Daher bietet KDE die Phonon Abstraktionsschicht an, um genau dieser Problematik entgegen zu wirken. * Ich kann über die Embedded Devices N770 und N800 nicht mitreden, vermutlich hat man hier aber eine "letztmals" stabile Version von GStreamer benutzt und darauf aufgebaut.
Zum Thema "mangelndes Sachverständnis" möchte ich dich auf folgende - ebenfalls mit mangelndem Sachverständnis beglückten namenhaften Personen aus dem Open Source Umfeld verweisen.
Von Ikone des guten Geschmacks am So, 27. Mai 2007 um 15:55 #
Nochmal Fakten Ja wo sind sie denn für deine Aussage, dass gstreamer kaum benutzbar ist?
* Rhythmbox, Totem usw. offerieren auch Xine als Backend. Ich hatte dich doch gebeten, dich vorher zu informieren. Ist das denn so schwer? Rhythmbox bietet schon seit längerem keinen Support mehr für xine. Ich bezweifle sogar, dass es sich noch mit xine bauen lässt. Desweiteren ist es kein Argument für Unbrauchbarkeit des einen Frameworks, wenn Applikationen auch ein anderes Backend unterstützen. Umgedreht wird ein Schuh draus: Es spricht gegen ein Framework, würde es nicht benutzt werden. Dein "Fakt" ist also keins.
* GSTreamer ist dafür bekannt, von heute auf morgen ebend mal die API zu brechen. * Hat GStreamer von 1999 an bis einschliesslich 2007 mit oben genannten Probleme. Von heute auf morgen wurde gar nix gebrochen. Und das Problem mit den APIs haben alle Projekte. Oder wo ist da der Unterschied zwischen dem guten API-Bruch bei QT (gibt ja immerhin schon 4 Versionen) und dem schlechten API-Bruch bei Gstreamer? Sowohl QT als auch Gstreamer bieten i.Ü. die Möglichkeit beides parallell zu installieren.
* Ich kann über die Embedded Devices N770 und N800 nicht mitreden, vermutlich hat man hier aber eine "letztmals" stabile Version von GStreamer benutzt und darauf aufgebaut. Was ist das denn für ein Schwachsinn? Was sollen sie denn sonst verwenden? Die Version aus dem Trunk? o_O
* Daher bietet KDE die Phonon Abstraktionsschicht an, um genau dieser Problematik entgegen zu wirken. Wieder nur heiße Luft. KDE will sich nicht von einem Framework abhängig machen. Dass man Gstreamer unterstützt spricht gegen deine These der Unbenutzbarkeit. Oder machen sich die KDE-Entwickler die Mühen für etwas, dass laut deiner "Fachaussage" unbenutzbar ist. ;)
Ach und zu deinen Links: Ich habe sie schon gelesen und verstanden. Du ganz offensichtlich nicht.
Zu Rhythmbox und Totem und alles was GStreamer unter GNOME benutzt. Als jemand der Regelmäßig GNOME in den vergangenen Jahren gebaut hat, kann ich dir bestätigen, es schon immer die Hölle war GSTreamer gescheit mit GNOME zum Bauen zu bewegen. Lange Zeit galt gnome-media als nicht baubar, da es immer noch auf GST 0.8 basierte und nicht GST 0.10. Gleiches war mit Rhythmbox und Totem, mal lies sich das Eine mit 0.9 compilieren, mal das Andere und das in einem gesamten was GNOME entsprechen sollte.
Zu Qt, es heisst Qt von Trolltech und nicht QT alias Quick Time von Apple
Zu Phonon. Phonon bietet eine Abstraktionsschicht zu unterschiedlichen Multimedia engines. Dazu gehört leider nunmal auch GStreamer. Gut jedoch, dass man unter KDE nicht dazu gezwungen wird, da man auch Xine verwenden kann. Die KDE Entwickler schaffen nur eine Schnittstelle zu GStreamer, mehr nicht.
Zu den Links, Sie geben genau das wieder, was die KDE Entwickler als Probleme deuten und zwar genau das, welches du mich "ums mal so auszudrücken" einen Lügner titulierst. Nämlich, dass man daher kein GSTreamer direkt verwenden möchte, gerade weil hier die API nie konsistent gehalten wird. Warum liest du dir nicht die Links durch ?
Zitat: http://www.pro-linux.de/news/2006/9688.html "Kritiker dieser Position merken an, dass GStreamer kein stabiles API für die Lebensdauer von KDE 4 bereitstellen könne."
Zitat: http://aseigo.blogspot.com/2006/05/id-like-another-black-eye-please.html "a believable API/ABI stability guarantee that covers kde4's lifespan"
Nämlich, dass man daher kein GSTreamer direkt verwenden möchte, gerade weil hier die API nie konsistent gehalten wird. Nenne mir eine verbreitete Bibliothek, deren API nie verändert wurde. Du kannst wohl kaum verlangen, dass GStreamer auch noch in 10 Jahren das gleiche API verwendet. Das wird auch bei den kdelibs nicht so sein, da bis dahin KDE 5 oder eher KDE 6 draußen ist.
"Kritiker dieser Position merken an, dass GStreamer kein stabiles API für die Lebensdauer von KDE 4 bereitstellen könne." Und KDE bietet kein stabiles API für die Lebensdauer von Linux. Das Problem ist hier doch, dass KDE bezüglich der Major-Releases an Qt angepasst ist. API-Wechsel von Qt bedeuten daher, dass KDE irgendwann umgeschrieben werden muss. Man will sich halt nicht noch eine Abhängigkeit bezüglich APIs hinzuholen.
Aber das hat wiederum nichts mit GStreamer an sich zu tun. Man traut sich ja zum Glück auch nicht, irgendeine andere Bibliothek fest zu verdrahten.
Schmarn. Python ist C-Basiert, und hat trotzdem eine hervoragende Anbindung an die KDE- und Qt-Libs. Wer verwendet sie? Sämtliche KDE-Anwendungen, die mir begegnet sind, sind in C++ programmiert. Eigentlich sind die KDE-Bindings alle überflüssig.
Naja, Vergleich kann man das schwer nennen, die aufgeführten Punkte haben nichts mit der Versionsänderung oder der Art der Weiterentwicklung zu tun.
die vielen gtk bindings für: ruby, php, tcl und wirklich vieele Sprachen
Wie das auch für Qt der Fall ist. Aber ich verstehe schon, dass es einfacher ist, immer das selbe zu behauten und sich nicht damit abzumühen, am aktuellen Informationsstand zu bleiben.
> Also Kde ist bereits vollständig auf D-Bus umgestellt ?
Ja, wenn man davon absieht das die Neue Major-Version (die DBUS dann bringt) noch bis Oktober in der Entwicklung ist. Der Sprung zur neuen Major-Version ist übrigens durch die Entwicklungstechnische Bindung an Qt begründet.
> Ach so ja und die tolle Cairo-Unterstützung ist ja schon seit Jaaahren in KDE.
Warum sollte KDE Cairo nutzen, wenn Qt bereits eine bessere Lösung mitbringt?
Weil man da offen ist und sagt "Also wer nun unbedingt Cairo nutzen will statt Arthur, na der darf auch seinen Frieden mit uns schließen und wir ermöglichen es ihm". Aus Offenheit und Freundlichkeit gegenüber der Konkurrenz auf Defizite zu schließen ist mehr als nur ne grobe Unhöflichkeit.
Und weißt du wie es mit Phonon ist? Genauso. Jeder darf sein $Lieblingsmultimediadingens unter KDE nutzen. Phonon sei Dank. Gerade, ja wirklich gerade im Soundbereich gibt es so viele Spezialprogramme (und meist gibt es von jeder Sorte nur dieses eine) mit einer Vielzahl an exotischen Bibliotheken und unterschiedlichsten Konzepten, da ist es die heilige Pflicht eines Desktops, dass sich das gerade vom Desktop für einfaches "Plingpling" genutzte Soundbackend dem Soundbackend der gerade genutzten Profimusikanwendung anpasst und NICHT umgekehrt den Programmierer deiser Spezialanwendung zu beglücken, wie es GNOME versucht (der Programmierer von Enligthenment, der auch ein paar Soundprogramme geschrieben hat bspw. dürfte sich ziemlich schwer bekehren lassen).
KDE ist der integrative Desktop: X-Beliebige Anwendungen sollen sich dort möglichst unkompliziert harmonisch einfügen können ohne dass deren Programmierer von KDE zwangsbeglückt werden.
KDE ist der integrative Desktop: X-Beliebige Anwendungen sollen sich dort möglichst unkompliziert harmonisch einfügen können ohne dass deren Programmierer von KDE zwangsbeglückt werden. Kann eine Nicht-KDE/Qt-Anwendung auf Phonon zurückgreifen?
Also Kde ist bereits vollständig auf D-Bus umgestellt?
Natürlich. Nachdem es jahrelang bereits das selbe Prinip erfolgreich mit DCOP umgesetzt hat. Diese jahrelangen positiven Erfahrungen sind ja auch der Grund, warum es zur Weiterentwicklung D-Bus gekommen ist.
Gnome hat eben langsam aber sicher wichtig Dinge wie cairo, d-bus, poppler etc eingebunden ohne gleich einen riesigen Versionssprung zu machen.
Das hat KDE auch. Der Versionssprung ist bedingt durch den Wunsch, das Framework neu zu gestalten und die neue Qt Version benutzen zu können. Äquivalent basierte das bei GNOME beim Umstieg von GTK1 auf GTK2. Die 3.x Serie weiter zu führen wäre durchaus auch machbar gewesen, aber die Vorteile einer Erneuerung haben in diesem Fall überwogen. Das ist immer eine Fall zu Fall Entscheidung
Von Anonymous Coward am So, 27. Mai 2007 um 13:22 #
Also Kde ist bereits vollständig auf D-Bus umgestellt? Nö, KDE hat bereits seit Jahren ein eigenes ausgereiftes und perfekt funktionierendes IPC-System, nämlich DCOP. Die Umstellung auf D-Bus findet doch nur deswegen statt, weil man zu den Betonköpfen von GNOME kompatibel sein will. Ach so ja und die tolle Cairo-Unterstützung ist ja schon seit Jaaahren in KDE. Nö, aber wozu auch? Qt hat ein eigenes Vektorgrafik-Framework, und das ist um Größenordnungen schneller als Cairo (http://zrusin.blogspot.com/2006/10/benchmarks.html). Also ich kann da wirklich nichts finden was KDE schon hat und gnome nicht, Wie wär's z. B. mit einem konsistenten Optionsdialog in praktisch allen KDE-Applikationen? Überhaupt ist die Funktionalität der GNOME-Bibliotheken einfach nur ein Witz, wenn man's mit den kdelibs vergleicht. Vom darunter liegenden Toolkit ganz zu schweigen, Qt ist einfach besser als GTK. Man denke nur an das Qt meta object system, das Vektorgrafik-Framework usw. usf. Dann gibt es noch solche Sachen wie einen ordentlichen PIM (Evolution muss ja ziemlich grausam sein, nach allem was man darüber hört), Konqueror (ein Universaltalent dank kioslaves und kparts), Amarok, DCOP und noch viele mehr. Ach so und "glohreiche" hätte dir deine Rechtschreibprüfung wohl anzeigen sollen, wenn du es schon nicht selber weißt, eine Feature das bei deinem ach so tollen KDE wohl immer noch nicht implementiert ist obwohl es Firefox nun schon seit fast einem Jahr kann. Von all deinen Aussagen ist das wohl die dümmste. Konqueror 3.2, erschienen im Februar 2004, hatte bereits eine Rechtschreibprüfung. Genauso wie übrigens fast alle anderen KDE-Programme wo man Text schreibt, z. B. Kopete, Konversation uvm. Und das zeigt mal wieder, dass die kdelibs einfach viel mehr können als der GNOME-Abfall, und dass diese Funktionalität auch genutzt wird. So ist z. B. praktisch jede KDE-Applikation per DCOP scriptbar, weil es so einfach ist, das einzubauen! Und das geht immer weiter: Mit KDE4 wird ein komplettes Scripting-Framework kommen, so dass man KDE-Applikationen in vielen Sprachen wird scripten können, dann gibt es solche Sachen wie solid usw. usf. GNOME ist einfach nur LÄCHERLICH dagegen.
Die Umstellung auf D-Bus findet doch nur deswegen statt, weil man zu den Betonköpfen von GNOME kompatibel sein will.
Sowas ist reichlich unnötig.
Natürlich ist es eine Bonuspunkt, das bei D-Bus keine gefühlte Desktopabhängigkeit vorhanden ist, d.h.zusätzlich zu technischen Unabhängigkeit, die ja auch schon bei DCOP gegeben war.
Allerdings hat D-Bus als Nachfolger von DCOP auch ein paar andere Vorteile, die bei kurzer Betrachtung zwar vielleicht nicht ausgereicht hätten, um eine Umstellungen zu begünstigen, aber bei längerem Auseinandersetzen dann auch ohne Cross-Desktop Bonus zur Entscheidung für einen Wechsle geführt hätten.
> Allerdings hat D-Bus als Nachfolger von DCOP auch ein paar andere Vorteile
Fakten:
D-Bus ist als Nachfolger zu Corba, später Bonobo von GNOME gedacht.
GNOME hat mittlerweile die dritte IPC Schnittstelle verheizt, da die ersten Zwei (we want to implement everything correctly) leider ein Fehlgriff waren.
DCOP unter KDE funktioniert, funktionierte und würde auch weiterhin funktionieren. Vorteile von D-Bus gibt es keine, es hat die Sache nur schwieriger für die KDE Developer gemacht.
Von Ikone des guten Geschmacks am So, 27. Mai 2007 um 14:15 #
Vorteile von D-Bus gibt es keine, es hat die Sache nur schwieriger für die KDE Developer gemacht. Komisch. Ich dachte dein Vorposter ist selbst KDE-Entwickler. Der sollte das doch besser beurteilen können.
.. und so ignoriert man (ihr) die folgenden Fakten, die ich hier gerne nochmals nennen möchte.
D-Bus ist als Nachfolger zu Corba, später Bonobo von GNOME gedacht.
GNOME hat mittlerweile die dritte IPC Schnittstelle verheizt, da die ersten Zwei (we want to implement everything correctly) leider ein Fehlgriff waren.
DCOP unter KDE funktioniert, funktionierte und würde auch weiterhin funktionieren.
Zum Thema KDE hat es die Sache schwieriger gestaltet, ob du nun Bindings maintainest oder nicht sei dahingestellt. Ich habe täglich genug mit KDE Entwicklern zu tun die wie wild fluchen. Ich sehe keine Vorteile gegenüber dem DCOP ausser dass es Plattform neutral zu sein scheint. Da es aber aus dem GNOME Lager stammt, um ihre vorher verheizten IPC Mechanismen zu substituieren ist es für mich stark GNOME lastig. Dabei ist es für mich nebensächlich, das KDE Entwickler maßgeblich an der Spezifikation mitwirkten.
D-Bus ist als Nachfolger zu Corba, später Bonobo von GNOME gedacht.
D-Bus ist technologisch ein Nachfolger von DCOP, ein einfacher Mechanismus um Methode an Objekten in anderen Prozessesn aufzurufen. Dass es in GNOME möglicherweise Bonobo und dessen Corba Verwendung ersetzt oder ersetzen wird, ändert nichts daran, dass die Parallelitäten zwischen DCOP und D-Bus wesentlich stärker sind.
DCOP unter KDE funktioniert, funktionierte und würde auch weiterhin funktionieren.
Ich denke, das wird niemand bestreiten.
Zum Thema KDE hat es die Sache schwieriger gestaltet
Auch eine unbestreitbare Tatsache. D-Bus erlaubt eine flexiblere Objektadressierung und ist daher ein bischen schwieriger als DCOP, allerdings sind speziell im Falle von Qt4 die D-Bus Bindings äußerst fein umgesetzt, so dass der Aufwand für den einzelnen Applikationsentwickler nicht wesentlich größer sein sollte. Im Gegensatz zu DCOP kann man praktisch jede QObject Instanz ohne Extraaufwand über D-Bus bereitstellen.
ob du nun Bindings maintainest oder nicht sei dahingestellt
http://www.freedesktop.org/wiki/Software/DBusBindings und dort nach meinem Namen suchen
Ich sehe keine Vorteile gegenüber dem DCOP ausser dass es Plattform neutral zu sein scheint
Wie schon erwähnt, mehr Flexibilität in der Objektadressierung. Das ist vorallem für Applikationen interessant, die intern als Resultat eines Aufrufs Objekte dynamisch anlegen und dann zum Zugriff anbieten, zum Beispiel die KOffice Anwendungen.
Ein weiterer Vorteil ist die Abfrage von Aufrufinformation, d.h. Introspection, die zusätzlich zu den syntaktischen Informationen auch Anmerkungen transportieren kann. Speziell bei der direkten Benutzung durch Anwender interessant.
Noch ein Vorteil wäre dann Activation, also die Möglichkeit, Applikationen für ein bestimmtes Interface bei Bedarf automatisch gestartet zu bekommen, so dass die aufrufende Applikation nicht zuerst abfragen muss, ob die Partnerapplikation gerade läuft. Zu einem gewissen Teil gabs das schon auch unter DCOP, aber war es praktisch auf einen 1:1 Relation zwischen DCOP Name und Applikationsname beschränkt.
Da es aber aus dem GNOME Lager stammt, um ihre vorher verheizten IPC Mechanismen zu substituieren ist es für mich stark GNOME lastig.
Nur weil Havoc auch GNOME Entwickler ist? D-Bus ist vermutlich von allen auf freedesktop.org beheimateten Projekten das mit der größten Desktopneutralität. Die Basisbibliothek libdbus hat keine Abhängigkeiten, nicht mal glib, und es wurde bereits von zwei Binding Teams gezeigt, dass die Spezifikation so sauber ist, dass sie vollständig von Binärebene weg reimplementiertbar ist.
> Konqueror (ein Universaltalent dank kioslaves und kparts), Amarok, DCOP und noch viele mehr.
Wann kann man mit einer KDE Anwendung wie Kaffeine eigentlich endlich Videodateien von einem Samba Server streamen ohne daß das KDE Zeugs das Video temporär auf der Festplatte im Temp Ordner zwischenspeichern muß?
Entweder eine Limitation in der Backend API, d.h. keine ausreichende Unterstützung von applikationsgesteurten Datenpuffern, oder eine vereinfachte Benutzung von KIO, d.h. Download und Benutzung als lokale Datei gegenüber der doch aufwendigereren direkten Handhabung eintreffender Datenpakete.
Das ist ausgschlossen. Wenn ich von Windows mit dem Videolan Client auf ein Video zugreife, daß mit Samba zur Verfügung gestellt wird, dann wird das Video gestreamt.
Dann gibt es noch solche Sachen wie einen ordentlichen PIM Ein ordentlicher PIM verschluckt sich nicht an Terminserien, etwas das Outlook schon seit über 10 Jahren einwandfrei beherrscht. Selbst Evolution hat damit keine Probleme. Leider ist Kontact aus diesem Grunde für mich unbrauchbar.
Amarok Ich kann den Hype um diese Anwendung nicht verstehen. Viele Features fehlen, werden aber laut Mark wohl auch niemals implementiert, z.B. der uneingeschränkte Zugriff auf ID3-Tags/VorbisComments.
Also Kde ist bereits vollständig auf D-Bus umgestellt ?
Ach so ja und die tolle Cairo-Unterstützung ist ja schon seit Jaaahren in KDE. Also ich kann da wirklich nichts finden was KDE schon hat und gnome nicht, lediglich Scrollkeeper ist echt besch***. Die großen Features sind doch vor allem, dass gnome-print nach gtk geht und gnome-vfs nach glib, alles recht kleine Dinge. Solange nieamdn was wirklich großes einfällt wird es wohl auch keinen Sprung auf 3.0 geben. Gnome hat eben langsam aber sicher wichtig Dinge wie cairo, d-bus, poppler etc eingebunden ohne gleich einen riesigen Versionssprung zu machen.
Ach so und "glohreiche" hätte dir deine Rechtschreibprüfung wohl anzeigen sollen, wenn du es schon nicht selber weißt, eine Feature das bei deinem ach so tollen KDE wohl immer noch nicht implementiert ist obwohl es Firefox nun schon seit fast einem Jahr kann.
Wie ineffizient ist es eigentlich, wenn jedes Programm seine eigene Rechtschreibprüfung mitbringt? Ein vernünftiger Desktop stellt diese Funktionalität Desktop-weit allen Anwendungen zur Verfügung.
Behalt doch demnächst einfach diese dämliche Rechtschreibkritik für dich, dann bleiben dir auch solche Peinlichkeiten erspart...
OT: Der Versionssprung ist nicht wegen d-bus oder poppler, sondern wegen der Umstellung auf Qt4 (Codebase musste gänzlich umgeschrieben werden)
- Artur unter KDE komplett neu entwickelt, bei gtk+2 hat man langsam aber sicher cairo integriert und zahlreiche Backends, dabei sollte man sich echtmal ansehen was mittlerweile alles möglich wäre wenn die Entwickler ihre Programme schon alle vollständig auf cairo umgestellt hätten (das wird sicher noch vor KDE-4.0 der Fall sein)
- Fonon, bei gnome hat man gstreamer eingeführt
- Änderungen am icon-Theme, bei gnome sicher kein grund für ein Major release
- Objectframework wurde bei gtk+2 auch heimlich still und leise umgestellt
Besonders begeisterend sind allerdings die Dinge die sich um Gnome herum entwickeln:
- libabiword
- enchant/libsexy
- die vielen gtk bindings für: ruby, php, tcl und wirklich vieele Sprachen. Zum Glück(!) hat man sich nämlich für C entschieden und ist dadurch offener auch für nicht OOP-Sprachen.
Richtig, aber man hat dafür eben den Preis gezahlt, wie du weiter unten selber gesagt hast, dass man den ganzen alten Code in den Gtk+ libs gelassen hat. Es ist schon fast beängstigend wie oft man mittlerweile über den Tag "deprecated" stoßt, wenn man sich die API Doc ansieht.
Das ist mein persönlicher Wunsch für die mittelfristige Zukunft von GNOME. Selbst wenn man keine Bahnbrechende Ideen für ein 3.0 hat (was ich eher sogar gut finde, mir gefällt die evolutionäre Entwicklung). Nachdem mal alles von den gnome-libs in Gtk+, glib usw. implementiert hat was man wollte, wäre es imho Zeit für ein Gtk+3 und ein GNOME3, auch wenn es nur daraus besteht gnome-libs und bonobo endlich komplett raus zu schmeißen und den Gtk+ Code aufzuräumen indem mal alle veralteten Funktionen entfernt.
mfg paul
Genau genommen ist das eine Bitte der proprietären Entwickler, also das beibehalten älterer Versionen über einen längeren Zeitraum. D..h. das wurde in dieser Form am Destop Architect Meeting 3 der OSDL/Linuxfoundation so von Industrievertretern vorbebracht. Ihnen ist natürlich klar, dass andere Entwickler, besonders die von Freier Software, die neueren Versionen benutzen werden, sobald sie verfügbar sind, aber sie hätten gerne so einen Art Phase-out Zeitrahmen, wo die alten Versionen noch sicher zur Defaultinstallation der Distrbutionen gehören und ihnen Zeit gibt, ihre Software anzupassen
Auch die Qt Lizenz ist sehr lobenswert, da man dann als Unternehmen nicht ständig zu hören bekomme "You use GTK+ which is open source, so why is VMWare closed source" - solche Kommentare oder ähnlich.
> lassen und durch DBUS ersetzen, das Printingframework über den Haufen werfen etc, > alles OHNE die komplette API über den Haufen zu werfen.
Also hat Gnome viele Altlasten, abgebrochenen Baustellen und frickelei.
> Artur unter KDE komplett neu entwickelt
Arthur gehört zu Qt.
> Fonon, bei gnome hat man gstreamer eingeführt
Phonon (und KDE allgemein) kann doch ein ganzes stück mehr als gstreamer (und Gnome).
> Änderungen am icon-Theme, bei gnome sicher kein grund für ein Major release
Bei KDE auch nicht, es sei denn man würde die komplette Namens-Struktur ändern. Wenn Gnome da einfach in Minor-Versionen umstellt, mit der alten vollgestopften API, dann wäre das ein Armutszeugnis und anzeichen für eine Miserable Entwicklungsführung.
KDE hat einen Grundsatz für Saubere Entwicklung. Innerhalb der Major-Version wird alles möglichst Stabil und Kompatibel gehalten. Grundlegende Änderungen die alten Code brechen sind nur bei Major-Versionen erlaubt. Das erlaubt sauberen und Stabilen Code, und kommt der Entwicklungsgeschwindigkeit zugute.
> die vielen gtk bindings für: ruby, php, tcl und wirklich vieele Sprachen. Zum
Mehr als Python, Ruby, Perl und JavaScript braucht man eh nicht :>
> Glück(!) hat man sich nämlich für C entschieden und ist dadurch offener auch
> für nicht OOP-Sprachen.
Schmarn. Python ist C-Basiert, und hat trotzdem eine hervoragende Anbindung an die KDE- und Qt-Libs.
Echt? Phonon ganz allein kann mehr als Gstreamer alleine? Verrat das mal den KDE-Entwicklern, die denken nämlich es ist nur eine Abstraktionsschicht zu Multimediaframeworks wie z.B. gstreamer. :)
Schenke ich dir: http://www.clueponbook.com/cluepon.html
Danke. Ich habe mich gerade gefragt welches Jahr wir haben. :p
ist es kaum einsetzbar, da einfach zu vieles nicht funktioniert.
Also wenn die Gstreamer-Nutzung von zahlreichen Musikplayern (Rhythmbox, banshee, exaile....), Musikeditoren(Jokosher), Videoeditoren(pitivi), Rippern(soundjuicer,thoggen) und auf Embedded Devices (N770/800) bei dir "kaum einsetzbar" bedeutet...
Soll man das jetzt als sprachliche Ungenauigkeit oder mangelndes Sachverständniss deinerseits einordnen? Naja, kannst ja selbst auswählen, oder? :)
* Rhythmbox, Totem usw. offerieren auch Xine als Backend.
* GSTreamer ist dafür bekannt, von heute auf morgen ebend mal die API zu brechen.
* Hat GStreamer von 1999 an bis einschliesslich 2007 mit oben genannten Probleme.
* Daher bietet KDE die Phonon Abstraktionsschicht an, um genau dieser Problematik entgegen zu wirken.
* Ich kann über die Embedded Devices N770 und N800 nicht mitreden, vermutlich hat man hier aber eine "letztmals" stabile Version von GStreamer benutzt und darauf aufgebaut.
Zum Thema "mangelndes Sachverständnis" möchte ich dich auf folgende - ebenfalls mit mangelndem Sachverständnis beglückten namenhaften Personen aus dem Open Source Umfeld verweisen.
Quellenverweise:
http://www.pro-linux.de/news/2006/9688.html
http://aseigo.blogspot.com/2006/05/id-like-another-black-eye-please.html
http://amarok.kde.org/blog/archives/91-Backends,-Phonon,-GStreamer.html
Ja wo sind sie denn für deine Aussage, dass gstreamer kaum benutzbar ist?
* Rhythmbox, Totem usw. offerieren auch Xine als Backend.
Ich hatte dich doch gebeten, dich vorher zu informieren. Ist das denn so schwer? Rhythmbox bietet schon seit längerem keinen Support mehr für xine. Ich bezweifle sogar, dass es sich noch mit xine bauen lässt.
Desweiteren ist es kein Argument für Unbrauchbarkeit des einen Frameworks, wenn Applikationen auch ein anderes Backend unterstützen. Umgedreht wird ein Schuh draus: Es spricht gegen ein Framework, würde es nicht benutzt werden. Dein "Fakt" ist also keins.
* GSTreamer ist dafür bekannt, von heute auf morgen ebend mal die API zu brechen.
* Hat GStreamer von 1999 an bis einschliesslich 2007 mit oben genannten Probleme.
Von heute auf morgen wurde gar nix gebrochen. Und das Problem mit den APIs haben alle Projekte. Oder wo ist da der Unterschied zwischen dem guten API-Bruch bei QT (gibt ja immerhin schon 4 Versionen) und dem schlechten API-Bruch bei Gstreamer? Sowohl QT als auch Gstreamer bieten i.Ü. die Möglichkeit beides parallell zu installieren.
* Ich kann über die Embedded Devices N770 und N800 nicht mitreden, vermutlich hat man hier aber eine "letztmals" stabile Version von GStreamer benutzt und darauf aufgebaut.
Was ist das denn für ein Schwachsinn? Was sollen sie denn sonst verwenden? Die Version aus dem Trunk? o_O
* Daher bietet KDE die Phonon Abstraktionsschicht an, um genau dieser Problematik entgegen zu wirken.
Wieder nur heiße Luft. KDE will sich nicht von einem Framework abhängig machen. Dass man Gstreamer unterstützt spricht gegen deine These der Unbenutzbarkeit. Oder machen sich die KDE-Entwickler die Mühen für etwas, dass laut deiner "Fachaussage" unbenutzbar ist. ;)
Ach und zu deinen Links: Ich habe sie schon gelesen und verstanden. Du ganz offensichtlich nicht.
Zu Rhythmbox und Totem und alles was GStreamer unter GNOME benutzt. Als jemand der Regelmäßig GNOME in den vergangenen Jahren gebaut hat, kann ich dir bestätigen, es schon immer die Hölle war GSTreamer gescheit mit GNOME zum Bauen zu bewegen. Lange Zeit galt gnome-media als nicht baubar, da es immer noch auf GST 0.8 basierte und nicht GST 0.10. Gleiches war mit Rhythmbox und Totem, mal lies sich das Eine mit 0.9 compilieren, mal das Andere und das in einem gesamten was GNOME entsprechen sollte.
Zu Qt, es heisst Qt von Trolltech und nicht QT alias Quick Time von Apple
Zu Phonon. Phonon bietet eine Abstraktionsschicht zu unterschiedlichen Multimedia engines. Dazu gehört leider nunmal auch GStreamer. Gut jedoch, dass man unter KDE nicht dazu gezwungen wird, da man auch Xine verwenden kann. Die KDE Entwickler schaffen nur eine Schnittstelle zu GStreamer, mehr nicht.
Zu den Links, Sie geben genau das wieder, was die KDE Entwickler als Probleme deuten und zwar genau das, welches du mich "ums mal so auszudrücken" einen Lügner titulierst. Nämlich, dass man daher kein GSTreamer direkt verwenden möchte, gerade weil hier die API nie konsistent gehalten wird. Warum liest du dir nicht die Links durch ?
Zitat: http://www.pro-linux.de/news/2006/9688.html
"Kritiker dieser Position merken an, dass GStreamer kein stabiles API für die Lebensdauer von KDE 4 bereitstellen könne."
Zitat: http://aseigo.blogspot.com/2006/05/id-like-another-black-eye-please.html
"a believable API/ABI stability guarantee that covers kde4's lifespan"
Planlos und lernresistent trifft es wohl eher. Hast du gerade eben wieder bewiesen.
Nenne mir eine verbreitete Bibliothek, deren API nie verändert wurde. Du kannst wohl kaum verlangen, dass GStreamer auch noch in 10 Jahren das gleiche API verwendet. Das wird auch bei den kdelibs nicht so sein, da bis dahin KDE 5 oder eher KDE 6 draußen ist.
"Kritiker dieser Position merken an, dass GStreamer kein stabiles API für die Lebensdauer von KDE 4 bereitstellen könne."
Und KDE bietet kein stabiles API für die Lebensdauer von Linux. Das Problem ist hier doch, dass KDE bezüglich der Major-Releases an Qt angepasst ist. API-Wechsel von Qt bedeuten daher, dass KDE irgendwann umgeschrieben werden muss. Man will sich halt nicht noch eine Abhängigkeit bezüglich APIs hinzuholen.
Aber das hat wiederum nichts mit GStreamer an sich zu tun. Man traut sich ja zum Glück auch nicht, irgendeine andere Bibliothek fest zu verdrahten.
Ja, da es eine vollkommen andere Aufgabe hat, ist es auf seinem Gebiet überlegen.
http://www.clueponbook.com/cluepon.html
http://www.clueponbook.com/cluepon.html
Wer verwendet sie? Sämtliche KDE-Anwendungen, die mir begegnet sind, sind in C++ programmiert. Eigentlich sind die KDE-Bindings alle überflüssig.
Naja, Vergleich kann man das schwer nennen, die aufgeführten Punkte haben nichts mit der Versionsänderung oder der Art der Weiterentwicklung zu tun.
die vielen gtk bindings für: ruby, php, tcl und wirklich vieele Sprachen
Wie das auch für Qt der Fall ist. Aber ich verstehe schon, dass es einfacher ist, immer das selbe zu behauten und sich nicht damit abzumühen, am aktuellen Informationsstand zu bleiben.
Ja, wenn man davon absieht das die Neue Major-Version (die DBUS dann bringt) noch bis Oktober in der Entwicklung ist. Der Sprung zur neuen Major-Version ist übrigens durch die Entwicklungstechnische Bindung an Qt begründet.
> Ach so ja und die tolle Cairo-Unterstützung ist ja schon seit Jaaahren in KDE.
Warum sollte KDE Cairo nutzen, wenn Qt bereits eine bessere Lösung mitbringt?
mfg Paul
Die Daten von http://zrusin.blogspot.com/2006/10/benchmarks.html deuten da auf anderes hin.
Trolltech wird in der nächsten Zeit bestimmt nicht auf Cairo setzen.
Und weißt du wie es mit Phonon ist? Genauso. Jeder darf sein $Lieblingsmultimediadingens unter KDE nutzen. Phonon sei Dank. Gerade, ja wirklich gerade im Soundbereich gibt es so viele Spezialprogramme (und meist gibt es von jeder Sorte nur dieses eine) mit einer Vielzahl an exotischen Bibliotheken und unterschiedlichsten Konzepten, da ist es die heilige Pflicht eines Desktops, dass sich das gerade vom Desktop für einfaches "Plingpling" genutzte Soundbackend dem Soundbackend der gerade genutzten Profimusikanwendung anpasst und NICHT umgekehrt den Programmierer deiser Spezialanwendung zu beglücken, wie es GNOME versucht (der Programmierer von Enligthenment, der auch ein paar Soundprogramme geschrieben hat bspw. dürfte sich ziemlich schwer bekehren lassen).
KDE ist der integrative Desktop: X-Beliebige Anwendungen sollen sich dort möglichst unkompliziert harmonisch einfügen können ohne dass deren Programmierer von KDE zwangsbeglückt werden.
Kann eine Nicht-KDE/Qt-Anwendung auf Phonon zurückgreifen?
Natürlich. Nachdem es jahrelang bereits das selbe Prinip erfolgreich mit DCOP umgesetzt hat. Diese jahrelangen positiven Erfahrungen sind ja auch der Grund, warum es zur Weiterentwicklung D-Bus gekommen ist.
Gnome hat eben langsam aber sicher wichtig Dinge wie cairo, d-bus, poppler etc eingebunden ohne gleich einen riesigen Versionssprung zu machen.
Das hat KDE auch. Der Versionssprung ist bedingt durch den Wunsch, das Framework neu zu gestalten und die neue Qt Version benutzen zu können. Äquivalent basierte das bei GNOME beim Umstieg von GTK1 auf GTK2.
Die 3.x Serie weiter zu führen wäre durchaus auch machbar gewesen, aber die Vorteile einer Erneuerung haben in diesem Fall überwogen. Das ist immer eine Fall zu Fall Entscheidung
Nö, KDE hat bereits seit Jahren ein eigenes ausgereiftes und perfekt funktionierendes IPC-System, nämlich DCOP. Die Umstellung auf D-Bus findet doch nur deswegen statt, weil man zu den Betonköpfen von GNOME kompatibel sein will.
Ach so ja und die tolle Cairo-Unterstützung ist ja schon seit Jaaahren in KDE.
Nö, aber wozu auch? Qt hat ein eigenes Vektorgrafik-Framework, und das ist um Größenordnungen schneller als Cairo (http://zrusin.blogspot.com/2006/10/benchmarks.html).
Also ich kann da wirklich nichts finden was KDE schon hat und gnome nicht,
Wie wär's z. B. mit einem konsistenten Optionsdialog in praktisch allen KDE-Applikationen? Überhaupt ist die Funktionalität der GNOME-Bibliotheken einfach nur ein Witz, wenn man's mit den kdelibs vergleicht. Vom darunter liegenden Toolkit ganz zu schweigen, Qt ist einfach besser als GTK. Man denke nur an das Qt meta object system, das Vektorgrafik-Framework usw. usf. Dann gibt es noch solche Sachen wie einen ordentlichen PIM (Evolution muss ja ziemlich grausam sein, nach allem was man darüber hört), Konqueror (ein Universaltalent dank kioslaves und kparts), Amarok, DCOP und noch viele mehr.
Ach so und "glohreiche" hätte dir deine Rechtschreibprüfung wohl anzeigen sollen, wenn du es schon nicht selber weißt, eine Feature das bei deinem ach so tollen KDE wohl immer noch nicht implementiert ist obwohl es Firefox nun schon seit fast einem Jahr kann.
Von all deinen Aussagen ist das wohl die dümmste. Konqueror 3.2, erschienen im Februar 2004, hatte bereits eine Rechtschreibprüfung. Genauso wie übrigens fast alle anderen KDE-Programme wo man Text schreibt, z. B. Kopete, Konversation uvm. Und das zeigt mal wieder, dass die kdelibs einfach viel mehr können als der GNOME-Abfall, und dass diese Funktionalität auch genutzt wird. So ist z. B. praktisch jede KDE-Applikation per DCOP scriptbar, weil es so einfach ist, das einzubauen! Und das geht immer weiter: Mit KDE4 wird ein komplettes Scripting-Framework kommen, so dass man KDE-Applikationen in vielen Sprachen wird scripten können, dann gibt es solche Sachen wie solid usw. usf. GNOME ist einfach nur LÄCHERLICH dagegen.
Sowas ist reichlich unnötig.
Natürlich ist es eine Bonuspunkt, das bei D-Bus keine gefühlte Desktopabhängigkeit vorhanden ist, d.h.zusätzlich zu technischen Unabhängigkeit, die ja auch schon bei DCOP gegeben war.
Allerdings hat D-Bus als Nachfolger von DCOP auch ein paar andere Vorteile, die bei kurzer Betrachtung zwar vielleicht nicht ausgereicht hätten, um eine Umstellungen zu begünstigen, aber bei längerem Auseinandersetzen dann auch ohne Cross-Desktop Bonus zur Entscheidung für einen Wechsle geführt hätten.
Fakten:
D-Bus ist als Nachfolger zu Corba, später Bonobo von GNOME gedacht.
GNOME hat mittlerweile die dritte IPC Schnittstelle verheizt, da die ersten Zwei (we want to implement everything correctly) leider ein Fehlgriff waren.
DCOP unter KDE funktioniert, funktionierte und würde auch weiterhin funktionieren.
Vorteile von D-Bus gibt es keine, es hat die Sache nur schwieriger für die KDE Developer gemacht.
Komisch. Ich dachte dein Vorposter ist selbst KDE-Entwickler. Der sollte das doch besser beurteilen können.
Mann, dachte ich auch ;)
Und ich dachte ich bin auch einer der D-Bus Bindings Maintainer und habe darum ein kleines bischen Einblick in D-Bus.
Tja, so schnell kann ein schöner Sonntag in Ernüchterung enden
D-Bus ist als Nachfolger zu Corba, später Bonobo von GNOME gedacht.
GNOME hat mittlerweile die dritte IPC Schnittstelle verheizt, da die ersten Zwei (we want to implement everything correctly) leider ein Fehlgriff waren.
DCOP unter KDE funktioniert, funktionierte und würde auch weiterhin funktionieren.
Zum Thema KDE hat es die Sache schwieriger gestaltet, ob du nun Bindings maintainest oder nicht sei dahingestellt. Ich habe täglich genug mit KDE Entwicklern zu tun die wie wild fluchen. Ich sehe keine Vorteile gegenüber dem DCOP ausser dass es Plattform neutral zu sein scheint. Da es aber aus dem GNOME Lager stammt, um ihre vorher verheizten IPC Mechanismen zu substituieren ist es für mich stark GNOME lastig. Dabei ist es für mich nebensächlich, das KDE Entwickler maßgeblich an der Spezifikation mitwirkten.
D-Bus ist technologisch ein Nachfolger von DCOP, ein einfacher Mechanismus um Methode an Objekten in anderen Prozessesn aufzurufen.
Dass es in GNOME möglicherweise Bonobo und dessen Corba Verwendung ersetzt oder ersetzen wird, ändert nichts daran, dass die Parallelitäten zwischen DCOP und D-Bus wesentlich stärker sind.
DCOP unter KDE funktioniert, funktionierte und würde auch weiterhin funktionieren.
Ich denke, das wird niemand bestreiten.
Zum Thema KDE hat es die Sache schwieriger gestaltet
Auch eine unbestreitbare Tatsache. D-Bus erlaubt eine flexiblere Objektadressierung und ist daher ein bischen schwieriger als DCOP, allerdings sind speziell im Falle von Qt4 die D-Bus Bindings äußerst fein umgesetzt, so dass der Aufwand für den einzelnen Applikationsentwickler nicht wesentlich größer sein sollte. Im Gegensatz zu DCOP kann man praktisch jede QObject Instanz ohne Extraaufwand über D-Bus bereitstellen.
ob du nun Bindings maintainest oder nicht sei dahingestellt
http://www.freedesktop.org/wiki/Software/DBusBindings
und dort nach meinem Namen suchen
Ich sehe keine Vorteile gegenüber dem DCOP ausser dass es Plattform neutral zu sein scheint
Wie schon erwähnt, mehr Flexibilität in der Objektadressierung. Das ist vorallem für Applikationen interessant, die intern als Resultat eines Aufrufs Objekte dynamisch anlegen und dann zum Zugriff anbieten, zum Beispiel die KOffice Anwendungen.
Ein weiterer Vorteil ist die Abfrage von Aufrufinformation, d.h. Introspection, die zusätzlich zu den syntaktischen Informationen auch Anmerkungen transportieren kann. Speziell bei der direkten Benutzung durch Anwender interessant.
Noch ein Vorteil wäre dann Activation, also die Möglichkeit, Applikationen für ein bestimmtes Interface bei Bedarf automatisch gestartet zu bekommen, so dass die aufrufende Applikation nicht zuerst abfragen muss, ob die Partnerapplikation gerade läuft.
Zu einem gewissen Teil gabs das schon auch unter DCOP, aber war es praktisch auf einen 1:1 Relation zwischen DCOP Name und Applikationsname beschränkt.
Da es aber aus dem GNOME Lager stammt, um ihre vorher verheizten IPC Mechanismen zu substituieren ist es für mich stark GNOME lastig.
Nur weil Havoc auch GNOME Entwickler ist? D-Bus ist vermutlich von allen auf freedesktop.org beheimateten Projekten das mit der größten Desktopneutralität. Die Basisbibliothek libdbus hat keine Abhängigkeiten, nicht mal glib, und es wurde bereits von zwei Binding Teams gezeigt, dass die Spezifikation so sauber ist, dass sie vollständig von Binärebene weg reimplementiertbar ist.
Wann kann man mit einer KDE Anwendung wie Kaffeine eigentlich endlich Videodateien von einem Samba Server streamen ohne daß das KDE Zeugs das Video temporär auf der Festplatte im Temp Ordner zwischenspeichern muß?
Entweder eine Limitation in der Backend API, d.h. keine ausreichende Unterstützung von applikationsgesteurten Datenpuffern, oder eine vereinfachte Benutzung von KIO, d.h. Download und Benutzung als lokale Datei gegenüber der doch aufwendigereren direkten Handhabung eintreffender Datenpakete.
Wenn ich von Windows mit dem Videolan Client auf ein Video zugreife, daß mit Samba zur Verfügung gestellt wird, dann wird das Video gestreamt.
Ein ordentlicher PIM verschluckt sich nicht an Terminserien, etwas das Outlook schon seit über 10 Jahren einwandfrei beherrscht. Selbst Evolution hat damit keine Probleme.
Leider ist Kontact aus diesem Grunde für mich unbrauchbar.
Amarok
Ich kann den Hype um diese Anwendung nicht verstehen. Viele Features fehlen, werden aber laut Mark wohl auch niemals implementiert, z.B. der uneingeschränkte Zugriff auf ID3-Tags/VorbisComments.