Von Kaninchenbock am Do, 2. August 2007 um 19:06 #
Das Weiterleiten eines C++ Funktionsaufrufs ist wirklich ein ziemlich vernachlässigbarer Einfluss.
D.h. ob ein Programm den Pfad zu einer Audiodatei direkt an die GStreamer API übergibt, oder zuerst an eine Methode in Phonon, die es dann an GStreamer weiterleitet, dürfte die Dauer bis zum Start der Audioausgabe so unwesentlich beeinflussen, dass es nicht merkbar ist. Das Laden der Audiodaten und deren Dekodierung dürfte bei weitem länger dauern.
Gut dran vorbei geredet, bei allen Vorteilen die Phonon bringen könnte oder nicht, so leicht sollte man sich das leben nicht machen! Die Taktik ist gut, so müssen sie keine ManPower in die Backends stecken und wählen sich dann einfach das beste... imho wäre eine Zusammenarbeit an einem Backend besser gewesen.
Konzeptionell richtig, praktisch wie D-Bus -> DCOP. Eine neue Implementierung, die aus den Schwachstellen der alten Implementierung gelernt hat. Nicht umsonst besteht seitens der Evolution Entwickler Interesse an Akondai als eine gemeinsamen Datenhaltungsinfrastruktur.
Ich habe damit nur sagen wollen, dass es sowas schon seit Jahren gibt. Und man es nicht als Gral der Weisheit def. soll, nur weil man es nicht besser weiß, wie dein Vorredner. Ich hoffe es kommt da zu Codeaustausch... die Vergangenheit lehrte uns leider anderes. Und wenn man sich die Entwicklung um EDS anschaut (MC, DBUS-Port, Tracker ...) glaube ich eher weniger daran.
Oxygen ist mehr als nur Icons. Und die Oxygen Icons benutzen die selbe Namenskonvention wie die Tango Icons. Wir Entwickler von freier Desktopsoftware nennen das Shared Specification.
Du bist doch sehr informiert, dann weißt du was es für Probleme gab, wegen den Specs und das die Einigung auf die Namenskonvention der kleinste Nenner war, und viele unzufrieden waren mit der Zusammenarbeit. Aber auch hier wollte ich nur sagen, das es dies schon gibt!
NetworkManager (unter Linux) das Default-Netzwerkstatusbackend von Solid.
Habe ich was anderes gesagt?
Wir können die Liste ja gerne noch weiter führen... Dolphin, Okular nichts was es nicht schon geben würde. Deswegen versteh ich den ganzen Hype einfach nicht und die Aussagen deines Vorredners schon gar nicht!
Sorry wenn du das falsch verstanden hast, ich wollte nur sagen, das es vergleichbare (sei dahin gestellt ob besser/schlechte) Technologien es bereits gibt und z.T. schon seit Jahren genutzt werden.
Von Kevin Krammer am Fr, 3. August 2007 um 17:26 #
Gut dran vorbei geredet...
Ich bin auf den Einwand eingegangen, Phonon würde Performance kosten. Da wie gesagt weiterhin das Backend die Medienhandhabung macht, ist das nicht der Fall.
Selbst bei der Wahl einer Mediaengine hätte man ein Qt/KDE API Binding gebraucht.
Und ein Binding, das soweit unabhängig sein muss, dass API/ABI Änderungen der zugrunde liegenden Engine keine Auswirkung auf das Binding haben wäre vom Design her auch nicht viel anders ausgefallen. Die Möglichkeit andere Backends benutzen zu können ist quasi ein Bonus.
Ich hoffe es kommt da zu Codeaustausch...
Hoffe ich auch. Erstmal muss sich Akonadi im Einsatz bei KDE beweisen. Wenn das gut klappt ist eine der Möglichkeiten, den Akonadi Server als Projekt bei freedesktop.org zu führen, eventuell auch ein paar der Agents.
Sorry wenn du das falsch verstanden hast, ich wollte nur sagen, das es vergleichbare (sei dahin gestellt ob besser/schlechte) Technologien es bereits gibt und z.T. schon seit Jahren genutzt werden.
Ja, sorry. Ohne die, hmm, gewagte Aussage zu Phonon hätte ich es auch nicht kommentiert
Das Weiterleiten eines C++ Funktionsaufrufs ist wirklich ein ziemlich vernachlässigbarer Einfluss.
D.h. ob ein Programm den Pfad zu einer Audiodatei direkt an die GStreamer API übergibt, oder zuerst an eine Methode in Phonon, die es dann an GStreamer weiterleitet, dürfte die Dauer bis zum Start der Audioausgabe so unwesentlich beeinflussen, dass es nicht merkbar ist.
Das Laden der Audiodaten und deren Dekodierung dürfte bei weitem länger dauern.
Gut dran vorbei geredet, bei allen Vorteilen die Phonon bringen könnte oder nicht, so leicht sollte man sich das leben nicht machen! Die Taktik ist gut, so müssen sie keine ManPower in die Backends stecken und wählen sich dann einfach das beste... imho wäre eine Zusammenarbeit an einem Backend besser gewesen.
Konzeptionell richtig, praktisch wie D-Bus -> DCOP. Eine neue Implementierung, die aus den Schwachstellen der alten Implementierung gelernt hat.
Nicht umsonst besteht seitens der Evolution Entwickler Interesse an Akondai als eine gemeinsamen Datenhaltungsinfrastruktur.
Ich habe damit nur sagen wollen, dass es sowas schon seit Jahren gibt. Und man es nicht als Gral der Weisheit def. soll, nur weil man es nicht besser weiß, wie dein Vorredner.
Ich hoffe es kommt da zu Codeaustausch... die Vergangenheit lehrte uns leider anderes. Und wenn man sich die Entwicklung um EDS anschaut (MC, DBUS-Port, Tracker ...) glaube ich eher weniger daran.
Oxygen ist mehr als nur Icons. Und die Oxygen Icons benutzen die selbe Namenskonvention wie die Tango Icons.
Wir Entwickler von freier Desktopsoftware nennen das Shared Specification.
Du bist doch sehr informiert, dann weißt du was es für Probleme gab, wegen den Specs und das die Einigung auf die Namenskonvention der kleinste Nenner war, und viele unzufrieden waren mit der Zusammenarbeit.
Aber auch hier wollte ich nur sagen, das es dies schon gibt!
NetworkManager (unter Linux) das Default-Netzwerkstatusbackend von Solid.
Habe ich was anderes gesagt?
Wir können die Liste ja gerne noch weiter führen... Dolphin, Okular nichts was es nicht schon geben würde. Deswegen versteh ich den ganzen Hype einfach nicht und die Aussagen deines Vorredners schon gar nicht!
Sorry wenn du das falsch verstanden hast, ich wollte nur sagen, das es vergleichbare (sei dahin gestellt ob besser/schlechte) Technologien es bereits gibt und z.T. schon seit Jahren genutzt werden.
Ich bin auf den Einwand eingegangen, Phonon würde Performance kosten. Da wie gesagt weiterhin das Backend die Medienhandhabung macht, ist das nicht der Fall.
Selbst bei der Wahl einer Mediaengine hätte man ein Qt/KDE API Binding gebraucht.
Und ein Binding, das soweit unabhängig sein muss, dass API/ABI Änderungen der zugrunde liegenden Engine keine Auswirkung auf das Binding haben wäre vom Design her auch nicht viel anders ausgefallen. Die Möglichkeit andere Backends benutzen zu können ist quasi ein Bonus.
Ich hoffe es kommt da zu Codeaustausch...
Hoffe ich auch. Erstmal muss sich Akonadi im Einsatz bei KDE beweisen. Wenn das gut klappt ist eine der Möglichkeiten, den Akonadi Server als Projekt bei freedesktop.org zu führen, eventuell auch ein paar der Agents.
Sorry wenn du das falsch verstanden hast, ich wollte nur sagen, das es vergleichbare (sei dahin gestellt ob besser/schlechte) Technologien es bereits gibt und z.T. schon seit Jahren genutzt werden.
Ja, sorry. Ohne die, hmm, gewagte Aussage zu Phonon hätte ich es auch nicht kommentiert