Das Problem hatte ich auch. Ich habe dann die kde4-factory Quelle mit eingebunden und von da noch nötige Packete nachinstalliert bzw.. alle Packete geupdatet wenn neue Version verfügbar.
Mein Plasma ist allerdings noch ziemlich schrottig. Das Panel hängt irgendwo in der Luft und allgemein scheint er die Auflösung nicht richtig zu erkennen. Naja, wenn ich Zeit habe schreibe ich mal einen Bug-Report...
KDE ansich entwickelt sich wirklich prima, doch die Plasma Desktop Shell scheint noch irgendwie das "Sorgenkind" zu sein. Ich hoffe, dass sich das bis zur Veröffentlichung noch bessert.
Unter http://vizzzion.org/?blogentry=742 gibt es einen Blogeintrag mit sehr vielen Screenshots. Es hatten aber wohl mehrere die Idee sich das anzugucken und der Webserver hat gerade kein Bock mehr und sich den Lockführern in ihrem Streik angeschlossen. Vielleicht einfach mal ein bisschen warten.
Ich bin ja auf KDE 4 gespannt. Zwar bin ich vor nem halben Jahr wegen Ubuntu zu Gnome gewechselt und bin da auch sehr zufrieden aber die 4er werd ich mir definitiv mal installieren, wenn sie fertig ist. Ich glaube zwar das die Wahl des Desktops bei weitem zu viel Bedeutung beigemessen wird, aber neugierig bin ich ja trotzdem. Na ja wen jemand wie ich in WinXp zuallererst alle Desktopeffekte abschaltet und dann noch das Win2000 theme wählt, das sagt ja schon alles
Wie viele RCs wirds denn noch geben? Respektive wie viele Berichte bei Pro-Linux? Grüße
und dann noch das Win2000 theme wählt, das sagt ja schon alles
das gibt es doch diesen windowsähnlichen Theme, irgendein Aufbau auf den fvwm2 -> Redmond98 http://www.fvwm.org/screenshots/desktops/Windows95-desk-1280x1024/screenshot.png
Doch, doch! Ich vermute nur mal, Du hast Dich etwas ungeschickt ausgedrückt. Ich verstehe Dich so, daß Du Linux und Windows parallel benutzt. Und für den Fall der Nutzung von XP stellst Du das klassische Design ein. Ohne jetzt eine Diskussion über einen XP-Desktop anzufachen, teile ich Deine Meinung. Da ich beruflich XP nutzen muß, habe ich ebenfalls das klassische Schema genommen, da mich das Teletubby Design nur aufregt. Es ist einfach ineffizient. Und ich hoffe, daß KDE nicht auch in ein solches Fahrwasser gerät.
Kann der Konqueror und die entsprechenden KDE Videoplayer endlich Videodateien per Netzwerk via SMB streamen ohne diese erst vorher lokal auf Festplatte kopieren zu müssen?
Von Kevin Krammer am Mi, 21. November 2007 um 11:07 #
Natürlich.
Durch das Mounten des SMB Shares sieht die Datei zwar wie eine lokale Datei aus, wird aber beim Lesen Stück für Stück übertragen, d.h. den Bereich der Datei, denn der Player gerade ausliest.
Wird schon vom Kernel erledigt, daher gilt das natürlich für alle Programme. Ziemlich praktisch solche Filesystem Plugins im Kernel.
Bei KDE: Ich gehe via Dolphin auf Netzwerk/-SMB Freigaben -> Dort kann ich dann ganz normal mit den Daten umgehen als wären Sie auf meiner lokalen Festplatte. Will ich aber dann z.B. eine MP3 Datei öffnen, bekommt das Programm eine smb url, mit der zumindest die gängigen Programme nichts anfangen können.
(Vielleicht gibt es auch eine ganz einfache Lösung dafür
Von Kevin Krammer am Mi, 21. November 2007 um 11:57 #
Ah.
Es kann sein, dass die Playerentwickler hier den einfacheren Weg genommen haben, die Daten zuerst zu cachen und dann als ganzen an die Engine (z.B. Xine) zu übergeben, anstatt sie in den Häppchen weiter zu geben, in denen sie eintreffen.
Hängt eventuell auch von der Engine ab, ob sie Daten blockweise über die API verarbeiten kann.
Die KIO slaves haben bisher kein "seeking" unterstützt, das heisst, man nimmt die Datei ganz oder gar nicht. Das ist soweit ich weiss in KDE 4 möglich, allerdings habe ich es noch nicht probiert. Eventuell unterstützen es auch nicht alle I/O Slaves.
Es hat allerdings nichts mit der URL zu tun, dass nicht alle Programme z.B. sftp://daten/film.avi verstehen, dafür kann KDE nun wirklich nix.
Zum Seeking: Dazu wurde mir bereits vor ca. 4 Jahren von KDE Entwicklern gesagt das es sehr wohl in kio enthalten ist, nur nicht von jedem Programm genutzt wird.
Ob diese Information noch aktuell ist kann ich nicht mit Sicherheit sagen.
Von Kevin Krammer am Mi, 21. November 2007 um 19:39 #
Bezüglich Seeking hat Sebas recht, das gibt es in KDE3's KIO nicht.
Allerdings ist es sehrwohl möglich "zu streamen", denn das ist die übliche Arbeitsweise der IO Slaves, d.h. Daten paketweise anliefern.
Es ist also mehr oder weniger eine Frage des Players, bzw. seiner Kommunikation mit seinem Backend oder seiner Multimediaschicht, ob er diese Daten dann häppchenweise oder als Gesamtes weiterreicht. Vermutlich ist es in den üblichen Multimedia APIs leichter, es als Datei zu übergeben.
Von Kevin Krammer am Mi, 21. November 2007 um 11:49 #
Es sind derzeit mindestens drei aktive, wahrscheinlich mehr (müßte man im Archive der kde-windows Mailingliste nachsehen [1]).
Christian Ehrlicher Ralf Habacker Jaroslav Staniek
Nachdem bisher verschiedene Unix Plattformen bedient wurden, haben sich hie-und-da auch unixspezifische Sachen eingeschlichen, bzw. wurde Standard APIs verwendet, die wiedermal nur unter Windows nicht unterstützt werden. Selbst ansich portable entworfene Software wie D-Bus ist davon nicht ausgeschlossen und erfordert daher manchmal auch Änderungen in anderen Projekten.
Die kdelibs (und evtl. einige Basiskomponenten) sind schon lauffähig unter Windows. Auch amarok ist da wohl schon sehr weit.
Man sollte das allerdings nicht falsch verstehen. Es geht dabei nicht darum, den kompletten Windows Desktop zu ersetzen, sondern vielmehr die Anwendungen, wie amarok, kate, konqueror, kopete und wie sie alle heißen, auf Windows lauffähig zu machen. Deshalb sollte man das eigentlich nicht überbewerten.
Von Scheich Xodox am Mi, 21. November 2007 um 11:53 #
Danke für eure Antworten. Schade, ich habe die ganze Zeit gedacht, ich könnte KDE als alternative GUI nutzen. Schaut euch mal die Oberfläche von Windows an. Das Zeug ist doch unbenutzbar. Windows kennt zB noch nicht mal mit Vista mehrere Desktops. Alles muss man immer mit extra Programmen nachrüsten. Da wäre KDE eine super Alternative.
Soweit ich weiß läuft KDE schon seit längere Zeit auf Windows. Grundsätzlich jedenfalls. Soll wohl nur sehr langsam sein und persönlich habe ich es nie zu gesicht bekommen.
Naja, ganz ausgeschlossen ist es nicht. Es ist so wie immer bei Open Source Software, wenn irgendein Freak, der dazu fähig ist, sich entscheidet, die komplette Oberfläche von KDE für Windows verfügbar zu machen (also als Alternative zur Windowsoberfläche), dann werden die KDE Entwickler da kaum entgegenwirken. Ich zitiere mal den Herrn Sebastian Kügler: "Pläne. den Desktop (Plasma, KWin) auch unter Windows und Mac OS zur Verfügung zu stellen, gibt es derzeit nicht. (Das heißt allerdings nicht, dass es nicht »Verrückte« gibt, die diese Komponenten auf diese Plattformen portieren. Wie es in der Free-Software-Welt halt ist (lacht)."
Oh, das funktioniert schon? Welche Taste? Ich muss mir wohl mal eine neuere Graka leisten, die von den aktuellen nvidia-Treibern supported wird. Schade, dass die freien ATI-Treiber noch nicht so weit sind, wie sie hoffentlich bald sein werden.
Von catconfuser am Mi, 21. November 2007 um 15:40 #
HabŽs nur auf einem Screenshot bei http://vizzzion.org/?blogentry=742 gesehen. Laut dortigem Text Maustaste in die linke obere rechte führen. Welche Beschränkungen es hinsichtich der Grafikkarten gibt weiß ich allerdings nicht.
Von vicbrother am Mi, 21. November 2007 um 19:59 #
Die Screenshots sehen nicht schlecht aus. Wie schafft man diese Anzeige der Zeit rechtsbündig von der eigentlichen Eingabe in der Konsole? Was für eine Shellerweiterung ist denn das?
In KDE3 gab es einen Fehler in den Oberflächentexten, von dem ich nicht weiß ob er schon behoben ist.
Wollte man einen bestimmten Dateityp mit einem bestimmten Player defaultmäßig öffnen (durch Klick oder Doppelklick auf die entsprechende Datei), musste man hierfür in das Kontextmenü der Datei gehen (rechte Maustaste), dort gibt es dann die Möglichkeit "Öffnen mit" wo man einige Programme auswählen kann oder man wählt "Sonstiges". Dort kann man dann aus einer Liste der zur Verfügung stehenden Programme auswählen. Hat man ein bestimmtes Programm gewählt, gibt es so eine kleine Checkbox, bei der steht "Programm dem Dateityp fest zuordnen" oder so ähnlich.
Dieser Text ist von der Formulierung her falsch. Es müsste heißen "Dateityp dem Programm fest zuordnen".
Ist zwar nur ein kleiner Fehler, ist mir aber in der neuen Mandriva 2008 wieder aufgefallen, dass es den immer noch gibt.
Wenn das einer von euch für KDE4 immer noch bestätigen kann, dann mach ich ne Meldung auf.
Ich möchte jetzt nicht klugscheißen und wahrscheinlich wirds mir jetzt eh keiner glauben aber ich hab Deutsch und Informatik studiert und arbeite bei SAP im Bereich Doku und Usability. Habe mir genau über ähnliche Formulierungen schon öfter den Kopf zerbrochen aber:
Du kannst ein Programm mehreren Dateitypen zuordnen, umgekehrt geht das jedoch nicht. Wenn man sagt man ordnet ein Programm einem Dateityp fest zu, dann heißt dies du assoziierst mit einem Programm einen festen Dateityp und genau da liegt der Fehler. Das Programm kann ja in der Regel mehrere Dateitypen bearbeiten und für mehrere Dateitypen die Default-Anwendung sein.
Dieses Prinzip würde man in der theoretischen Informatik mit Injektivität und Surjektivität bezeichnen, falls das jemand von euch kennt.
Denkt mal genau drüber nach
Ungeachtet davon ist diese Formulierung kein Beinbruch aber korrekt ist sie definitiv nicht.
Von realsuamor am Di, 27. November 2007 um 14:19 #
Bsp: Das Programm Writer dem Dateityp Text fest zuordnen so ist es original verständlicher: Dem Dateityp Text das Programm Writer fest zuordnen
Der Originaltext ist also richtig und Du hast auch recht
Man kann aber auch einem Dateityp mehrere Programme zuordnen, z.B. Auswahl von Programmen mit Hilfe von Kontextmenüs. Weiß allerdings nicht, ob das von KDE4 unterstützt wird.
Von vicbrother am Mi, 21. November 2007 um 19:29 #
Wo kann ich denn eine gute verständliche Einführung in die neuen kdelibs bekommen? Der IDEAL-Modus reizt mich, etwas zu programmieren, aber der scheint nicht in PyQT/PyKDE enthalten zu sein?
Wie sieht es eigentlich mit einem Schachfrontend für die KDE4.0 aus? Bei GNOME ist eins dabei, bei der KDE sieht knights recht verweist aus...
(PS: Weiß auch zufällig jemand, in welchem Paket qtdemo unter Debian steckt?)
Von vicbrother am Mi, 21. November 2007 um 21:13 #
Nee, das kannte ich noch nicht. Da bin ich sehr gespannt - dann muss ich ggf. doch keinen FICS-Client mit IDEAL-Modus mehr schreiben Die Grafik sieht sehr gut aus (obwohl ich die Fritzfigurensätze bevorzuge, aber vielleicht nimmt sich ein Grafiker dieser Sache noch an).
Die KDE 4.0 habe ich gerade mit der Debian Live KDE 4.0 getestet. WOW. Das sieht wirklich sehr gut aus, was die Entwickler da geleistet haben. Man spürt gleich, das mit Plasma viel los sein wird. Hoffentlich gibt es dafür ein Schachplasma - zig Partien frei auf dem Desktop verteilen, irgendwo noch die aktuelle Turniertabelle und die Paarungen - mit Plasma sicherlich kein Problem.
Nur kcontrol finde ich umständlicher als vorher, weil die Orientierung verloren geht.
Die Distributoren werden sich jedenfalls auf KDE 4.0 freuen - damit kommt das MAC-Feeling auf den PC!
Von zettberlin am Mi, 21. November 2007 um 21:55 #
...als Option statt Dolphin.
Ich habŽ mal die LiveCD auf Suse-Basis getestet und fand zumindest das voreingestellte Verhalten des Desktops ausgesprochen ärgerlich:
1.) warum kann ich Kicker und das Menü nicht per Rechtsklick konfigurieren?
2.) Warum ist KDE4 auf der LiveCD der einzige Linux-Desktop (und ab MacOS Leopard überhaupt der einzige...) der keine richtige Integration von virtuellen Desktops hat?
3.)Warum kann ich nicht per Rechtsklick den Desktop (Bildschirmschoner, Hintergrund, etc) konfigurieren?
Das wären nur die Probleme, die mir nach einer Stunde schon endlos auf die Nerven gegangen sind.
Hinzu kommen 2 Fragen:
1.) Wie wollen es die KDE-devs bis zum 11 Dezember schaffen, die kapitalen Probleme von Konqueror zu lösen? 2.) Wenn diese und die oben genannten Probleme im SVN schon gelöst sind, warum konnte ich gestern eine Live-Demo herunterladen, die so aussah, als würde es noch 6 Monate dauern, bis KDE4 so schnell und sicher läuft wie KDE 3 in Mandrake 9?
Positives gibt es auch: das Ding sieht hübsch aus und Phonon scheint eine sehr ordentliche Lösung für Sound auf dem Desktop zu werden....
Von Kevin Krammer am Do, 22. November 2007 um 00:17 #
Phonon ist eine äußerst sauber entworfene C++ API für pluginbasierte Multimedia Aufgaben.
KDE, in seiner Eigenschaft als Applikationsframework, baut grundsätzlich auf den Errungenschaften von Bibliotheken und Spezialframeworks auf, es wäre ja auch nicht sehr zielführend, Arbeit in Duplikation von Funktionalität zu stecken, die Entwickler mit diesbezüglichen Kenntnissen schon anbieten.
Im Falle von Multimedia wäre es demnach nicht sehr zielführend, die Arbeit der GStreamer oder XINE Entwickler zu ignorieren, auch wenn das von manchen Leuten vielleicht als "...die Arbeit anderen überlassen..." gesehen wird. Glücklicherweise verstehen die meisten Menschen, dass es im Interesse der Entwickler von Multimediabibliotheken ist, wenn ihre Arbeit auch benutzt wird.
Ja man kann sich aller schön reden. Ich finde es sehr schade, dass KDE sich aus den Low-Level-Bereichen der Desktop Entwicklung zurück zieht. Da werden Ressourcen in Gimmics wie Plasma gesteckt ... schön bunt super ... die schweren Aufageben überlassen wir mal den anderen, ... echt schade. Es gab mal andere KDE Zeiten.
Plasma ist der Desktop (oder die Desktop-Shell, wie es neu genannt wird), und somit ein Zentraler Bestandteil von KDE. Dass man der Schnittstelle zwischen Benutzer und PC besondere Beachtung schenkt, erwarte ich von einer Desktopumgebung eigentlich schon.
Je mehr sich KDE von den Low-Level-Bereichen abnabelt, desto plattformunabhängiger wird es. Das sehe ich als Vorteil. Es stimmt, dass KDE mit DCOP und aRTs Vorreiter in Low-Level-Techniken war, aber andere mussten das Rad (aus welchen Gründen auch immer) neu erfinden. Jetzt da eine Modernisierung der beiden Techniken fällig ist, steht man vor der Wahl, entweder ebenfalls aus Sturheit und Eitelkeit die eigene Entwicklung weiter voranzutreiben, oder auf inzwischen bestehende Lösungen aufzusetzen und sich wieder auf seine Kernkompetenzen zu konzentrieren. Ich begrüsse die getroffene Entscheidung. Mit der Zwischenschicht Phonon gewinnt man nicht nur API-Stabilität über die verschiedenen Plattformen hinweg, sondern hat auch das Gezanke um das "Multimedia-Framework der Woche" auf Linux elegant umgangen.
Von Kevin Krammer am Do, 22. November 2007 um 13:58 #
...steht man vor der Wahl, entweder ebenfalls aus Sturheit und Eitelkeit die eigene Entwicklung weiter voranzutreiben, oder auf inzwischen bestehende Lösungen aufzusetzen...
Man kann einfach nicht allen Leuten recht machen.
Wenn KDE Basisinfrastruktur macht gibt es welche, die sich darüber aufregen, wenn man später beim Aufkommen von Alternativen die eigene Lösung beibehält, und wenn man dann bei der nächsten Möglichkeit auf gemeinsam benutzbare Infrastruktur umstellt gibt es welche, die sich darüber aufregen, man würde anderen die Arbeit überlassen.
Obwohl KDE eine sehr große Entwicklergemeinschaft hat, kann sie sich nicht um den gesamten Desktopsoftwarestack oberhalb des Kernels kümmern. Ich denke es ist besser, man überlässt zum Beispiel den X-Entwicklern die Arbeit am X-Server und dessen Treibern, etc. KDE Entwickler, die für solche Bereiche auch Interesse haben, arbeiten dort ja ohnehin von sich aus mit, z.B. Zack Rusin bei X-Server Treibern, Thiago Maciera und unsere Windowsleute bei D-Bus, usw.
Das ist ja mal reines beleidigtes Rumgejammer. KDE arbeitet nach wie vor in Bereichen jenseits der Farbauswahl. Da fallen mir Grundlegende Technologien wie KIO, die Beschäftigung mit dem Thema semantischer Desktop (wenn auch noch ganz in den Kinderschuhen), D-BUS, Java Script und HTML Bibliotheken ein.
Nur weil man heutzutage nicht mehr alles selber machen muss und sich nicht im Keller mit Keksen einschließt um die Super 4k Bibliothek ala Assembler zu schreiben, heißt das nicht das man sich nicht mehr mit Grundlagen beschäftigt.
Heutzutage sind Themen wie Architektur, Philosophie, Modellierung und API Design endlich in den Vordergrund gerückt. Beispiele sind D-Bus und freedesktop.org. Das ist auch Grundlagenarbeit, die alte passiert aber auch noch, nur etwas versteckter dahinter, wo sie auch hin gehört wenn man sich mit so etwas allgemeinem wie einen Desktop auseinander setzt.
1.) Kicker gibt's nicht mehr. Gibt halt keine Optionen per Rechtsklick mehr/derzeit. 2.) Natürlich werden virtuelle Desktops unterstützt, vielleicht ist es nicht Default aber es gibt ein Pager/Workspace plasmoid. 3.) Weil es beim RC1 noch nicht implementiert war, im SVN kann man per Rechtsklick den Hintergrund ändern.
Von zettberlin am Do, 22. November 2007 um 15:57 #
>1.) Kicker gibt's nicht mehr. Gibt halt keine Optionen per Rechtsklick mehr/derzeit.
Ganz toll - Desktop ohne Panel. Wozu soll das gut sein?
>2.) Natürlich werden virtuelle Desktops unterstützt, vielleicht ist es nicht Default aber es gibt ein Pager/Workspace plasmoid.
Dieser Pager wird aber von Fenstern auf dem Desktop verdeckt, was ihn letztlich unbrauchbar macht. Von einer Integration der virtuellen Desktops kann man damit nicht reden...
>3.) Weil es beim RC1 noch nicht implementiert war, im SVN kann man per Rechtsklick den Hintergrund ändern.
Da bin ich ja beruhigt.... hatte schon gedacht, dieses Feature sollte gestrichen werden, weil es jemanden verwirren könnte....
Von Kevin Krammer am Do, 22. November 2007 um 18:45 #
Ganz toll - Desktop ohne Panel. Wozu soll das gut sein?
Wer hat gesagt, es gäbe kein Panel mehr? Das Programm Kicker gibt es nicht mehr, Panels sind jetzt eine Form von Plasmacontainer.
Sieht man ja praktisch auf jedem Screenshot
Dieser Pager wird aber von Fenstern auf dem Desktop verdeckt...
Wenn man ihn auf dem Desktop statt auf einem Panel platziert, ja. Aber warum sollte man das tun, wenn man ihn auch bei maximierten Fenstern benutzen möchte?
> 2.) Wenn diese und die oben genannten Probleme im SVN schon gelöst sind, warum konnte ich gestern > eine Live-Demo herunterladen, die so aussah, als würde es noch 6 Monate dauern, bis KDE4 so schnell > und sicher läuft wie KDE 3 in Mandrake 9?
Blöde Frage. KDE3 hat Jahrelange Entwicklung und mehrere Versionen hinter sich. Warum sollte ein großer Wurf wie KDE4 das dann gleich bei der ersten Version schaffen?
"Kicker" ist (wie so ziemlich alles) ein Plasmoid. Bisher war es nicht konfigurierbar, da man sich um das unter der Oberfläche werkelt gekümmert hat. Im aktuellen SVN kann man schon ansatzweise sehen, dass "Kicker" jetzt zu einem konfigurierbaren Plasmoid umgewandelt wird. Virtuelle Desktops gibt es mit Sicherheit, einfach warten, wie gesagt, viele der Dinge, die man "sieht" müssen sich noch entwickelt. Das ist weniger schlimm als man jetzt denkt, da es wirklich nur das Optische ist.
Von zettberlin am Do, 22. November 2007 um 16:03 #
>einfach warten, wie gesagt, viele der Dinge, die man "sieht" müssen sich noch entwickelt.
Warten lohnt sich oft aber wie soll das alles bis zum 11. Dezember fertig werden? Und/oder: wieso soll eine Software, die so wichtig ist wie KDE, als Major-Release freigegeben werden, wenn sie noch so unterentwickelt ist, dass sie ein gutes Drittel der Leistungen ihres Vorgängers nicht bringen kann....
Du musst das etwas anders sehen. Mit Plasma wurde eine sehr mächtige Schnittstelle geschaffen. Die ist im Prinzip fertig. Alles was noch fehlt sind die entsprechenden Plasmoide, die sind aber nicht so schwer zu erstellen. Prinzipiell zwingt dich auch keiner, die vorgegebene Taskleiste zu verwenden. Es könnte auch jemand etwas Alternatives veröffentlichen, das dir mehr zusagt und ähnliche (oder bessere?) Funktionen bietet. Es wurde ja zuletzt erst ein Beispiel gegeben, mit dem Startmenü. Ich zum Beispiel mag das neue Startmenü gar nicht leidern, ich hätte am liebsten wieder das alte K-Menü. Jetzt weiß ich zwar nicht, ob das schon im Gange ist, aber prinzipiell sollte es kein Problem darstellen, ein Plasmoid zu erstellen, das die Funktionalität des K-Menüs hat (evtl. mit ein paar Verbesserungen).
Was ich damit sagen will ist, dass schlicht nicht so viel fehlt wie es gerade aussieht.
Du musst das etwas anders sehen. Mit Plasma wurde eine sehr mächtige Schnittstelle geschaffen. Die ist im Prinzip fertig.
..."im Prinzip" klingt verdächtig nach Radio Eriwan. Das Problem ist allerdings, dass das, was die KDE-Entwickler hier als "RC1" präsentieren im großen und ganzen Alpha-Qualität hat: Technisch interessant aber Hölle von instabil und vollkommen unvollständig.
"Release Candidate" heißt, dass die Software fertig ist und dass nur noch ggf. vorhandene Fehler beseitigt werden, bzw (deshalb "Candidate"), dass sie so veröffentlicht wird, falls keine gravierenden Bugs mehr gefunden werden.
Das, was hier als RC1 präsentiert wird (getestet unter OpenSUSE 10.3), ist in Sachen Stabilität und Ausgereiftheit wirklich unter aller Kanone, kaum ein Programm verrichtet störungsfrei seinen Dienst. Ich verstehe nicht, welcher Teufel die KDE-Leute geritten hat, den Release-Plan so ohne Rücksicht auf Verluste durchzuziehen.
Da muss ich dir zustimmen, das Verständnis der KDE Entwickler, was eine "Beta" und was ein "RC" ist ist sehr dürftig. Aber ich denke mal, das hängt damit zusammen, dass die KDE Entwickler von Anfang an gesagt haben, dass für die Endbenutzer eigentlich erst KDE 4.1 gedacht ist und KDE 4.0 hauptsächlich für die Entwickler von Anwendungen ist, damit die ihre Anwendungen portieren können. Dennoch hätte man sich für ein besser passendes Namensschema entscheiden sollen.
Von vicbrother am Fr, 23. November 2007 um 00:42 #
Ich habe zwei Fragen zu Strigi:
1. Wie sucht man gezielt nach Inhalten in E-Mails? 2. Wieso frisst strigidaemon locker 30-80% der CPU laut top? Soll das so sein oder ist das ein Bug (Debian/Sid)?
Von Kevin Krammer am Fr, 23. November 2007 um 13:56 #
1. Wie sucht man gezielt nach Inhalten in E-Mails?
Vermutlich über Einschränkung der Suche auf einen speziellen MIME Type. Ich glaube EMails sind message/rfc822
2. Wieso frisst strigidaemon locker 30-80% der CPU laut top? Soll das so sein oder ist das ein Bug (Debian/Sid)?
Im laufenden Betrieb oder bei der Indizierung? Bei der Indizierung wird glaub ich so verfahren, dass mit niederer Priorität (sodass andere Prozesse jederzeit die CPU vorher bekommen) aber ohne Pausen gearbeitet (um schnell fertig zu sein). Eventuell gibt es noch Unterschiede, ob das Rechner mit Netzstrom oder Akku läuft.
Mein Plasma ist allerdings noch ziemlich schrottig. Das Panel hängt irgendwo in der Luft und allgemein scheint er die Auflösung nicht richtig zu erkennen. Naja, wenn ich Zeit habe schreibe ich mal einen Bug-Report...
KDE ansich entwickelt sich wirklich prima, doch die Plasma Desktop Shell scheint noch irgendwie das "Sorgenkind" zu sein. Ich hoffe, dass sich das bis zur Veröffentlichung noch bessert.
http://www.linux-magazin.de/heft_abo/ausgaben/2007/12/schoene_aussichten
Gruß, marrat
Bisschen alt...
Endlich sieht KDE mal nach was aus
Zwar bin ich vor nem halben Jahr wegen Ubuntu zu Gnome gewechselt und bin da auch sehr zufrieden aber die 4er werd ich mir definitiv mal installieren, wenn sie fertig ist.
Ich glaube zwar das die Wahl des Desktops bei weitem zu viel Bedeutung beigemessen wird, aber neugierig bin ich ja trotzdem. Na ja wen jemand wie ich in WinXp zuallererst alle Desktopeffekte abschaltet und dann noch das Win2000 theme wählt, das sagt ja schon alles
Wie viele RCs wirds denn noch geben? Respektive wie viele Berichte bei Pro-Linux?
Grüße
Oh, wie interessant!
das gibt es doch diesen windowsähnlichen Theme, irgendein Aufbau auf den fvwm2 -> Redmond98
http://www.fvwm.org/screenshots/desktops/Windows95-desk-1280x1024/screenshot.png
Wow, ein echter Teufelskerl!
*tststs* Dann musst du ja schon wieder die Distri wechseln
Also Gnome kann das.
Durch das Mounten des SMB Shares sieht die Datei zwar wie eine lokale Datei aus, wird aber beim Lesen Stück für Stück übertragen, d.h. den Bereich der Datei, denn der Player gerade ausliest.
Wird schon vom Kernel erledigt, daher gilt das natürlich für alle Programme. Ziemlich praktisch solche Filesystem Plugins im Kernel.
Bei KDE: Ich gehe via Dolphin auf Netzwerk/-SMB Freigaben -> Dort kann ich dann ganz normal mit den Daten umgehen als wären Sie auf meiner lokalen Festplatte.
Will ich aber dann z.B. eine MP3 Datei öffnen, bekommt das Programm eine smb url, mit der zumindest die gängigen Programme nichts anfangen können.
(Vielleicht gibt es auch eine ganz einfache Lösung dafür
Es kann sein, dass die Playerentwickler hier den einfacheren Weg genommen haben, die Daten zuerst zu cachen und dann als ganzen an die Engine (z.B. Xine) zu übergeben, anstatt sie in den Häppchen weiter zu geben, in denen sie eintreffen.
Hängt eventuell auch von der Engine ab, ob sie Daten blockweise über die API verarbeiten kann.
beim mir machen Videos im Totem alle paar Sekunden eine Pause zum cachen, wenn ich diese von SMB Shares starte.
Kann man das unterbinden?
D.C.
Es hat allerdings nichts mit der URL zu tun, dass nicht alle Programme z.B. sftp://daten/film.avi verstehen, dafür kann KDE nun wirklich nix.
Ob diese Information noch aktuell ist kann ich nicht mit Sicherheit sagen.
Allerdings ist es sehrwohl möglich "zu streamen", denn das ist die übliche Arbeitsweise der IO Slaves, d.h. Daten paketweise anliefern.
Es ist also mehr oder weniger eine Frage des Players, bzw. seiner Kommunikation mit seinem Backend oder seiner Multimediaschicht, ob er diese Daten dann häppchenweise oder als Gesamtes weiterreicht.
Vermutlich ist es in den üblichen Multimedia APIs leichter, es als Datei zu übergeben.
denn er kopiert das Zeug erst in das Temp Verzeichnis
also warte noch vier jahre...
Christian Ehrlicher
Ralf Habacker
Jaroslav Staniek
Nachdem bisher verschiedene Unix Plattformen bedient wurden, haben sich hie-und-da auch unixspezifische Sachen eingeschlichen, bzw. wurde Standard APIs verwendet, die wiedermal nur unter Windows nicht unterstützt werden.
Selbst ansich portable entworfene Software wie D-Bus ist davon nicht ausgeschlossen und erfordert daher manchmal auch Änderungen in anderen Projekten.
[1] http://lists.kde.org/?l=kde-windows
SaroEngels
PutHuhn
Shane King (amarok)
teilweise Andreas Pakulat
Man sollte das allerdings nicht falsch verstehen. Es geht dabei nicht darum, den kompletten Windows Desktop zu ersetzen, sondern vielmehr die Anwendungen, wie amarok, kate, konqueror, kopete und wie sie alle heißen, auf Windows lauffähig zu machen.
Deshalb sollte man das eigentlich nicht überbewerten.
Grundsätzlich jedenfalls. Soll wohl nur sehr langsam sein und persönlich habe ich es nie zu gesicht bekommen.
Ich zitiere mal den Herrn Sebastian Kügler:
"Pläne. den Desktop (Plasma, KWin) auch unter Windows und Mac OS zur Verfügung zu stellen, gibt es derzeit nicht. (Das heißt allerdings nicht, dass es nicht »Verrückte« gibt, die diese Komponenten auf diese Plattformen portieren. Wie es in der Free-Software-Welt halt ist (lacht)."
Von daher, wer weiß.
erinnert sich keiner mehr an Debian GNU/Win32 ?
Gruss,
Kay
In KDE3 gab es einen Fehler in den Oberflächentexten, von dem ich nicht weiß ob er schon behoben ist.
Wollte man einen bestimmten Dateityp mit einem bestimmten Player defaultmäßig öffnen (durch Klick oder Doppelklick auf die entsprechende Datei), musste man hierfür in das Kontextmenü der Datei gehen (rechte Maustaste), dort gibt es dann die Möglichkeit "Öffnen mit" wo man einige Programme auswählen kann oder man wählt "Sonstiges". Dort kann man dann aus einer Liste der zur Verfügung stehenden Programme auswählen. Hat man ein bestimmtes Programm gewählt, gibt es so eine kleine Checkbox, bei der steht "Programm dem Dateityp fest zuordnen" oder so ähnlich.
Dieser Text ist von der Formulierung her falsch. Es müsste heißen "Dateityp dem Programm fest zuordnen".
Ist zwar nur ein kleiner Fehler, ist mir aber in der neuen Mandriva 2008 wieder aufgefallen, dass es den immer noch gibt.
Wenn das einer von euch für KDE4 immer noch bestätigen kann, dann mach ich ne Meldung auf.
Christoph
Der Dateityp ist fest in diesem Fall, das Programm variable, du ordnest diesem Dateityp ein Programm zu.
Allerdings ist es auch andersherum nicht unbedingt falsch, nur programmzentrierter, aber hier geht es in erster Linie um den Dateityp.
Am Ende geht beides, aber falsch ist das erste nicht.
Ich möchte jetzt nicht klugscheißen und wahrscheinlich wirds mir jetzt eh keiner glauben aber ich hab Deutsch und Informatik studiert und arbeite bei SAP im Bereich Doku und Usability. Habe mir genau über ähnliche Formulierungen schon öfter den Kopf zerbrochen aber:
Du kannst ein Programm mehreren Dateitypen zuordnen, umgekehrt geht das jedoch nicht. Wenn man sagt man ordnet ein Programm einem Dateityp fest zu, dann heißt dies du assoziierst mit einem Programm einen festen Dateityp und genau da liegt der Fehler. Das Programm kann ja in der Regel mehrere Dateitypen bearbeiten und für mehrere Dateitypen die Default-Anwendung sein.
Dieses Prinzip würde man in der theoretischen Informatik mit Injektivität und Surjektivität bezeichnen, falls das jemand von euch kennt.
Denkt mal genau drüber nach
Ungeachtet davon ist diese Formulierung kein Beinbruch aber korrekt ist sie definitiv nicht.
Christoph
Das Programm Writer dem Dateityp Text fest zuordnen
so ist es original
verständlicher:
Dem Dateityp Text das Programm Writer fest zuordnen
Der Originaltext ist also richtig und Du hast auch recht
Man kann aber auch einem Dateityp mehrere Programme zuordnen, z.B. Auswahl von Programmen mit Hilfe von Kontextmenüs. Weiß allerdings nicht, ob das von KDE4 unterstützt wird.
Wie sieht es eigentlich mit einem Schachfrontend für die KDE4.0 aus? Bei GNOME ist eins dabei, bei der KDE sieht knights recht verweist aus...
(PS: Weiß auch zufällig jemand, in welchem Paket qtdemo unter Debian steckt?)
Kennst du schon die KDE-Brettspielplattform "Tagua"?
http://dot.kde.org/1189276647/
Schach ist offenbar von Anfang an bei diesem Projekt dabei ...
Die KDE 4.0 habe ich gerade mit der Debian Live KDE 4.0 getestet. WOW. Das sieht wirklich sehr gut aus, was die Entwickler da geleistet haben. Man spürt gleich, das mit Plasma viel los sein wird. Hoffentlich gibt es dafür ein Schachplasma - zig Partien frei auf dem Desktop verteilen, irgendwo noch die aktuelle Turniertabelle und die Paarungen - mit Plasma sicherlich kein Problem.
Nur kcontrol finde ich umständlicher als vorher, weil die Orientierung verloren geht.
Die Distributoren werden sich jedenfalls auf KDE 4.0 freuen - damit kommt das MAC-Feeling auf den PC!
Ich habŽ mal die LiveCD auf Suse-Basis getestet und fand zumindest das voreingestellte Verhalten des Desktops ausgesprochen ärgerlich:
1.) warum kann ich Kicker und das Menü nicht per Rechtsklick konfigurieren?
2.) Warum ist KDE4 auf der LiveCD der einzige Linux-Desktop (und ab MacOS Leopard überhaupt der einzige...) der keine richtige Integration von virtuellen Desktops hat?
3.)Warum kann ich nicht per Rechtsklick den Desktop (Bildschirmschoner, Hintergrund, etc) konfigurieren?
Das wären nur die Probleme, die mir nach einer Stunde schon endlos auf die Nerven gegangen sind.
Hinzu kommen 2 Fragen:
1.) Wie wollen es die KDE-devs bis zum 11 Dezember schaffen, die kapitalen Probleme von Konqueror zu lösen?
2.) Wenn diese und die oben genannten Probleme im SVN schon gelöst sind, warum konnte ich gestern eine Live-Demo herunterladen, die so aussah, als würde es noch 6 Monate dauern, bis KDE4 so schnell und sicher läuft wie KDE 3 in Mandrake 9?
Positives gibt es auch: das Ding sieht hübsch aus und Phonon scheint eine sehr ordentliche Lösung für Sound auf dem Desktop zu werden....
KDE, in seiner Eigenschaft als Applikationsframework, baut grundsätzlich auf den Errungenschaften von Bibliotheken und Spezialframeworks auf, es wäre ja auch nicht sehr zielführend, Arbeit in Duplikation von Funktionalität zu stecken, die Entwickler mit diesbezüglichen Kenntnissen schon anbieten.
Im Falle von Multimedia wäre es demnach nicht sehr zielführend, die Arbeit der GStreamer oder XINE Entwickler zu ignorieren, auch wenn das von manchen Leuten vielleicht als "...die Arbeit anderen überlassen..." gesehen wird.
Glücklicherweise verstehen die meisten Menschen, dass es im Interesse der Entwickler von Multimediabibliotheken ist, wenn ihre Arbeit auch benutzt wird.
Ich finde es sehr schade, dass KDE sich aus den Low-Level-Bereichen der Desktop Entwicklung zurück zieht. Da werden Ressourcen in Gimmics wie Plasma gesteckt ... schön bunt super ... die schweren Aufageben überlassen wir mal den anderen, ... echt schade. Es gab mal andere KDE Zeiten.
Je mehr sich KDE von den Low-Level-Bereichen abnabelt, desto plattformunabhängiger wird es. Das sehe ich als Vorteil. Es stimmt, dass KDE mit DCOP und aRTs Vorreiter in Low-Level-Techniken war, aber andere mussten das Rad (aus welchen Gründen auch immer) neu erfinden. Jetzt da eine Modernisierung der beiden Techniken fällig ist, steht man vor der Wahl, entweder ebenfalls aus Sturheit und Eitelkeit die eigene Entwicklung weiter voranzutreiben, oder auf inzwischen bestehende Lösungen aufzusetzen und sich wieder auf seine Kernkompetenzen zu konzentrieren. Ich begrüsse die getroffene Entscheidung. Mit der Zwischenschicht Phonon gewinnt man nicht nur API-Stabilität über die verschiedenen Plattformen hinweg, sondern hat auch das Gezanke um das "Multimedia-Framework der Woche" auf Linux elegant umgangen.
Man kann einfach nicht allen Leuten recht machen.
Wenn KDE Basisinfrastruktur macht gibt es welche, die sich darüber aufregen, wenn man später beim Aufkommen von Alternativen die eigene Lösung beibehält, und wenn man dann bei der nächsten Möglichkeit auf gemeinsam benutzbare Infrastruktur umstellt gibt es welche, die sich darüber aufregen, man würde anderen die Arbeit überlassen.
Obwohl KDE eine sehr große Entwicklergemeinschaft hat, kann sie sich nicht um den gesamten Desktopsoftwarestack oberhalb des Kernels kümmern.
Ich denke es ist besser, man überlässt zum Beispiel den X-Entwicklern die Arbeit am X-Server und dessen Treibern, etc.
KDE Entwickler, die für solche Bereiche auch Interesse haben, arbeiten dort ja ohnehin von sich aus mit, z.B. Zack Rusin bei X-Server Treibern, Thiago Maciera und unsere Windowsleute bei D-Bus, usw.
Nur weil man heutzutage nicht mehr alles selber machen muss und sich nicht im Keller mit Keksen einschließt um die Super 4k Bibliothek ala Assembler zu schreiben, heißt das nicht das man sich nicht mehr mit Grundlagen beschäftigt.
Heutzutage sind Themen wie Architektur, Philosophie, Modellierung und API Design endlich in den Vordergrund gerückt. Beispiele sind D-Bus und freedesktop.org. Das ist auch Grundlagenarbeit, die alte passiert aber auch noch, nur etwas versteckter dahinter, wo sie auch hin gehört wenn man sich mit so etwas allgemeinem wie einen Desktop auseinander setzt.
Grüße
Felix
2.) Natürlich werden virtuelle Desktops unterstützt, vielleicht ist es nicht Default aber es gibt ein Pager/Workspace plasmoid.
3.) Weil es beim RC1 noch nicht implementiert war, im SVN kann man per Rechtsklick den Hintergrund ändern.
1.) Gute Frage
2.) Sie sind nicht im SVN gelöst.
Ganz toll - Desktop ohne Panel. Wozu soll das gut sein?
>2.) Natürlich werden virtuelle Desktops unterstützt, vielleicht ist es nicht Default aber es gibt ein Pager/Workspace plasmoid.
Dieser Pager wird aber von Fenstern auf dem Desktop verdeckt, was ihn letztlich unbrauchbar macht. Von einer Integration der virtuellen Desktops kann man damit nicht reden...
>3.) Weil es beim RC1 noch nicht implementiert war, im SVN kann man per Rechtsklick den Hintergrund ändern.
Da bin ich ja beruhigt.... hatte schon gedacht, dieses Feature sollte gestrichen werden, weil es jemanden verwirren könnte....
Wer hat gesagt, es gäbe kein Panel mehr?
Das Programm Kicker gibt es nicht mehr, Panels sind jetzt eine Form von Plasmacontainer.
Sieht man ja praktisch auf jedem Screenshot
Dieser Pager wird aber von Fenstern auf dem Desktop verdeckt...
Wenn man ihn auf dem Desktop statt auf einem Panel platziert, ja. Aber warum sollte man das tun, wenn man ihn auch bei maximierten Fenstern benutzen möchte?
Auf der DemoCD ist das so konfiguriert, dass das Panel-Plasmoid nur auf dem ersten Desktop zu sehen ist, damit ist es leider sinnlos.
Das man das umkonfigurieren kann (also von unbrauchbar auf vernünftig) ist leider nicht leicht herauszufinden, danke für den Tipp...
>Wenn man ihn auf dem Desktop statt auf einem Panel platziert, ja. Aber warum sollte man das tun
weil das die Voreinstellung ist und nicht zu erkennen ist, dass man den Pager auf die Panel-leiste legen kann...
> eine Live-Demo herunterladen, die so aussah, als würde es noch 6 Monate dauern, bis KDE4 so schnell
> und sicher läuft wie KDE 3 in Mandrake 9?
Blöde Frage. KDE3 hat Jahrelange Entwicklung und mehrere Versionen hinter sich. Warum sollte ein großer Wurf wie KDE4 das dann gleich bei der ersten Version schaffen?
Im aktuellen SVN kann man schon ansatzweise sehen, dass "Kicker" jetzt zu einem konfigurierbaren Plasmoid umgewandelt wird.
Virtuelle Desktops gibt es mit Sicherheit, einfach warten, wie gesagt, viele der Dinge, die man "sieht" müssen sich noch entwickelt.
Das ist weniger schlimm als man jetzt denkt, da es wirklich nur das Optische ist.
Warten lohnt sich oft aber wie soll das alles bis zum 11. Dezember fertig werden? Und/oder: wieso soll eine Software, die so wichtig ist wie KDE, als Major-Release freigegeben werden, wenn sie noch so unterentwickelt ist, dass sie ein gutes Drittel der Leistungen ihres Vorgängers nicht bringen kann....
Prinzipiell zwingt dich auch keiner, die vorgegebene Taskleiste zu verwenden. Es könnte auch jemand etwas Alternatives veröffentlichen, das dir mehr zusagt und ähnliche (oder bessere?) Funktionen bietet.
Es wurde ja zuletzt erst ein Beispiel gegeben, mit dem Startmenü. Ich zum Beispiel mag das neue Startmenü gar nicht leidern, ich hätte am liebsten wieder das alte K-Menü. Jetzt weiß ich zwar nicht, ob das schon im Gange ist, aber prinzipiell sollte es kein Problem darstellen, ein Plasmoid zu erstellen, das die Funktionalität des K-Menüs hat (evtl. mit ein paar Verbesserungen).
Was ich damit sagen will ist, dass schlicht nicht so viel fehlt wie es gerade aussieht.
..."im Prinzip" klingt verdächtig nach Radio Eriwan. Das Problem ist allerdings, dass das, was die KDE-Entwickler hier als "RC1" präsentieren im großen und ganzen Alpha-Qualität hat: Technisch interessant aber Hölle von instabil und vollkommen unvollständig.
"Release Candidate" heißt, dass die Software fertig ist und dass nur noch ggf. vorhandene Fehler beseitigt werden, bzw (deshalb "Candidate"), dass sie so veröffentlicht wird, falls keine gravierenden Bugs mehr gefunden werden.
Das, was hier als RC1 präsentiert wird (getestet unter OpenSUSE 10.3), ist in Sachen Stabilität und Ausgereiftheit wirklich unter aller Kanone, kaum ein Programm verrichtet störungsfrei seinen Dienst. Ich verstehe nicht, welcher Teufel die KDE-Leute geritten hat, den Release-Plan so ohne Rücksicht auf Verluste durchzuziehen.
Aber ich denke mal, das hängt damit zusammen, dass die KDE Entwickler von Anfang an gesagt haben, dass für die Endbenutzer eigentlich erst KDE 4.1 gedacht ist und KDE 4.0 hauptsächlich für die Entwickler von Anwendungen ist, damit die ihre Anwendungen portieren können.
Dennoch hätte man sich für ein besser passendes Namensschema entscheiden sollen.
1. Wie sucht man gezielt nach Inhalten in E-Mails?
2. Wieso frisst strigidaemon locker 30-80% der CPU laut top? Soll das so sein oder ist das ein Bug (Debian/Sid)?
Vermutlich über Einschränkung der Suche auf einen speziellen MIME Type. Ich glaube EMails sind message/rfc822
2. Wieso frisst strigidaemon locker 30-80% der CPU laut top? Soll das so sein oder ist das ein Bug (Debian/Sid)?
Im laufenden Betrieb oder bei der Indizierung?
Bei der Indizierung wird glaub ich so verfahren, dass mit niederer Priorität (sodass andere Prozesse jederzeit die CPU vorher bekommen) aber ohne Pausen gearbeitet (um schnell fertig zu sein).
Eventuell gibt es noch Unterschiede, ob das Rechner mit Netzstrom oder Akku läuft.
zu 2.: Im laufenden Betrieb. Ist die Inotify-Benachrichtigung von strigidaemon mittlerweile bugfrei und aktiv?