Zum Glück benutz ich Gnome, da muss ich mich mit dem KDE RC-Krams nicht beschäftigen ;)
Wie ist das mit KDE 3.3 wird das schon was mit der Transparenz anfangen können, die das nächste X-Release unterstützen soll? Oder hab ich da was in den flaschen Hals bekommen?
Konsole in den Betas konnte "composite"-Transparenz, ist aber wegen dadurch verursachter Probleme in der endgültigen Version per "#ifdef 0" ausgeschaltet.
Wenn's mit dem X-Server mal voran gehen würde und nicht jeder seinen eigenen Fork aufmachen würde der dann sowieso nicht 100% kompatibel ist und bei dem es mit der Entwicklung auch nicht voran geht könnte man auch bessere Transparenzeffekte einbauen.
Der Xserver ist einfach immer noch das altertümlichste an einem Unix System (nicht schlecht, aber altertümlich).
ich denke wenn es einen GPL X-Server geben würde wären einige Probleme nicht vorhanden! (imho sind das doch alles irgendwelche Abarten von X11 Lizenzen bei den Forks oder?)
wenn ich screenshohs mit transparenz sehe frage ich mich immer "wie sinnvoll ist das?". gut möglicherweise gibt es manche sinnvolle fälle, aber meiner meinung gehört sowas nicht in menüs oder konsolen. zugegeben, wenn man es zum ersten mal sieht, findet man es schon besonders cool. doch praktisch gesehen bringt es nur den nachteil einer schlechten lesbarkeit der schrift in den menüs/konsolen.
ist wie bei tiefergelegten autos. sieht zwar cool aus wenn nur noch 2cm zw. auto und boden sind. doch jemand der sein auto produktiv einsetzten will wird das alles andere als praktisch sehen, wenn er bei der nächsten bodenwelle nicht weiterfahren kann ohne das auto kaputt zu machen.
Von Michael Thaler am Mi, 11. August 2004 um 13:11 #
Ich gebe dir recht dass transparente xterms und Menueschatten eher eine Spielerei sind, Fensterschatten finde ich aber schon sinnvoll, vor allem weil man dadurch keinen Fensterrahmen mehr braucht. Das macht z.B. MacOS X (und auch Baghira) so und dadurch hat man effektiv mehr Platz im Fenster.
Und ich will meinen Rechner zwar produktiv einsetzen, aber ich finds trotzdem schoen wenn mein Desktop auch schoen aussieht.
Solange man diese ganzen Spielereien noch ausschalten kann gehts ja. Da werden aber noch einige Dinge kommen denen man kaum noch etwas sinnvolles abgewinnen kann.
Von Ralph Miguel am Mi, 11. August 2004 um 14:51 #
Und wenn ich irgendwo Designer-Kunststückchen sehe, dann frage ich nicht nach dem Sinn. Wenn es mir gefällt, dann aktiviere ich sie; wenn nicht, dann lasse ich es bleiben.
Transparenz hat definitiv einen praktischen Nutzen. Lange Coding-Sessions in VIM könnte ich mir mit einem plain-weißen Hintergrund gar nicht vorstellen.
Auch transparente Menüs haben, wenn auch einen kleineren, praktischen Nutzen: Wenn ich ein Kontextmenü aufrufe und mir einfällt dass ich Informationen brauche, die unter dem Menü versteckt sind. Kommt häufig vor. Ohne Transparenz klickst das Menü halt kurz weg und gut ist. Mit Transparenz sparst Du Dir den Klick.
Das hast du dir doch eben aus den Fingern gesogen um auch mal was zu schreiben. So nebenbei erwähnst du noch das du mit dem Vi programmierst, um dich als Guru hinzustellen. Dabei kommt doch nur Käse raus...
OK, alle "KDE ist besser als Gnome", "Gnome ist besser als KDE", "Ich benutze Gnome" und "Ich benutze KDE" - Flame-Posts bitte hierin, damit die ganzen Flames nicht überall im Thread verstreut sind...
... sollte man eigentlich standardmäßig als ersten Post hinschreiben, wenn eine Meldung zu KDE oder Gnome kommt.
...oder zu Editoren ...oder zu Kerneln ...oder zu Mailern ...oder zu irc-clients ...oder zu browsern ...oder zu shells ...oder zu Distributionen ...oder zu ${foobar}
daß die Zusammenarbeit des Konqueror-Teams mit den Safarileuten etwas weniger wurde.
Soll kein Trollen sein !
Nach der Ankündigung gemeinsam khtml zu verbessern dachte ich jetzt würde Apple ständig in den Changelogs stehen, aber scheinbar ist es nicht so.
Vielleicht wartet Apple darauf, bis wieder eine interessante Neuerung kommt, die sie allein nicht an den Safari angepasst bekommen.
Mal eine (dumme?) Frage: Wenn Apple wirklich alle Änderungen an Khtml an die KDE-Entwickler zurückgibt, dürfte der Konqueror doch keine Probleme mehr beim Anzeigen der meisten Seiten haben.
Ich kann mir nicht vorstellen, daß Apple seinen Kunden einen Browser anbietet, der bei doch einigen Seiten starke Abweichungen in der Anzeige hat.
Da ich den Safari nicht testen kann, sind das nur Vermutungen ...
> daß die Zusammenarbeit des Konqueror-Teams mit den Safarileuten etwas weniger wurde.
Sie ist auf jeden Fall schwieriger als gehofft. Das Apple-Team werkelt in einem eigenen closed Repository und ab und zu (Entwickler-Konferenz/Safari-Release) wird dann der Webcore-Tarball released. Der enthält dann zwar ein Changelog, aber keine einzelnen Diffs zu dessen Einträgen. D.h. die khtml-Entwickler müssen sich die passenden Teile für Fix/Feature selbst rausfrickeln und schauen dass sie nicht z.B. Erweiterungen für Dashboard übernehmen.
> Wenn Apple wirklich alle Änderungen an Khtml an die KDE-Entwickler zurückgibt, dürfte der Konqueror doch keine Probleme mehr beim Anzeigen der meisten Seiten haben.
Das wie zurückgeben ist das Problem, deren Version basiert irgendwie auf KDE_3_1_BRANCH und khtml hat seitdem eben auch eigene Weiterentwicklung und weiterhin im KDE-Repository.
Nein RC2 ist aktuell und warum auf dem CVS? Nehme dazu doch einfach das empfohlene Buildtool "Konstruct" wenn du kein Gentoo hast. (Bei Gentoo ist der rc2 seit gestern drinnen)
Von maestro_alubia am Mi, 11. August 2004 um 14:39 #
Ist ein bischen OT:
Wann kann man mit einer Integration von Kaffeine in das KDE-Multimedia-Paket rechnen ? Oder ist das gar nicht vorgesehen?
Ich bin mit Kaffeine sehr zufrieden und es ist mein bevorzugter Player, nur er scheint nicht mehr ganz so gut mit KDE 3.2.3 zusammenzuarbeiten, so dass in Zukunft eine bessere Kompatibilität zu wünschen wäre.
Von tach und tschüss am Mi, 11. August 2004 um 14:56 #
Gibts es denn nicht schon einige Player im Kdemultimedia-Paket? Kann sich doch jeder den Player nachträglich installieren. Finde nicht das man unbedingt alles was einigermassen gut ist per Default in die KDE-Distributionspakete stecken sollte. Imho ist jetzt schon viel zu viel da drinnen. Wenn ich mal so nach einer frischen Installation das Menü durchsuche wird einem ja ganz schwindelig... Alleine bei Texteditoren stehen bei mir 3 drinnen (Kate, Kwrite, KEdit) und natürlich noch die anderen erkannten von VIM bis nano. Bei Playern geht das auch von Kaboodle bis Noatun...
Von maestro_alubia am Mi, 11. August 2004 um 15:47 #
Naja, mir ist es ja auch weniger wichtig, dass es im Paket enthalten ist, als dass das Programm akzeptabel läuft und man KDE updaten kann, ohne Inkompatibilitäten befürchten zu müssen.
Hmm, bedauerlich. Ich benutze Kaffeine auch sehr gerne, da er alle wichtigen Features hat und trotzdem sehr übersichtlich und einfach zu handhaben ist. Besonders die Steuerung der DVD-Menüs finde ich sehr gelungen. Auf Noatun und Kaboodle könnte ich hingegen verzichten.
Von maestro_alubia am Do, 12. August 2004 um 00:40 #
Mit den beiden konnte ich mich auch noch nie richtig anfreunden.
Kaffeine ist dank der xine-lib deutlich flexibler und umfangreicher.
Zudem ist die getrennte Entwicklung von Front- und Backend effektiver und für die Community wesentlich vorteilhafter, da auch beispielsweise GNOME von Verbesserungen an der xine-lib und damit eigener Frontends wie gxine profitiert.
Insgesamt würde Linux und Co. in Sachen Multimedia dadurch erneut erfreulich zulegen.
Ich habe übrigends das dringende Bedürfnis, einen Multimedia-Player für alle möglichen Medien zu haben. Sowohl DVD/DVB/CD als auch MPEG1/2/3/4/,DivX/Xvid,Quicktime,WMV/WMA,Ogg,AAC... und Internet-Streams soll ein einziger Player können. Xine ist dafür bestens geeignet.
Sobald Kaffeine noch ein bischen stabiler geworden ist, ist es für mich der perfekte Player. Danke dafür an Jürgen Koffler und die anderen Kaffeine-, Xine- und Codec- Programmierer. :-)
Zum Glück benutz ich Gnome, da muss ich mich mit dem KDE RC-Krams nicht beschäftigen ;)
Wie ist das mit KDE 3.3 wird das schon was mit der Transparenz anfangen können, die das nächste X-Release unterstützen soll? Oder hab ich da was in den flaschen Hals bekommen?
Der Xserver ist einfach immer noch das altertümlichste an einem Unix System (nicht schlecht, aber altertümlich).
ich denke wenn es einen GPL X-Server geben würde wären einige Probleme nicht vorhanden! (imho sind das doch alles irgendwelche Abarten von X11 Lizenzen bei den Forks oder?)
Fensterschatten auch mit KDE
Gruß, Mark
gut möglicherweise gibt es manche sinnvolle fälle, aber meiner meinung gehört sowas nicht in menüs oder konsolen.
zugegeben, wenn man es zum ersten mal sieht, findet man es schon besonders cool. doch praktisch gesehen bringt es nur den nachteil einer schlechten lesbarkeit der schrift in den menüs/konsolen.
ist wie bei tiefergelegten autos. sieht zwar cool aus wenn nur noch 2cm zw. auto und boden sind. doch jemand der sein auto produktiv einsetzten will wird das alles andere als praktisch sehen, wenn er bei der nächsten bodenwelle nicht weiterfahren kann ohne das auto kaputt zu machen.
Und ich will meinen Rechner zwar produktiv einsetzen, aber ich finds trotzdem schoen wenn mein Desktop auch schoen aussieht.
Solange man diese ganzen Spielereien noch ausschalten kann gehts ja.
Da werden aber noch einige Dinge kommen denen man kaum noch etwas sinnvolles abgewinnen kann.
Transparenz hat definitiv einen praktischen Nutzen. Lange Coding-Sessions in VIM könnte ich mir mit einem plain-weißen Hintergrund gar nicht vorstellen.
Auch transparente Menüs haben, wenn auch einen kleineren, praktischen Nutzen: Wenn ich ein Kontextmenü aufrufe und mir einfällt dass ich Informationen brauche, die unter dem Menü versteckt sind. Kommt häufig vor. Ohne Transparenz klickst das Menü halt kurz weg und gut ist. Mit Transparenz sparst Du Dir den Klick.
... sollte man eigentlich standardmäßig als ersten Post hinschreiben, wenn eine Meldung zu KDE oder Gnome kommt.
...oder zu Kerneln
...oder zu Mailern
...oder zu irc-clients
...oder zu browsern
...oder zu shells
...oder zu Distributionen
...oder zu ${foobar}
Soll kein Trollen sein !
Nach der Ankündigung gemeinsam khtml zu verbessern dachte ich jetzt würde Apple ständig in den Changelogs stehen, aber scheinbar ist es nicht so.
Vielleicht wartet Apple darauf, bis wieder eine interessante Neuerung kommt, die sie allein nicht an den Safari angepasst bekommen.
Mal eine (dumme?) Frage:
Wenn Apple wirklich alle Änderungen an Khtml an die KDE-Entwickler zurückgibt, dürfte der Konqueror doch keine Probleme mehr beim Anzeigen der meisten Seiten haben.
Ich kann mir nicht vorstellen, daß Apple seinen Kunden einen Browser anbietet, der bei doch einigen Seiten starke Abweichungen in der Anzeige hat.
Da ich den Safari nicht testen kann, sind das nur Vermutungen ...
Vielleicht hat er ja die gleichen Probleme.
Sorry, daß ich nicht vorher gegoogelt habe was Webcore ist.
Die Zusammenarbeit scheint doch zu klappen.
Sorry Apple
und nein, es ist (leider) nicht alles portiert - oder sollte konq 3.3 wirklich text-shadow: können? *hoff* *wünsch* *sabber*
Sie ist auf jeden Fall schwieriger als gehofft. Das Apple-Team werkelt in einem eigenen closed Repository und ab und zu (Entwickler-Konferenz/Safari-Release) wird dann der Webcore-Tarball released. Der enthält dann zwar ein Changelog, aber keine einzelnen Diffs zu dessen Einträgen. D.h. die khtml-Entwickler müssen sich die passenden Teile für Fix/Feature selbst rausfrickeln und schauen dass sie nicht z.B. Erweiterungen für Dashboard übernehmen.
> Wenn Apple wirklich alle Änderungen an Khtml an die KDE-Entwickler zurückgibt, dürfte der Konqueror doch keine Probleme mehr beim Anzeigen der meisten Seiten haben.
Das wie zurückgeben ist das Problem, deren Version basiert irgendwie auf KDE_3_1_BRANCH und khtml hat seitdem eben auch eigene Weiterentwicklung und weiterhin im KDE-Repository.
Den Apple-Kunden stört das aber nicht, so lange das Design des Gehäuses einigermaßen ansprechend ist.
>Den Apple-Kunden stört das aber nicht, so lange >das Design des Gehäuses einigermaßen >ansprechend ist.
Auch wieder wahr
:)
Im CVS ist kein TAG diesen Namens.
Ich nehme also mal an das das RC1 ist.
>>http://download.kde.org/unstable/3.3.0rc1/src/ - but it was intentionally not announced.
(Bei Gentoo ist der rc2 seit gestern drinnen)
Wann kann man mit einer Integration von Kaffeine in das KDE-Multimedia-Paket rechnen ? Oder ist das gar nicht vorgesehen?
Ich bin mit Kaffeine sehr zufrieden und es ist mein bevorzugter Player, nur er scheint nicht mehr ganz so gut mit KDE 3.2.3 zusammenzuarbeiten, so dass in Zukunft eine bessere Kompatibilität zu wünschen wäre.
Imho ist jetzt schon viel zu viel da drinnen. Wenn ich mal so nach einer frischen Installation das Menü durchsuche wird einem ja ganz schwindelig... Alleine bei Texteditoren stehen bei mir 3 drinnen (Kate, Kwrite, KEdit) und natürlich noch die anderen erkannten von VIM bis nano. Bei Playern geht das auch von Kaboodle bis Noatun...
Meine Stimme bekommt jedenfalls kaffeine. Sehr schöner und benutzbarer Player.
Kaffeine ist dank der xine-lib deutlich flexibler und umfangreicher.
Zudem ist die getrennte Entwicklung von Front- und Backend effektiver und für die Community wesentlich vorteilhafter, da auch beispielsweise GNOME von Verbesserungen an der xine-lib und damit eigener Frontends wie gxine profitiert.
Insgesamt würde Linux und Co. in Sachen Multimedia dadurch erneut erfreulich zulegen.
Ich habe übrigends das dringende Bedürfnis, einen Multimedia-Player für alle möglichen Medien zu haben. Sowohl DVD/DVB/CD als auch MPEG1/2/3/4/,DivX/Xvid,Quicktime,WMV/WMA,Ogg,AAC...
und Internet-Streams soll ein einziger Player können. Xine ist dafür bestens geeignet.
Sobald Kaffeine noch ein bischen stabiler geworden ist, ist es für mich der perfekte Player.
Danke dafür an Jürgen Koffler und die anderen Kaffeine-, Xine- und Codec- Programmierer. :-)
(Das natürlich auch mit dem ebenso genialen Konqueror funktioniert)