Von einem kleinen Linuxgott am Mo, 17. Juli 2006 um 08:16 #
OK, OK, es geht weiter. Überall in den großen GUI-Bibliotheken (GTK, Gnome, QT, KDE), aber seid doch mal vernünftig und versucht alle Schnittstellen nach und nach einander anzugleichen. Es wäre sinnvoll langsam beiden Systeme zu verschmelzen und das beste von beiden jeweils ins andere zu übernehmen.
Bullshit - die GUI Elemente sind strukturell alle gleich. Es ginge "nur" darum, sie in eine gemeinsame Beschreibungssprache zu überführen und damit vom Toolkit zu lösen. Ob die Darstellung dann nach Gnome, KDE oder Motif aussehen soll, wäre dann Frage der Präferenz. Schwieriger zu abstrahieren wären HIG-Unterschiede (Button-Order, der verschlimmbesserte Gnome-Dateidialog, etc.) oder profilbasierte Shortcuts. Ob die Programmierer nun Gtk oder Qt verwenden, ist für den Anwender zweitrangig.
Du meinst sowas wie Glade mit der gladelib? (abstrahiertes GUI Framework auf XML basis ähnlich zu XUL) Leider ist Die Lib etwas dürfig ausgestattet was die Elemente betrifft. Aber immerhin wird daran gearbeitet. Ich las mal von einer idee das ganze auch für Qt um zu setzen. Ist aber wohl im Sande verlaufen.
>Bullshit - die GUI Elemente sind strukturell alle gleich ja so ein bullshit gtk und qt sind leider welten auseinander und die elementen haben wirklich gar nichts gemeinsam. GTk ist übrigens in C geschrieben und QT in C++. Da liegen wirklich Welten(!) dazwischen. Die Elemente haben echt sehr wenig gemeinsam, sieh dir allein mal welche Datentypen die glib2 hat und welche das in Qt sind. Sorry du bekommst verdienst dir echt die Zitrone des Jahres
Das wird eigentlich nie der Fall sein, da bei beiden eine andere Politik" dahinter steht. Man könnte lapidar sagen, dass Gnome versucht sich an OSx anzunähern und das Look and Feel als auch die einfachheit der Bedienung zu Klonen oder in gewisserweise die besten Teile dessen zu übernehmen. KDE ist dabei eher das gleiche, nur mit einer Ausrichtung auf Windows.
Nur weil GNOME nicht anders als MacOS aussehen kann sind solche Behauptungen einfach nicht wahr: die KDE schränkt die Leute nicht ein und gibt ihnen viele Möglichkeiten Ihren Rechner so zu konfigurieren, wie sie ihn am besten nutzen können - KDE kann genau wie die MacOS-Oberfläche aussehen. Bei mir tut sie es jedenfalls.
Hab auch nichts dagegen gesagt, dass KDE dies nicht kann. Hab jediglich behauptet, dass gnome und kde eine verschiedene Politik bzgl ihres Systems haben. Außerdem ist der vergleich zwischen gnome und mac os legitim, da OSx genau wie Gnome den user einschränkt und man nur wenige möglichkeiten zur Anpassung hat (außer man installiert diverse Tools unter OSx). Windows/Kde haben da mehr möglichkeiten. Liegt halt auch daran, dass Gnome/OSx beide das gleiche Ziel mit "Einfachheit und Benutzerfreundlichkeit" verfolgen.
Die animierten Epilepsieoberflaechen sind aber nicht gut. Sie sind scheinbar fuer Bekiffte erstellt soviel wie sich bei jeder kleinen Aktion bewegt, blinkt, piept und krampfartig rumhupeft obwohl man arbeiten will.
Falls du in einem KDE-Programm eine freie Fläche findest, die weder einen blinken Button noch ein rotierendes 3D Icon enthält, dann solltest du das im KDE Bugtracker aber sofort als Bug melden!
wird doch gemacht stichwort dbus (das kommt auch in kde4) oder xdg. meines wissens nach soll auch cairo mit kde4 unterstützt werden. gnome ist da wie immer natürlich vorraus und setzt schon heute auf das D-Bus und cairo (open desktop standards)
Also zunächst einmal, Gnome mag im Moment vorraus sein, ist es aber nicht immer und überall. Es zeigt sich meiner Meinung nach eher eine ständige Verschiebung, wer gerade technisch die Nase vorn hat. Schließlich spornen sich die beiden Projekte so ja auch gegenseitig an.
Und ja, einige auf freedesktop.org entwickelte Sachen kommen mit KDE4. Das liegt daran, dass KDE generell nicht so die Scheuklappen aufhat, wenn es um Software geht, die nicht von ihnen selbst entwickelt wurde. Außerdem sehe ich nur Vorteile, wenn eine gewisse Basis zusammenentwickelt wird.
Die "Zeichnungslibrary", weiß nicht wie ich es sonst nennen sollte, welche in KDE4 durch Qt4 vorhanden ist heißt Arthur. Diese ist grundsätzlich in der Lage auch andere Backends zum anzeigen zu nutzen, darunter auch Cairo. Es stellt sich nur die Frage nach dem Sinn, immerhin ist Arthur weiter entwickelt als Cairo. Cairo plant sogar erst noch Dinge, die in Arthur schon enthalten sind. Außerdem kann Arthur ebenfalls OpenGL direkt nutzen, was das ganze noch mehr in Frage stellt.
> Das liegt daran, dass KDE generell nicht so die Scheuklappen aufhat, wenn es um Software geht, die nicht von ihnen > selbst entwickelt wurde. sorry aber kde hängt bei freedesktop standards ständig hinterher. Übrigens kann cairo (freedesktop-standard) bereits jetz via glitz (auch freedestop standard) open-gl direkt nutzen. Das tut Cairo auf meinenm System (zenwalk) schon seit fast einem Jahr. Ich kenne keine distro die bisher arthur ausliefert, da es nämlich noch gar nicht fertig ist.
Arthur soll meines wissens nach nur api sein ganz ohne backend
Am meisten vermisse ich bei KDE den mangel für enchant (freedesktop standard) damit könnten kde-programm dann endlich hunspell für die rechtschreibprüfung verwenden und ich müsste nicht immer alle wörterbücher doppelt aspell/hunspell installieren.
> sorry aber kde hängt bei freedesktop standards ständig hinterher.
Was unbestätigten und bösartigen Gerüchten zufolge damit zusammenhängen könnte, dass Teile dieser sogenannten Standards ihren Ursprung im GNOME-Umfeld haben ;-)
Stichworte: Ximian, FUD, GStreamer, Unterwanderung etc.
Übrigens ist es nicht mal vollständig richtig, KDE unterstützt und nutzt z.B. bereits die Papierkorb-Spezifikation [1] und GNOME nicht.
Von Da isser der Schmutzfink am Mo, 17. Juli 2006 um 20:15 #
KDE unterstützt und nutzt z.B. bereits die Papierkorb-Spezifikation [1] und GNOME nicht. Na da bin ich aber froh, dass die KDE-Devs ihre Prioritäten richtig setzen. Bugfixing ist sowieso "totally overrated".
Ähem, Cairo gibt auf seinen eigenen Seiten wieder, was ich gerade geschrieben habe. Sie stellen sich die Frage nach dem Sinn und weisen darauf hin, dass Arthur weiter entwickelt ist. Schön, dass Du mehr weißt, als die eigentlichen Entwickler.
Arthur ist in Qt4 enthalten, es läuft jetzt schon und ist für alle Distributionen zu haben. KDE4 wird auf QT4 basieren und daher eben all diese Dinge anbieten können, wenn es fertig ist.
Außerdem weißt freedesktop.org auf seinen Seiten explizit drauf hin, dass sie keine Standards erstellen oder verwalten. Gerade das macht den Erfolg von ihnen aus und sorgt für gute Zusammenarbeit unter den großen DEs. Warten wir doch einfach mal KDE4 ab, Ende des Jahres wird es ja schon die ersten Alphas geben, wie ich gehört habe. Vielleicht kann man dann ja auch hunspell für KDE verwenden.
das was kspell2 da verwendet ist so unbrauchbar, nö danke. Toll übrigens das die KDE-Chaoten noch ispell verwenden ich hätte gerne HUNSPELL und das geht in KDE defintiv nicht. Ich mein was soll der scheiss: ispell - kann nur englisch hspell - kann nur hebräisch aspell - Kann intern immer noch kein Unicode, damit nicht internationalisierungsfähig.
Wenn du es so gern hättest, dann kümmere dich darum, anstatt rumzublubbern. Daß kspell2 nicht das gelbe vom Ei ist, wird wohl kaum jemand bestreiten, rechtfertigt aber keinesfalls deine Falschaussage.
Ich musste schmunzeln, als ich die Liste der Verbesserungen gelesen habe. Fast alles dort genannte kann KDE bereits seit mehr als einem Jahr. Ich schätze mal wie viele Jahre die Gnome-Neuerungen bei KDE dabei sind: Bildschirm-Rotation: 1.5 Jahre Anwendungen im Terminal starten: 7 Jahre Dateirechte rekursiv zu vergeben: 4 Jahre SElinux REchte setzen: ? echte Transparenz im Terminal: ? (nicht sicher) Sitzungs-Verwaltung vollständig: 4 Jahre
Sieht eher so aus als wäre Gnome inzwischen feature-mäßig bei KDE's Stand vor drei Jahren angelangt... Sollte es wahrscheinlich bald mal wieder testen
Von Christian Neumair am Mo, 17. Juli 2006 um 17:45 #
> Ich musste schmunzeln, als ich die Liste der Verbesserungen gelesen habe. Fast alles dort genannte kann KDE bereits seit mehr als einem Jahr
Ich habe als GNOME-Entwickler immer Probleme mit derartiger Kritik und fühle mich ziemlich verprellt, wenn ich "wurde aber auch langsam Zeit" zu hören bekomme:
Wir haben massive Probleme eine stabile Entwicklerbasis zu halten und als Vollzeitstudent kann ich auch nicht gerade über Zeitüberschuss klagen. Trotzdem habe ich irgendwie die paar Stunden aufgebracht, um Nautilus eine Sitzungs-Verwaltung zu spendieren. Das sollte denjenigen unter Euch, die sich regelmäßig über ungelöste Probleme und Fehler beschweren Ansporn sein, sich ebenso einzubringen.
Rund 10-20 Entwickler sind dafür verantwortlich, dass Ihr überhaupt signifikante Fortschritte an der Plattform über die letzten Jahre mitverfolgen und kommentieren durftet. Ansonsten hieße es "tote Hose" und "immer druf'", "taugt nix" und "vollkommen veraltet".
Es wäre schön, wenn der Dreisatz Kritik -> Problemanalyse -> Problemlösung von mehr als nur einer Hand voll Beteiligten verinnerlicht werden würde. Gerade freie Software lebt davon, dass einzelne initiativ werden - rührig sind - und sich konstruktiv einbringen.
Ich möchte abschließend darauf hinweisen, dass wir uns vieler Unzulänglichkeiten bewusst sind, aber schlicht nicht die Ressourcen haben, diese zu beheben. Dazu braucht es einfach mehr aktiv Mitwirkende, und nicht journalistisch-akribisch aber vollkommen passiv analysierende und publizierende Beobachter.
Jetzt bin ich etwas verwirrt, denn ich lese von sovielen Firmen die sich mit GNOME schmücken und doch auch Arbeit daran leisten. Das müssen doch also mehr als 10-20 Entwickler sein und es sollte daher doch auch eine stabile Entwicklerbasis geben...
Andernfalls wäre es natürlich sehr traurig für einen Desktop, welcher die Benutzer von Windows zu Linux führen soll...
Von Christian Neumair am Mo, 17. Juli 2006 um 20:44 #
> Jetzt bin ich etwas verwirrt, denn ich lese von sovielen Firmen die sich mit GNOME schmücken und doch auch > Arbeit daran leisten. Das müssen doch also mehr als 10-20 Entwickler sein und es sollte daher doch auch eine > stabile Entwicklerbasis geben...
Dass sich Firmen engagieren ist vollkommen richtig und auch für die Existenz der Plattform als solches unerlässlich. Ich habe sicher keine Kritik an den Firmen geübt, die GNOME-Unterstützen. Allein die Server-Infrastruktur, der Bugzilla und die Wartung vieler Kernmodule ist ein gigantischer Aufwand, auch Beteiligte am befreundeten KDE-Projekt wissen da sicher viel zu berichten.
Große Softwarehäuser, hauptsächlich Red Hat und Novell, zahlen über die Infrastruktur hinaus jeweils ca. 3-5 Vollzeitentwickler (Matthias Clasen, Federico Mena-Quintero, Alexander Larsson etc.), aber auch sowas geht extrem ins Geld; Unternehmer wissen, wovon ich spreche.
Man kann natürlich als Nutzer beliebiges fordern, muss sich aber auch im Klaren darüber sein, dass man keine Ansprüche an eine Person zu stellen hat, die man nicht für das bezahlt was sie tut. Dass Dir Rechte an der Software selbst eingeräumt werden, heißt nicht, dass Dir Verfügungsgewalt und ein Forderungskatalog für die Arbeitszeit oder Freizeit anderer zustehen (wohl aber über Deine Freizeit, und das ist der Punkt ).
Jede Firma, die sich in einem solchen Projekt engagiert, hat auch immer die eigene Produktlinie im Kopf. Das ist per se nicht böse oder verwerflich, führt aber dazu, dass Entwickler auch immer in anderen Projekten als am Desktop selbst gebunden sind, was wiederrum heißt, dass jemand, der ein Feature wünscht, sich selbst dahinerklemmen muss/kann/darf, weil es u.U. für die eine oder andere Firma einfach andere Prioritäten gibt.
Wenn Du Dir einen Entwickler zahlst, ist das etwas anderes. Du wirst ja aber einen Teufel tun und ihn über ein zur Pflege notwändiges Mindestmaß hinaus an etwas arbeiten lassen, was Dir nicht wichtig ist, wenn Probleme die Dir wichtig sind noch nicht gelöst sind.
Beispielsweise hat Red Hat sich dafür eingesetzt, SELinux-Unterstützung für die Plattform zu kriegen, und das ist dann auch prompt in GnomeVFS/Nautilus 2.16 gewandert. Unzählige Verbesserungen an der Plattform wie die Druckunterstützung oder die Cairo-Integration in GTK+, D-Bus etc. wären ohne "Manpower" der großen Unternehmen unmöglich, die ganzen Optimierungen an GTK+ sind auch auf nur durch Unterstützung der Unternehmen möglich, weil eben ein Entwickler ohne Unterstützung i.d. Regel nicMindestmaßht die Zeit (oder das kreative Potenzial, technische Wissen etc.) hat, an langwierigen Lösungen für "große" Probleme zu arbeiten. Ausnahmen bestätigen hier die Regel, im deutschsprachigen Umfeld z.B. Christian Kellner, Sven Neumann oder Tim Janik um nur einige zu nennen - aber wir sind natürlich alle in unserem maximal einbringbaren Zeit- und Energieaufwand begrenzt.
Ich spreche ja gerade davon, dass man sich genau einen irrsinnig nervigen Fehler rauspickt und selbst ausmerzt, und dann die Fehlerkorrektur mit anderen teilt, anstatt passiv die Entwicklung zu verfolgen und sich aus Bequemlichkeit über dies und jenes aufzuregen (z.B. über diverse DND-Bugs).
Das gipfelt dann darin, dass man einen Wettkampf der Plattformen ausruft, und von allen Aktiven fordert sich doch bitteschön daran zu beteiligen, weil ja Plattform X schon um Lichtjahre besser sei als Plattform Y und man sich ja so mit Plattform Y identifiziere, die ja viel besser sei als Plattform Z aber der Feature A und B fehle, und man könne ja als treuer Nutzer auch etwas Engagement erwarten usw..
Aha. Und du glaubst man konnte vorher in Gnome keine Anwendung in einem Terminal starten oder was? Soll ich dir was sagen, wenn ich die Release Notes von KDE lese hab ich auch immer das Gefühl, wow, kann Gnome ja schon ewig, aber dann setzt mein kritischer Verstand ein und sagt: "Moment, du kannst ja gar nicht wissen, was genau gemeint ist, dazu verwendest du KDE zu selten".
Also KDE hatte mit DCOP schon seit Jahren etwas zu D-BUS vergleichbares. Vielleicht hätte dies mal Gnome direkt übernehmen sollen, die fehlenden Funktionen hätte man ja nachrüsten können. Außerdem setzt freedesktop.org keine Standards (freedesktop.org is not a formal standards organization), auch wenn vieles glücklicherweise übernommen wird.
>Also KDE hatte mit DCOP schon seit Jahren etwas zu D-BUS vergleichbares. Vor allem in der Zahl der Abstürze / Sekunde ist dcop ja unschlagbar, weil es aucho so stabil und speichersparend ist wird es auch demnächst ersetzt gell
Bin schon seit einiger Zeit am testen der 2.15-Serie. gnome-vfs benötigt jetzt dbus. Ebenso wie control-center und deskbar-applett. So langsam könnte GNOME dbus in 'platform' mit aufnehmen, ohne DBUS geht da bald gar nix mehr. Bei control-center benötigt man derzeit sogar HAL, auch wenn man "--disable-hal" explizit angibt. Es sei den man ersetzt das sound-capplet mit der Version aus 2.14.2. Unter Slackware-current lassen sich epiphany und yelp nicht kompillieren weil in Slackware per default kein von Gnome akzeptierte Gecko-Engine enthalten ist ('Seamonkey not supported', 'Requires gecko >= 1.8' oder 'Requires GTK+2-enabled gecko-build') Für gnopernicus benötigt man einen patch der im CVS schon seit drei Wochen enthalten ist (und in garnome auch). Da hätte man gnopernicus auch gleich auf 1.1.1 aktualisieren können... Das mit den abstürzen beim Start kenne ich drzeit nur wenn gail auf 1.9 aktualisiert wird. Mit 1.8.11 läufts. Mit Gnome-Session 2.15.4 lassen sich hier die Einstellungen für die Tasten-Wiederholung nicht setzen.
Hab schon den einen oder anderen Bug-Report verschickt (geht ja dank BugBuddy relativ einfach). Hoffe mal die fixes kommen auch in die RC's mit rein... ansonsten läuft GNOME 2.15 ganz ordentlich. Vor allem der GTK+2-GDMgreeter sieht nun endlich etwas flotter aus.
Gnome 2.15/2.16 fühlt sich deutlich besser an als die letzte offizielle Gnome-Version 2.12 aus Slackware 10.1 ;o)
> epiphany und yelp nicht kompillieren weil in Slackware per default kein von Gnome akzeptierte Gecko-Engine enthalten ist Meines Wissens nach wird schon lange empfohlen gegen XUL-Runner zu kompilieren (lauft tut's dann gegen seamonkey)
das --disable-hal nicht funktioniert ist wohl ein bug
die abhängigkeit zu d-bus eher weniger, denn auch in KDE soll DCOP durch DBUS ersetzt werden
> Meines Wissens nach wird schon lange empfohlen gegen XUL-Runner zu kompilieren (lauft tut's dann gegen seamonkey) Davon war mir bisher nichts bekannt, werds dann aber wohl mal testen.
> die abhängigkeit zu d-bus eher weniger, denn auch in KDE soll DCOP durch DBUS ersetzt werden War auch nicht als "Bug" eingestuft und im Gegensatz zu HAL läuft DBUS auch soweit stabil das man es installieren kann. Aber ich denke diese "Abhängigkeit" sollte man deutlicher hervorheben.
>Davon war mir bisher nichts bekannt gnome entwickler sind leider sehr schweigsam ;-( hoffentlich bessert sich das bald wenn mehr leute das livegnome-wiki verwenden.
Auf der gnome seite steht folgendes: "Things to look forward to in GNOME 2.16 include: ... Support for compositing, alpha blending, drop shadows, window transparency and more" http://www.gnome.org/start/2.14/notes/en/rnlookingforward.html
im artikel steht: "Gnome-terminal nutzt nun »echte« Transparenz, wenn diese verfügbar ist."
was genau bedeutet "wenn diese verfügbar ist"? funktioniert echte transparenz bei gnome 2.16 nun out-of-the-box oder muss man sowas wie XGL installieren oder wie muss ich mir das nun vorstellen?
Echte Transparenz bedeutet das nicht die Applikation rumrechnen muss sonder das "anzeigende Medium" sich darum kümmert. Nur diese echte Transparenz ist in der Lage auch bewegte Bilder unterhalb des transparenten Bereichs darzustellen, und nicht etwa nur das Hintergrundbild reinrechnen. Der aktuelle X-Server (X.org oder XFree) ist dazu "out of the box" nicht in der Lage. Meines wissens nach schafft das nicht mal die Composite Extension.
Auf deine Frage: Ja bei Gnome funktioniert es "out of the box", wenn du einen XServer installierst der das kann, wie z.B. XGL.
aber mit XGL kann ich doch das gnome-terminal und alle anderen programme jetzt auch schon "echt" transparent darstellen, oder nicht? mir ist nicht ganz klar, wo dann der unterschied zwischen gnome 2.14 und 2.16 in sachen transparenz ist?
Also ich nutze den gnome-terminal in der Version 2.14.2, und habe keine echte Transparenz. Das soll in dieser Version auch nur mit einem extra Patch gehen, soweit ich weiss.
Bei Gnome 2.16 wird man aber kein XGL benötigen, um echte Transparenz in den Anwendungen und auch Metacity zu haben. Dazu verwendet Gnome dann die "libcm" (cm für compositing), wenn ich mich recht entsinne.
es geht mit x.org (ab 6.8) und einem composite manager (z.b. xcompmgr) dann muss aber auch in der xorg.conf composite angeschalten werden (is per default deaktiviert). mit XGL oder AIGLX funktioniert es auch aber nicht nur
Gnome und KDE, das sind so zwei Dinge, dazu möchte ich einfach mal folgendes anmerken: Es ist einfach sensationell, daß immer, wenn es hier eine Meldung zu Gnome gibt, einige loshechten, um ganz schnell zu betonen, wie überlegen doch KDE ist. Führt das Arbeiten mit KDE zu vermindertem Selbstwertgefühl? Und dann wird immer darauf hingewiesen, wie überlegen doch das kommende KDE4/QT4 sein wird.
Gibt es irgendwo eine Quelle, aus der hervorgeht, wie KDE4 so aussieht? Bei Gnome weiß man ja, wie es weitergeht, bei KDE stehe ich total im Regen.
KDE4 wird halt ganz anders werden als KDE3 - daher ist es schwer zu sagen wie es aussieht. Aber es gibt bereits viele veröffentlichte Vorstellungen, z.B. http://appeal.kde.org, dazu das neue Audiosystem etcetcetc
Von da_sister_from_da_hood am Mo, 17. Juli 2006 um 22:19 #
Er muss sich seinen Bordcomputer mit der KDE vorgestellt haben.... Das ist jetzt aber ein Argument der Verschwörungstheoretiker, die glauben die NASA war nie auf dem Mond. Den mit KotzDesktop an Bord wären die niemals bis zum Mond gekommen.
Mit einer damaligen Konsole schaffte man das sicherlich nicht. War an Bord der Apollo eigentlich ein Kernspeicher mit Ferritringen oder waren das Lochkarten?
Mir ist es wurscht. Ich nutze sowohl Gnome als auch KDE, meine Präferenz ist aber eindeutig KDE. Und nicht weil ich finde, Gnome ist so schlecht, sondern weil ich finde, das KDE vieles einfach simpler und besser löst. Das fängt an vom IRC Support (vergleich mal #gnome und #kde auf freenode), geht hin zu Scripts mit denen ich über ruby und dcop Applikationen bequem starten kann bis hin zu simplen Entscheidungen die mich in Gnome als "PowerUser" einfach stören.
Gnome hat viel mehr Ressourcen als XFCE, aber XFCE hat in letzter Zeit viel mehr an Boden gut machen können, als Gnome gegen KDE.
comrad
Leider ist Die Lib etwas dürfig ausgestattet was die Elemente betrifft. Aber immerhin wird daran gearbeitet. Ich las mal von einer idee das ganze auch für Qt um zu setzen. Ist aber wohl im Sande verlaufen.
ja so ein bullshit gtk und qt sind leider welten auseinander und die elementen haben wirklich gar nichts gemeinsam. GTk ist übrigens in C geschrieben und QT in C++. Da liegen wirklich Welten(!) dazwischen. Die Elemente haben echt sehr wenig gemeinsam, sieh dir allein mal welche Datentypen die glib2 hat und welche das in Qt sind.
Sorry du bekommst verdienst dir echt die Zitrone des Jahres
Außerdem ist der vergleich zwischen gnome und mac os legitim, da OSx genau wie Gnome den user einschränkt und man nur wenige möglichkeiten zur Anpassung hat (außer man installiert diverse Tools unter OSx). Windows/Kde haben da mehr möglichkeiten. Liegt halt auch daran, dass Gnome/OSx beide das gleiche Ziel mit "Einfachheit und Benutzerfreundlichkeit" verfolgen.
Und ja, einige auf freedesktop.org entwickelte Sachen kommen mit KDE4. Das liegt daran, dass KDE generell nicht so die Scheuklappen aufhat, wenn es um Software geht, die nicht von ihnen selbst entwickelt wurde. Außerdem sehe ich nur Vorteile, wenn eine gewisse Basis zusammenentwickelt wird.
Die "Zeichnungslibrary", weiß nicht wie ich es sonst nennen sollte, welche in KDE4 durch Qt4 vorhanden ist heißt Arthur. Diese ist grundsätzlich in der Lage auch andere Backends zum anzeigen zu nutzen, darunter auch Cairo. Es stellt sich nur die Frage nach dem Sinn, immerhin ist Arthur weiter entwickelt als Cairo. Cairo plant sogar erst noch Dinge, die in Arthur schon enthalten sind. Außerdem kann Arthur ebenfalls OpenGL direkt nutzen, was das ganze noch mehr in Frage stellt.
theile
> selbst entwickelt wurde.
sorry aber kde hängt bei freedesktop standards ständig hinterher. Übrigens kann cairo (freedesktop-standard) bereits jetz via glitz (auch freedestop standard) open-gl direkt nutzen. Das tut Cairo auf meinenm System (zenwalk) schon seit fast einem Jahr. Ich kenne keine distro die bisher arthur ausliefert, da es nämlich noch gar nicht fertig ist.
Arthur soll meines wissens nach nur api sein ganz ohne backend
Am meisten vermisse ich bei KDE den mangel für enchant (freedesktop standard) damit könnten kde-programm dann endlich hunspell für die rechtschreibprüfung verwenden und ich müsste nicht immer alle wörterbücher doppelt aspell/hunspell installieren.
Was unbestätigten und bösartigen Gerüchten zufolge damit zusammenhängen könnte, dass Teile dieser sogenannten Standards ihren Ursprung im GNOME-Umfeld haben ;-)
Stichworte: Ximian, FUD, GStreamer, Unterwanderung etc.
Übrigens ist es nicht mal vollständig richtig, KDE unterstützt und nutzt z.B. bereits die Papierkorb-Spezifikation [1] und GNOME nicht.
[1] http://www.freedesktop.org/wiki/Standards_2ftrash_2dspec
Trotzdem ist gnome graphik engine mässig kde haushoch überlegen
Trotzdem ist gnome-graphik-engine mäßig, KDE haushoch überlegen
Na da bin ich aber froh, dass die KDE-Devs ihre Prioritäten richtig setzen. Bugfixing ist sowieso "totally overrated".
Arthur ist in Qt4 enthalten, es läuft jetzt schon und ist für alle Distributionen zu haben. KDE4 wird auf QT4 basieren und daher eben all diese Dinge anbieten können, wenn es fertig ist.
Außerdem weißt freedesktop.org auf seinen Seiten explizit drauf hin, dass sie keine Standards erstellen oder verwalten. Gerade das macht den Erfolg von ihnen aus und sorgt für gute Zusammenarbeit unter den großen DEs. Warten wir doch einfach mal KDE4 ab, Ende des Jahres wird es ja schon die ersten Alphas geben, wie ich gehört habe. Vielleicht kann man dann ja auch hunspell für KDE verwenden.
theile
Experimental backends include OpenGL (through glitz), Quartz, and XCB.
wer cairo gegen glitz compiliert und das macht z.b. zenwalk wie gesagt schon länger, dessen cairo zeichnet auch direkt opengl (falls glx geladen ist)
Es hat dir schon mal jemand versucht zu verklickern, daß KDE Enchant nutzt. Guck beizeiten mal in den Quellcode, Du Blindgänger.
ispell - kann nur englisch
hspell - kann nur hebräisch
aspell - Kann intern immer noch kein Unicode, damit nicht internationalisierungsfähig.
Bildschirm-Rotation: 1.5 Jahre
Anwendungen im Terminal starten: 7 Jahre
Dateirechte rekursiv zu vergeben: 4 Jahre
SElinux REchte setzen: ?
echte Transparenz im Terminal: ? (nicht sicher)
Sitzungs-Verwaltung vollständig: 4 Jahre
Sieht eher so aus als wäre Gnome inzwischen feature-mäßig bei KDE's Stand vor drei Jahren angelangt...
Sollte es wahrscheinlich bald mal wieder testen
Ich habe als GNOME-Entwickler immer Probleme mit derartiger Kritik und fühle mich ziemlich verprellt, wenn ich "wurde aber auch langsam Zeit" zu hören bekomme:
Wir haben massive Probleme eine stabile Entwicklerbasis zu halten und als Vollzeitstudent kann ich auch nicht gerade über Zeitüberschuss klagen. Trotzdem habe ich irgendwie die paar Stunden aufgebracht, um Nautilus eine Sitzungs-Verwaltung zu spendieren. Das sollte denjenigen unter Euch, die sich regelmäßig über ungelöste Probleme und Fehler beschweren Ansporn sein, sich ebenso einzubringen.
Rund 10-20 Entwickler sind dafür verantwortlich, dass Ihr überhaupt signifikante Fortschritte an der Plattform über die letzten Jahre mitverfolgen und kommentieren durftet. Ansonsten hieße es "tote Hose" und "immer druf'", "taugt nix" und "vollkommen veraltet".
Es wäre schön, wenn der Dreisatz Kritik -> Problemanalyse -> Problemlösung von mehr als nur einer Hand voll Beteiligten verinnerlicht werden würde. Gerade freie Software lebt davon, dass einzelne initiativ werden - rührig sind - und sich konstruktiv einbringen.
Ich möchte abschließend darauf hinweisen, dass wir uns vieler Unzulänglichkeiten bewusst sind, aber schlicht nicht die Ressourcen haben, diese zu beheben. Dazu braucht es einfach mehr aktiv Mitwirkende, und nicht journalistisch-akribisch aber vollkommen passiv analysierende und publizierende Beobachter.
Andernfalls wäre es natürlich sehr traurig für einen Desktop, welcher die Benutzer von Windows zu Linux führen soll...
> Arbeit daran leisten. Das müssen doch also mehr als 10-20 Entwickler sein und es sollte daher doch auch eine
> stabile Entwicklerbasis geben...
Dass sich Firmen engagieren ist vollkommen richtig und auch für die Existenz der Plattform als solches unerlässlich. Ich habe sicher keine Kritik an den Firmen geübt, die GNOME-Unterstützen. Allein die Server-Infrastruktur, der Bugzilla und die Wartung vieler Kernmodule ist ein gigantischer Aufwand, auch Beteiligte am befreundeten KDE-Projekt wissen da sicher viel zu berichten.
Große Softwarehäuser, hauptsächlich Red Hat und Novell, zahlen über die Infrastruktur hinaus jeweils ca. 3-5 Vollzeitentwickler (Matthias Clasen, Federico Mena-Quintero, Alexander Larsson etc.), aber auch sowas geht extrem ins Geld; Unternehmer wissen, wovon ich spreche.
Man kann natürlich als Nutzer beliebiges fordern, muss sich aber auch im Klaren darüber sein, dass man keine Ansprüche an eine Person zu stellen hat, die man nicht für das bezahlt was sie tut. Dass Dir Rechte an der Software selbst eingeräumt werden, heißt nicht, dass Dir Verfügungsgewalt und ein Forderungskatalog für die Arbeitszeit oder Freizeit anderer zustehen (wohl aber über Deine Freizeit, und das ist der Punkt ).
Jede Firma, die sich in einem solchen Projekt engagiert, hat auch immer die eigene Produktlinie im Kopf. Das ist per se nicht böse oder verwerflich, führt aber dazu, dass Entwickler auch immer in anderen Projekten als am Desktop selbst gebunden sind, was wiederrum heißt, dass jemand, der ein Feature wünscht, sich selbst dahinerklemmen muss/kann/darf, weil es u.U. für die eine oder andere Firma einfach andere Prioritäten gibt.
Wenn Du Dir einen Entwickler zahlst, ist das etwas anderes. Du wirst ja aber einen Teufel tun und ihn über ein zur Pflege notwändiges Mindestmaß hinaus an etwas arbeiten lassen, was Dir nicht wichtig ist, wenn Probleme die Dir wichtig sind noch nicht gelöst sind.
Beispielsweise hat Red Hat sich dafür eingesetzt, SELinux-Unterstützung für die Plattform zu kriegen, und das ist dann auch prompt in GnomeVFS/Nautilus 2.16 gewandert. Unzählige Verbesserungen an der Plattform wie die Druckunterstützung oder die Cairo-Integration in GTK+, D-Bus etc. wären ohne "Manpower" der großen Unternehmen unmöglich, die ganzen Optimierungen an GTK+ sind auch auf nur durch Unterstützung der Unternehmen möglich, weil eben ein Entwickler ohne Unterstützung i.d. Regel nicMindestmaßht die Zeit (oder das kreative Potenzial, technische Wissen etc.) hat, an langwierigen Lösungen für "große" Probleme zu arbeiten. Ausnahmen bestätigen hier die Regel, im deutschsprachigen Umfeld z.B. Christian Kellner, Sven Neumann oder Tim Janik um nur einige zu nennen - aber wir sind natürlich alle in unserem maximal einbringbaren Zeit- und Energieaufwand begrenzt.
Ich spreche ja gerade davon, dass man sich genau einen irrsinnig nervigen Fehler rauspickt und selbst ausmerzt, und dann die Fehlerkorrektur mit anderen teilt, anstatt passiv die Entwicklung zu verfolgen und sich aus Bequemlichkeit über dies und jenes aufzuregen (z.B. über diverse DND-Bugs).
Das gipfelt dann darin, dass man einen Wettkampf der Plattformen ausruft, und von allen Aktiven fordert sich doch bitteschön daran zu beteiligen, weil ja Plattform X schon um Lichtjahre besser sei als Plattform Y und man sich ja so mit Plattform Y identifiziere, die ja viel besser sei als Plattform Z aber der Feature A und B fehle, und man könne ja als treuer Nutzer auch etwas Engagement erwarten usw..
Vor allem in der Zahl der Abstürze / Sekunde ist dcop ja unschlagbar, weil es aucho so stabil und speichersparend ist wird es auch demnächst ersetzt gell
gnome-vfs benötigt jetzt dbus. Ebenso wie control-center und deskbar-applett. So langsam könnte GNOME dbus in 'platform' mit aufnehmen, ohne DBUS geht da bald gar nix mehr.
Bei control-center benötigt man derzeit sogar HAL, auch wenn man "--disable-hal" explizit angibt. Es sei den man ersetzt das sound-capplet mit der Version aus 2.14.2.
Unter Slackware-current lassen sich epiphany und yelp nicht kompillieren weil in Slackware per default kein von Gnome akzeptierte Gecko-Engine enthalten ist ('Seamonkey not supported', 'Requires gecko >= 1.8' oder 'Requires GTK+2-enabled gecko-build')
Für gnopernicus benötigt man einen patch der im CVS schon seit drei Wochen enthalten ist (und in garnome auch). Da hätte man gnopernicus auch gleich auf 1.1.1 aktualisieren können...
Das mit den abstürzen beim Start kenne ich drzeit nur wenn gail auf 1.9 aktualisiert wird. Mit 1.8.11 läufts. Mit Gnome-Session 2.15.4 lassen sich hier die Einstellungen für die Tasten-Wiederholung nicht setzen.
Hab schon den einen oder anderen Bug-Report verschickt (geht ja dank BugBuddy relativ einfach). Hoffe mal die fixes kommen auch in die RC's mit rein... ansonsten läuft GNOME 2.15 ganz ordentlich. Vor allem der GTK+2-GDMgreeter sieht nun endlich etwas flotter aus.
Gnome 2.15/2.16 fühlt sich deutlich besser an als die letzte offizielle Gnome-Version 2.12 aus Slackware 10.1 ;o)
DV
Meines Wissens nach wird schon lange empfohlen gegen XUL-Runner zu kompilieren (lauft tut's dann gegen seamonkey)
das --disable-hal nicht funktioniert ist wohl ein bug
die abhängigkeit zu d-bus eher weniger, denn auch in KDE soll DCOP durch DBUS ersetzt werden
Davon war mir bisher nichts bekannt, werds dann aber wohl mal testen.
> die abhängigkeit zu d-bus eher weniger, denn auch in KDE soll DCOP durch DBUS ersetzt werden
War auch nicht als "Bug" eingestuft und im Gegensatz zu HAL läuft DBUS auch soweit stabil das man es installieren kann. Aber ich denke diese "Abhängigkeit" sollte man deutlicher hervorheben.
DV
gnome entwickler sind leider sehr schweigsam ;-( hoffentlich bessert sich das bald wenn mehr leute das livegnome-wiki verwenden.
Meines Wissens ist die libbonobo als deprecated markiert. Wird es denn endlich mal möglich gnome ohne zeugs wie libart und audiofile zu kompilieren?
DANKE! Ihr seid gesegnet
"Things to look forward to in GNOME 2.16 include:
...
Support for compositing, alpha blending, drop shadows, window transparency and more"
http://www.gnome.org/start/2.14/notes/en/rnlookingforward.html
im artikel steht: "Gnome-terminal nutzt nun »echte« Transparenz, wenn diese verfügbar ist."
was genau bedeutet "wenn diese verfügbar ist"? funktioniert echte transparenz bei gnome 2.16 nun out-of-the-box oder muss man sowas wie XGL installieren oder wie muss ich mir das nun vorstellen?
Auf deine Frage: Ja bei Gnome funktioniert es "out of the box", wenn du einen XServer installierst der das kann, wie z.B. XGL.
mir ist nicht ganz klar, wo dann der unterschied zwischen gnome 2.14 und 2.16 in sachen transparenz ist?
Bei Gnome 2.16 wird man aber kein XGL benötigen, um echte Transparenz in den Anwendungen und auch Metacity zu haben. Dazu verwendet Gnome dann die "libcm" (cm für compositing), wenn ich mich recht entsinne.
die cairo-clock und der XFCE4-WM machen das mit ganz normalen "composite" auf xorg-6.9. Wozu bitte der ganze schrott?
Aber ich will doch nur mit der Kiste arbeiten... da brauch ich keine hüpfenden, röchelnden oder stöhnenden Mauszeiger...
Allnz kloa?
Spielt Ihr mal mit KDE, ich arbeite derweil weiter...
Gibt es irgendwo eine Quelle, aus der hervorgeht, wie KDE4 so aussieht? Bei Gnome weiß man ja, wie es weitergeht, bei KDE stehe ich total im Regen.
Duck und weg..
Wladimir Iljitsch Lenin
"KDE in seinem Lauf hält weder Ochs noch Esel auf"
E. Honecker
N. Armstrong (Er muss sich seinen Bordcomputer mit der KDE vorgestellt haben....)
Das ist jetzt aber ein Argument der Verschwörungstheoretiker, die glauben die NASA war nie auf dem Mond. Den mit KotzDesktop an Bord wären die niemals bis zum Mond gekommen.
meine Präferenz ist aber eindeutig KDE.
Und nicht weil ich finde, Gnome ist so schlecht, sondern
weil ich finde, das KDE vieles einfach simpler und besser
löst. Das fängt an vom IRC Support (vergleich mal #gnome
und #kde auf freenode), geht hin zu Scripts mit denen
ich über ruby und dcop Applikationen bequem starten kann
bis hin zu simplen Entscheidungen die mich in Gnome
als "PowerUser" einfach stören.
Gnome hat viel mehr Ressourcen als XFCE, aber XFCE hat
in letzter Zeit viel mehr an Boden gut machen können, als
Gnome gegen KDE.
Das ist meine Meinung.