... hab am Schluss das meiste überflogen. Aber nehmen wir mal KIO Slaves, weil ja KDE sooo toll sein soll: Damit kann man NICHT STREAMEN, egal ob ich per ftp, sftp, smb, etc .. darauf zugreife. Das im Jahre 2007 bleibt KDE nur suboptimal. Da verwende ich doch lieber das alte Gnome-VFS, freue mich auf GVFS und nutze inzwischen immer mehr Fuse. Das funktioniert dann ohne X und Desktopunabhängig.
Damit kann man NICHT STREAMEN, egal ob ich per ftp, sftp, smb, etc .. darauf zugreife. Das im Jahre 2007 bleibt KDE nur suboptimal.
Natürlich geht das, das ist der Standardmodus. KIO aus KDE3 kann nur kein "Seek". Eine Designentscheidung, weil nicht alle Protokolle "Seek" unterstützen. Ich glaube in KDE4 wird das über Capabilities gehandhabt.
Nein. Erst wird die komplette Datei in ein temp. Verzeichnis kopiert, dann abgespielt. Ausprobiert mit smb, ftp, sftp ... Version: suse, kubuntu, slackware mit gepatchten KDE (susi, kubuntu) oder ungepatched (slackware), kde v3.5.x
Wieso sollte es von der Anwendung abhängen? Ich greife per Konqueror auf das entfernte Verzeichnis zu, z.b. (s)ftp://user@rechner und kann im Konqueror Verzeichnisse und Dateien browsen. Wie eben unter sshfs+fuse, curlftp+fuse oder gnome-vfs. Dann öffne ich eine Anwendung (video -> kaffeine, musik -> amarok), die zu der Datei passt. Was passiert? Konqueror(!) öffnet die Datei, kopiert erst die _komplette_ Datei in ein temp. Verzeichnis und danach(!) wird alles abgespielt.
Unter Gnome oder mit Fuse bin ich es gewohnt, die Datei zu öffnen und sie spielt sich _sofort_ ab. Ich kann einen beliebigen(!) Player verwenden (z.b. mplayer, audacious) und im Player in der Datei hin- und herspringen.
Achja, für die, die dieses negative Verhalten von KDE partout nicht wahrhaben wollen: http://www.ricardis.tudelft.nl/~vincent/fusesmb/
Einfach mal unter den Features lesen... Gnome-VFS war unstable, ist aber inzwischen stable. KDE kann noch immer nicht streamen (KDE 3.5.5) und wird es in KDE3 _NIE_ können. Punkt. KDE4 gibt es noch nicht. Da lass ich mich jetzt nicht monatelang hinhalten. Ich nutze seit über einem Jahr schon Netzlaufwerke, die ich streamen kann. KDE kann es seit Jahren nicht.
Soviel zu der ständigen Diskussion in deutschen Foren, wie gut doch KDE sein soll. Ist es nicht. Jeder Desktop hat seine Vor- und Nachteile. Punkt.
Dann öffne ich eine Anwendung (video -> kaffeine, musik -> amarok), die zu der Datei passt. Was passiert? Konqueror(!) öffnet die Datei, kopiert erst die _komplette_ Datei in ein temp. Verzeichnis und danach(!) wird alles abgespielt.
Dann wird die entsprechende Anwendung kein %u oder %U in ihrer .desktop Datei haben. In diesem Fall wird angenommen, dass die Anwendung nur lokale Dateien verarbeiten kann und der Transfer wird von Konqueror gemacht.
Bei einer Applikation, die selbst KIO verwendet, wird die URL direkt weitergegeben und der Applikation überlassen, was sie damit tut.
Die kann dann immer noch die Datei mit KIO::NetAccess in eine temporäre Datei runterladen oder eben einen KIO Job direkt benutzen und die Daten verarbeiten wenn sie eintreffen.
"Soviel zu der ständigen Diskussion in deutschen Foren, wie gut doch KDE sein soll. Ist es nicht. "
Oh doch, ist es. Allerdings hast du dir so ziemlich den einzigen extremen bösen grausamen und ätzenden Designfehler von KDE 3 als ultimatives Beispiel rausgesucht.
Ich fand dieses Verhalten bei KDE auch immer mehr als störend, aber am Ende wirst du nicht viele Beispiele wie dieses finden. Fairerhalber muss man sagen das bei GNOME das Problem dadurch auch existiert das nicht alle Anwendungen Gnome-VFS nutzen und oft garnichts nuit übergebenen URIs anfangen können. Bei KDE wirst du mindestens immer den Weg über den Download gehen können.
"Jeder Desktop hat seine Vor- und Nachteile. Punkt."
Eine Binsenweisheit. Nur am Ende ist KDE eben doch technisch weiter, selbst dieser schwachsinnige Müll ( ) hat seinen Grund. Auch wenn ich nicht so entschieden hätte. Bei GNOME ist es meistens eher ungewollt wenn etwas anders reagiert als erwartet, bei KDE gibts wenigstens Gründe, auch wenn sie *piep* *piep* *piep* sind.
> Bei KDE wirst du mindestens immer den Weg über den Download gehen können.
Downloaden kann man immer, auch per Hand und selbst das ist mir lieber als ne Datei im Temp Ordner, die ich dort vielleicht gar nicht haben will oder falls man dieses Verhalten nicht kennt, von der man nichts weiß.
Nein. Erst wird die komplette Datei in ein temp. Verzeichnis kopiert, dann abgespielt
Dann verwendet der Player vermutlich die simplere Variante mit KIO::NetAccess. Bei einer direkten Benutzung eines KIO Jobs bekommt man die Daten bei Eintreffen über ein Signal, also sehr wohl streaming.
Andernfalls müsste Konqueror ständig temporäre Dateien anlegen, wenn er eine Webseite mit mehreren Elementen (Bilder, etc) lädt
Andernfalls müsste Konqueror ständig temporäre Dateien anlegen, wenn er eine Webseite mit mehreren Elementen (Bilder, etc) lädt Also bei mir hat er das immer getan. Anderenfalls hätte er die Bilder bei jedem Aufruf der Seite neu laden müssen.
Der Cache ist liegt erstens in einem andere Verzeichnis und Dateien dort werden parallel zum Bildaufbau abgespeichert.
Es ist eine Sache über Applikationen zu schimpfen, die kein KIO verwenden, oder die KIO über KIO::NetAccess verwenden.
Es ist eine andere Sache, trotz nachprüfbarer Information unsinnige Behauptungen weiter zu führen. Erhöht nicht gerade den Wert als Diskussionsteilnehmer.
Ein KIO::TransferJob gibt die von seinem IO-Slave empfangen Daten über ein Signal an die Applikation weiter, genau in den Datenpaketen, die der Slave von seiner Quelle bekommt. Die Applikation hat dann logischerweise mehrere Möglichkeiten, mit diesen Daten zu arbeiten: direkte Verarbeitung, Sammeln in einem Puffer, Schreiben in eine Datei und Weitersenden.
Wie man mit Konqueror und einer Webseite mit einem großen Bild trivial nachprüfbaren kann, ist der Grundtransfermodus von KIO Datenstreaming.
Damit kann man NICHT STREAMEN, egal ob ich per ftp, sftp, smb, etc .. darauf zugreife. Das im Jahre 2007 bleibt KDE nur suboptimal. Da verwende ich doch lieber das alte Gnome-VFS, freue mich auf GVFS und nutze inzwischen immer mehr Fuse. Das funktioniert dann ohne X und Desktopunabhängig.
Natürlich geht das, das ist der Standardmodus.
KIO aus KDE3 kann nur kein "Seek". Eine Designentscheidung, weil nicht alle Protokolle "Seek" unterstützen. Ich glaube in KDE4 wird das über Capabilities gehandhabt.
Nein. Erst wird die komplette Datei in ein temp. Verzeichnis kopiert, dann abgespielt. Ausprobiert mit smb, ftp, sftp ... Version: suse, kubuntu, slackware mit gepatchten KDE (susi, kubuntu) oder ungepatched (slackware), kde v3.5.x
Mit welcher KDE/KIO-Anwendung hast Du es denn ausprobiert?
Wieso sollte es von der Anwendung abhängen? Ich greife per Konqueror auf das entfernte Verzeichnis zu, z.b. (s)ftp://user@rechner und kann im Konqueror Verzeichnisse und Dateien browsen. Wie eben unter sshfs+fuse, curlftp+fuse oder gnome-vfs.
Dann öffne ich eine Anwendung (video -> kaffeine, musik -> amarok), die zu der Datei passt. Was passiert? Konqueror(!) öffnet die Datei, kopiert erst die _komplette_ Datei in ein temp. Verzeichnis und danach(!) wird alles abgespielt.
Unter Gnome oder mit Fuse bin ich es gewohnt, die Datei zu öffnen und sie spielt sich _sofort_ ab. Ich kann einen beliebigen(!) Player verwenden (z.b. mplayer, audacious) und im Player in der Datei hin- und herspringen.
Achja, für die, die dieses negative Verhalten von KDE partout nicht wahrhaben wollen:
http://www.ricardis.tudelft.nl/~vincent/fusesmb/
Einfach mal unter den Features lesen...
Gnome-VFS war unstable, ist aber inzwischen stable. KDE kann noch immer nicht streamen (KDE 3.5.5) und wird es in KDE3 _NIE_ können. Punkt. KDE4 gibt es noch nicht. Da lass ich mich jetzt nicht monatelang hinhalten. Ich nutze seit über einem Jahr schon Netzlaufwerke, die ich streamen kann. KDE kann es seit Jahren nicht.
Soviel zu der ständigen Diskussion in deutschen Foren, wie gut doch KDE sein soll. Ist es nicht. Jeder Desktop hat seine Vor- und Nachteile. Punkt.
Bei fuese glaub ich dir das mit "jedem beliebigen Player", bei gnome-vfs nicht, gnome-vfs support muss in der Anwendung implementiert sein.
Dann wird die entsprechende Anwendung kein %u oder %U in ihrer .desktop Datei haben. In diesem Fall wird angenommen, dass die Anwendung nur lokale Dateien verarbeiten kann und der Transfer wird von Konqueror gemacht.
Bei einer Applikation, die selbst KIO verwendet, wird die URL direkt weitergegeben und der Applikation überlassen, was sie damit tut.
Die kann dann immer noch die Datei mit KIO::NetAccess in eine temporäre Datei runterladen oder eben einen KIO Job direkt benutzen und die Daten verarbeiten wenn sie eintreffen.
Oh doch, ist es. Allerdings hast du dir so ziemlich den einzigen extremen bösen grausamen und ätzenden Designfehler von KDE 3 als ultimatives Beispiel rausgesucht.
Ich fand dieses Verhalten bei KDE auch immer mehr als störend, aber am Ende wirst du nicht viele Beispiele wie dieses finden. Fairerhalber muss man sagen das bei GNOME das Problem dadurch auch existiert das nicht alle Anwendungen Gnome-VFS nutzen und oft garnichts nuit übergebenen URIs anfangen können. Bei KDE wirst du mindestens immer den Weg über den Download gehen können.
"Jeder Desktop hat seine Vor- und Nachteile. Punkt."
Eine Binsenweisheit.
) hat seinen Grund. Auch wenn ich nicht so entschieden hätte. Bei GNOME ist es meistens eher ungewollt wenn etwas anders reagiert als erwartet, bei KDE gibts wenigstens Gründe, auch wenn sie *piep* *piep* *piep* sind.
Nur am Ende ist KDE eben doch technisch weiter, selbst dieser schwachsinnige Müll (
Downloaden kann man immer, auch per Hand und selbst das ist mir lieber als ne Datei im Temp Ordner, die ich dort vielleicht gar nicht haben will oder falls man dieses Verhalten nicht kennt, von der man nichts weiß.
Dann verwendet der Player vermutlich die simplere Variante mit KIO::NetAccess. Bei einer direkten Benutzung eines KIO Jobs bekommt man die Daten bei Eintreffen über ein Signal, also sehr wohl streaming.
Andernfalls müsste Konqueror ständig temporäre Dateien anlegen, wenn er eine Webseite mit mehreren Elementen (Bilder, etc) lädt
Also bei mir hat er das immer getan. Anderenfalls hätte er die Bilder bei jedem Aufruf der Seite neu laden müssen.
Der Cache ist liegt erstens in einem andere Verzeichnis und Dateien dort werden parallel zum Bildaufbau abgespeichert.
Es ist eine Sache über Applikationen zu schimpfen, die kein KIO verwenden, oder die KIO über KIO::NetAccess verwenden.
Es ist eine andere Sache, trotz nachprüfbarer Information unsinnige Behauptungen weiter zu führen. Erhöht nicht gerade den Wert als Diskussionsteilnehmer.
Ein KIO::TransferJob gibt die von seinem IO-Slave empfangen Daten über ein Signal an die Applikation weiter, genau in den Datenpaketen, die der Slave von seiner Quelle bekommt. Die Applikation hat dann logischerweise mehrere Möglichkeiten, mit diesen Daten zu arbeiten: direkte Verarbeitung, Sammeln in einem Puffer, Schreiben in eine Datei und Weitersenden.
Wie man mit Konqueror und einer Webseite mit einem großen Bild trivial nachprüfbaren kann, ist der Grundtransfermodus von KIO Datenstreaming.