Von Karl Schuessler am Do, 2. August 2007 um 08:50 #
Irgendwie lesen sich selbst die "Features" als Bugfixes ...
Neue Applikationen oder wirklich neue Funktionen bekommt man nur, wenn man auch mono + apps installiert, oder ?
Irgendwie merkt man, dass es bisher erst einmal an der Basisinfrastruktur aufgeräumt wurde, gerade wenn man durch die API doku geht und schon gar nicht mehr weiss, welche der vielen reimplemtierungen man nehmen soll. KDE scheint ja gerade zum 3ten mal aufzuräumen und schiebt die kompatibilitätsklassen in eigene compat libs, das ist schon deutlich übersichtlicher und schlanker.
Du magst schon recht haben, dass sich solche Zusammenfassung leicht falsch verstehen lassen. Aber vergiss nicht, das es hier um Gnome 2.19.6 geht. Die 5 Versionen zuvor hast du gerade nicht berücksichtigt. Des weiteren ist es schon erstaunlich das bei jedem Beitrag über eine Gnome-Testversion, sich über den Mangel an Neuheiten beschwert wird, technisch gesehen Gnome aber jetzt schon auf Höhe eines evt. bald erscheinenen KDE ist. Woher kommen die ganzen Sachen, wenn alles immer nur Bugfix Releases sind? Wer sich wirklich für die Entwicklung interessiert weiß das sich viel geändert hat und sich noch einiges ändert bis zur Final. Hier ein kleiner Einstieg: http://live.gnome.org/RoadMap
> Des weiteren ist es schon erstaunlich das bei jedem > Beitrag über eine Gnome-Testversion, sich über den > Mangel an Neuheiten beschwert wird, technisch gesehen > Gnome aber jetzt schon auf Höhe eines evt. bald > erscheinenen KDE ist. Woher kommen die ganzen Sachen, > wenn alles immer nur Bugfix Releases sind?
Das liegt wohl an der Release-Politik. Gnome Releast nun mal nach einem bestimmten Zeitraum, KDE nachdem eine bestimmte Feature-List abgearbeitet wurde. KDE "teasert" z.B. schon lange Features welche in 4.0 kommen werden, das auch schon zu Zeitpunkten in denen es noch nicht mal eine richtige Alpha-Version gab. Bei Gnome läuft die Entwicklung eher im Hintergrund, was zu einem bestimmten Zeitpunkt fertig ist und für gut befunden wurde kommt in die neue Version. Das hat zur Folge dass es bei KDE kein Problem ist, bei einem neuen Major Release, eine entsprechend lange Feature List aufzuzählen. Dass es bei Gnome in der gleichen Zeit mehrere Releases gegeben hat wird oft "vergessen", damit auch die Tatsache, dass 3 oder 4 mal wenig auch gleich viel oder auch mehr sein kann als einmal viel.
"wird oft "vergessen", damit auch die Tatsache, dass 3 oder 4 mal wenig auch gleich viel oder auch mehr sein kann als einmal viel."
So weit die leere Theorie.
Nun zur vollen Praxis: wir starten, auf demselben Rechner (!), zwei verschiedene X server-Sitzungen, einmal mit dem letzten Gnome, einmal mit dem letzten KDE. Und dann vergleichen wir...
Einfach wenn man sich die Main Features anschaut, die KDE 4.x bringen sollen, nicht mal die 4.0 da soll ja noch einiges fehlen. Da stellt man echt fest, das es dies schon gibt. Aber ich will hier auch gar kein Streit wieder vom Zaun brechen, KDE4 wird sicher cool, und den Konkurrenzkampf wieder ordentlich beleben.
Bei aller Liebe zu Gnome, aber das kann nicht ernst gemeint sein. Verfolge mal zeitnah (am besten auf dot.kde.org) was hinter Phonon, Akonadi, Strigi, Nepomuk, Plasma, Oxygen etc. steckt. Und dann sih dir mal an, was KDE in punkto Netzwerktransparenz schon seit Jahren kann (das du noch immer bei keiner anderen DE inkl. denen von Win und Mac findest). Schau dir an, wie die libs aussehen und wie damit zu arbeiten ist.
KDE hatte und hat noch seinen Nachholbedarf hinsichtlich den HIG, aber technisch war es schon immer das ambitioniertere Projekt. Alles andere zu behaupten ist nun wirklich bodenloser Unsinn.
Von Kaninchenbock am Do, 2. August 2007 um 15:19 #
Phonon -> eine Abstraktion über eine Abstraktion super, wer glaubt wirklich das hier keine Performace flöten geht? (Gnome: gstreamer) Akonadi -> EDS Strigi/Nepumik -> Tracker Plasma -> Compiz mit Screenlets etc. Oxygen -> da sind wieder die tollen Icons, ich kann dazu nur "Tango" sagen (ach ja auch da hat sich ja KDE raus gehalten) Netzwerktranzparenz -> wer versucht denn gerade einen KDE Abklatsch vom NetworkManager zu etablieren?
Von Kevin Krammer am Do, 2. August 2007 um 17:51 #
Phonon -> eine Abstraktion über eine Abstraktion super, wer glaubt wirklich das hier keine Performace flöten geht?
Das Weiterleiten eines C++ Funktionsaufrufs ist wirklich ein ziemlich vernachlässigbarer Einfluss.
D.h. ob ein Programm den Pfad zu einer Audiodatei direkt an die GStreamer API übergibt, oder zuerst an eine Methode in Phonon, die es dann an GStreamer weiterleitet, dürfte die Dauer bis zum Start der Audioausgabe so unwesentlich beeinflussen, dass es nicht merkbar ist. Das Laden der Audiodaten und deren Dekodierung dürfte bei weitem länger dauern.
Akonadi -> EDS
Konzeptionell richtig, praktisch wie D-Bus -> DCOP. Eine neue Implementierung, die aus den Schwachstellen der alten Implementierung gelernt hat. Nicht umsonst besteht seitens der Evolution Entwickler Interesse an Akondai als eine gemeinsamen Datenhaltungsinfrastruktur.
Oxygen -> da sind wieder die tollen Icons, ich kann dazu nur "Tango" sagen
Oxygen ist mehr als nur Icons. Und die Oxygen Icons benutzen die selbe Namenskonvention wie die Tango Icons. Wir Entwickler von freier Desktopsoftware nennen das Shared Specification.
Netzwerktranzparenz -> wer versucht denn gerade einen KDE Abklatsch vom NetworkManager zu etablieren
NetworkManager hat erstens nichts mit Netzwerktransparenz zu tun und zweitens ist NetworkManager (unter Linux) das Default-Netzwerkstatusbackend von Solid.
Von Kaninchenbock am Do, 2. August 2007 um 19:06 #
Das Weiterleiten eines C++ Funktionsaufrufs ist wirklich ein ziemlich vernachlässigbarer Einfluss.
D.h. ob ein Programm den Pfad zu einer Audiodatei direkt an die GStreamer API übergibt, oder zuerst an eine Methode in Phonon, die es dann an GStreamer weiterleitet, dürfte die Dauer bis zum Start der Audioausgabe so unwesentlich beeinflussen, dass es nicht merkbar ist. Das Laden der Audiodaten und deren Dekodierung dürfte bei weitem länger dauern.
Gut dran vorbei geredet, bei allen Vorteilen die Phonon bringen könnte oder nicht, so leicht sollte man sich das leben nicht machen! Die Taktik ist gut, so müssen sie keine ManPower in die Backends stecken und wählen sich dann einfach das beste... imho wäre eine Zusammenarbeit an einem Backend besser gewesen.
Konzeptionell richtig, praktisch wie D-Bus -> DCOP. Eine neue Implementierung, die aus den Schwachstellen der alten Implementierung gelernt hat. Nicht umsonst besteht seitens der Evolution Entwickler Interesse an Akondai als eine gemeinsamen Datenhaltungsinfrastruktur.
Ich habe damit nur sagen wollen, dass es sowas schon seit Jahren gibt. Und man es nicht als Gral der Weisheit def. soll, nur weil man es nicht besser weiß, wie dein Vorredner. Ich hoffe es kommt da zu Codeaustausch... die Vergangenheit lehrte uns leider anderes. Und wenn man sich die Entwicklung um EDS anschaut (MC, DBUS-Port, Tracker ...) glaube ich eher weniger daran.
Oxygen ist mehr als nur Icons. Und die Oxygen Icons benutzen die selbe Namenskonvention wie die Tango Icons. Wir Entwickler von freier Desktopsoftware nennen das Shared Specification.
Du bist doch sehr informiert, dann weißt du was es für Probleme gab, wegen den Specs und das die Einigung auf die Namenskonvention der kleinste Nenner war, und viele unzufrieden waren mit der Zusammenarbeit. Aber auch hier wollte ich nur sagen, das es dies schon gibt!
NetworkManager (unter Linux) das Default-Netzwerkstatusbackend von Solid.
Habe ich was anderes gesagt?
Wir können die Liste ja gerne noch weiter führen... Dolphin, Okular nichts was es nicht schon geben würde. Deswegen versteh ich den ganzen Hype einfach nicht und die Aussagen deines Vorredners schon gar nicht!
Sorry wenn du das falsch verstanden hast, ich wollte nur sagen, das es vergleichbare (sei dahin gestellt ob besser/schlechte) Technologien es bereits gibt und z.T. schon seit Jahren genutzt werden.
Von Kevin Krammer am Fr, 3. August 2007 um 17:26 #
Gut dran vorbei geredet...
Ich bin auf den Einwand eingegangen, Phonon würde Performance kosten. Da wie gesagt weiterhin das Backend die Medienhandhabung macht, ist das nicht der Fall.
Selbst bei der Wahl einer Mediaengine hätte man ein Qt/KDE API Binding gebraucht.
Und ein Binding, das soweit unabhängig sein muss, dass API/ABI Änderungen der zugrunde liegenden Engine keine Auswirkung auf das Binding haben wäre vom Design her auch nicht viel anders ausgefallen. Die Möglichkeit andere Backends benutzen zu können ist quasi ein Bonus.
Ich hoffe es kommt da zu Codeaustausch...
Hoffe ich auch. Erstmal muss sich Akonadi im Einsatz bei KDE beweisen. Wenn das gut klappt ist eine der Möglichkeiten, den Akonadi Server als Projekt bei freedesktop.org zu führen, eventuell auch ein paar der Agents.
Sorry wenn du das falsch verstanden hast, ich wollte nur sagen, das es vergleichbare (sei dahin gestellt ob besser/schlechte) Technologien es bereits gibt und z.T. schon seit Jahren genutzt werden.
Ja, sorry. Ohne die, hmm, gewagte Aussage zu Phonon hätte ich es auch nicht kommentiert
Ich nutze fluxbox, icewm etc.. aber meiner Meinung nach führt KDE die Entwicklung an, nicht Gnome. In ziemlich allen Bereichen! (Bis auf den dcop Ersatz)
Nicht fuer ungut, aber_nicht_jeder_findet_solche_APIs_toll. Da hinkt Gnome 10 Jahre hinter Win/Mac/KDE her. Ich weiß übrigens daß es Bindings für Gnome gibt, das ändert aber nichts dran, daß ich die C-Api von Gnome einfach häßlich finde und ich es für einen fundamentalen Fehler halte, eine Desktop-Umgebung und die dazugehörigen Bibliotheken in C zu schreiben. Solange das so ist, werd ich einen weiten Bogen um Gnome machen, denn ich find sowas einfach unästhetisch.
Versteh deine Haltung nicht ganz! Was hast du dagegen, dass eine C-API existiert? Als DEV suchst du dir eine API aus, C, C++, C#, Python, Java, Ruby, Haskell .... Du hast die Wahl, bei QT und WIN wird das schon schwerer. Ich finde es eher fatal zu wenig Bindungs zu haben, bzw. LowLevel Sprachen zu vernachlässigen.
Versteh deine Haltung nicht ganz! Was hast du dagegen, dass eine C-API existiert?
Ich habe gar nichts gegen eine C-Api. Was mich stört ist daß Gnome in C geschrieben ist. Eine Desktop-Umgebung in C zu schreiben ist einfach keine gute Idee.
Als DEV suchst du dir eine API aus, C, C++, C#, Python, Java, Ruby, Haskell
Die Haskell-Bindings wären wirklich der einzige Grund, mir doch mal GTK anzuschauen.
Du hast die Wahl, bei QT und WIN wird das schon schwerer.
Qt hat auch ziemlich viele Bindings: Java, Python, Ruby, um nur einige zu nennen. Leider kein Haskell, da hast du Recht.
Ich finde es eher fatal zu wenig Bindungs zu haben, bzw. LowLevel Sprachen zu vernachlässigen.
C++ ist zwar nicht unbedingt eine wirklich tolle Sprache, aber den low-level Kram kann man damit mindestens genauso gut wie mit C machen. C++ ist auch nicht langsamer as C (siehe http://shootout.alioth.debian.org/) und zusätzlich ist es objektorientiert, was ich bei GUI-Anwendungen als riesigen Vorteil ansehe.
Einen Vorteil hat GTK: Wenn ich eine Binärdatei erstelle habe ich bei C++ verschiedene ABIs von den verschiedenen g++ versionen. Deswegen muss ich doppeltkompilieren wenn ich z.B. ein universelles Paket erstellen will. Bei GTKmm (GTKs C++ binding) kann ich gtkmm statisch linken (ist auch nur ein Wrapper) und die stabilen C-Libraries nutzen, brauch ich nur einmal kompilieren. C hat durchaus Vorteile. Und dass GNOME in C programmiert ist doch nicht schlimm, als Entwickler kannst du dir ja ein Binding aussuchen. Mein Favorit ist PyGTK zusammen mit Glade 3. PyQT hab ich allerdings noch nicht ausprobiert.
> hasst du'n Tutorial oder sowas, für PyGTK gibt's eins, aber das behandelt PyGlade ja nicht ...?
Wie meinen? Auf der PyGTK Homepage gibt's doch einige Tutorials, die erklären, wie man Glade-Designs lädt?
Im Wesentlichen:
import pygtk import gtk import gtk.glade
und dann an entsprechender Stelle im Programm:
widget_tree = gtk.glade.XML("layout.glade")
Wobei "layout.glade" halt die Datei ist, in der du dein Layout mit Glade gespeichert hast... Die einzelnen Widgets kriegst du dann z.B. mit widget_tree.get_widget("name_des_widgets")
> Einen Vorteil hat GTK: Wenn ich eine Binärdatei erstelle habe ich bei C++ verschiedene ABIs von den verschiedenen g++ versionen.
Das hat nur etwas mit der GCC-Entwicklung zu tun. Die ständigen ABI-Änderungen sind einfach eine Unverschämtheit. Sowas sollte allenfalls bei Major-Releases vorkommen.
Von gnome is people am Do, 2. August 2007 um 14:06 #
haskell? lazyness ist überbwertet, denke ich. (Ausser den take k sort list trick, natürlich) Mir persönlich gefällt eager besser. Und kontrolliertes destructive update ist a must have. Ehrlich, diesen Monad, Arrow, Rational kramm bereitet nur Kopfschmerzen ;-) Vielleicht werde ich eines Tages noch meine Haskell-Lektion lernen. Für mich ist Ocaml the way to go. GTK programming mit ocaml ist so einfach.
Dem kann ich nur zustimmen. Musste letztes Jahr mit GTK# arbeiten und das setzt ja auf gtkmm auf. So einen Mist wie dieses Zeug habe ich noch nicht gesehen. Die API ist einfach nicht objektorientiert, auch wenn jetzt die C-Leute wieder meinen werden, dass es so ist.
Aber was mir generell auffällt bei GTK, ist, dass die Programmierer versuchen ihre Unfähigkeit eine angemessene Sprache (für GUI-Programmierung) zu benutzen durch sinnlosen Einsatz von Design-Patterns zu kompensieren zu versuchen. Anscheinend wollen sie zeigen, wie toll sie doch sind und die Prinzipien der Software-Entwicklung verstanden haben.
Ich habe nichts gegen Design-Patterns, insofern sie sinnvoll eingesetzt werden. Aber wenn ich zig Klassen instanziieren muss, um eine TreeView mit 5 Elementen durch zu iterieren, dann ist da etwas faul. Sicher hat MVC auch seine Berechtigung, aber gerade im Bereich von kleinen Listen und wo das Daten-Modell genau einmal angezeigt wird, sollte man leichtgewichtige Alternativen zur Verfügung stellen.
Und noch besser sind die Scherze, dass man Methoden aufrufen kann, welche laut Dokumentation erlaubt sind und man einfach nicht das gewünschte Ergebnis bekommt. Z.B. die Schriftfarbe eines Buttons konnte ich nicht setzen, obwohl die entsprechende Methode aufgerufen wurde. Im Netz fand ich die Begründung, dass man ein einheitliches Look and Feel haben will und deshalb die Methode wirkungslos ist.
Ähnliches ist ja auch bei KDEPrinter passiert, dass sie eine "private" Methode in CUPS benutzt haben und dadurch mit einmal inkompatibel nach einem CUPS-Update waren, da die Methode entfernt/umbenannt wurde. Im Quellcode von CUPS stand über der Methode ungefähr: "This method is private. Don't use it." Das ist lächerlich. Bei OOP mache ich nicht öffentliche Methode privat und dann kann niemand darauf zu greifen. Ich selbst habe schon einige große Komponenten in C# und JAVA entwickelt und weiß, wie sich Nutzer verhalten. Die lesen nicht erst die Doku. Die schauen in der IDE, welche Methoden sie benutzen dürfen und greifen dann darauf zu.
Und so kann man die Liste, C nicht für solche Aufgaben zu benutzen (fehlende Typsicherheit etc), immer weiter führen. Noch ein kleiner Tipp an die C-Befürworter. Objektorientierte Programme kann man übrigens mit dem Compiler viel besser optimieren, da die Optimierung auf viel höherer Ebene statt findet. Also hört endlich auf, C als ultimative Sprache darzustellen. Sie gehört wirklich nur in den Low-Level Bereich!
Von gnome is people am Do, 2. August 2007 um 17:27 #
Also hört endlich auf, C als ultimative Sprache darzustellen. Sie gehört wirklich nur in den Low-Level Bereich! Das tut auch keiner. Das GTK Tutorial weist sogar explizit darauf hin, dass man C nicht benutzen soll, wenn es vermeidbar wäre. Und Bindings gibt es ja mehr als genug.
Warum entwickeln sie dann in C und nicht in C++? Ich weiß, dass es zur Anfangszeit auf den gcc geschoben wurde, da er in C++ einen Riesen-Overhead erzeugte. Das betraf allerdings auch nur Exceptions, die bis heute in QT/KDE nicht sehr intensiv benutzt werden (leider). Und C++ bietet schon viele Vorteile gegenüber C, die den Programmierer unterstützen und somit die Entwicklung beschleunigen. Also war es doch die Unfähigkeit der Entwickler, einen objekt-orientierten Ansatz zu wählen
Es ist einfach so, dass die GTK und GNOME-Entwickler ein gutes Ziel verfolgen, aber leider auf Grund der technischen Gegebenheiten, die sie nutzen, immer mehr an Boden gegenüber anderen Projekten verlieren. Und die Versuche, das über schicke Themes reinzuholen, helfen da auch nicht weiter. Irgendwann hat auch der letzte Anwender begriffen, dass GNOME hinterhinkt.
Von gnome is people am Do, 2. August 2007 um 18:59 #
Warum entwickeln sie dann in C und nicht in C++ - Wegen Bindings? - Warum C++? Eiffel ist doch objektorienterter oder?
auf Grund der technischen Gegebenheiten, die sie nutzen, immer mehr an Boden gegenüber anderen Projekten verlieren Autsch. Scheint ein Troll zu sein. Schade, ich habe mehr von der Konversation erwartet. Bye.
Ich schätze du bist der Troll, denn du gehst nicht auf seine Argumente ein. Bindings gibt es bei beiden Desktop-Systemen zu genüge, und die Frage ist natürlich berechtigt, warum eine Nicht-Objektorientierte-Sprache bevorzugt wurde, wenn es doch auch Sprachen wie Smalltalk etc gibt.
Am Ende ist GNOME einfach kein guter Entwurf: Themes mögen den reinen Anwender eine schöner Oberfläche zeigen und täuschen, im Hintergrund aber stehen Bibliotheken, die alte Techniken fortführen und mehrfach die gleichen Probleme lösen. Ein typisches Problem bei nicht objektorientierter Programmierung. Was GNOME fehlt ist da einfach ne Linie (und ich rede dabei nicht von Schnee).
>> Und die Versuche, das über schicke Themes reinzuholen, helfen da auch nicht weiter
aha. nur das 99% dieser schicken Themes von der Commnunity und nicht von den Gnome Entwicklern kommen. und wenn du das im Screenshot meinst: das Thema kommt von mir und auch die Icons sind 3rdparty. abgesehen von Clearlooks und dem gnome-icon-theme gibt's von den Gnome Entwicklern keine "schicken" Themes. Das GnomeThemesExtra Packet enthält auch nur 3rdparty Artwork.
mag ja alles sein, aber ich glaube nicht daß dies das Kernthema seines Forumsposts war. Ich denke daß was er meint stimmt schon, woher auch immer die Themes sind. Aus Ingenieurs-Perspektive ist das GTK-Design einfach mal großer Mist und ein häßliches Entlein.
Bei OOP mache ich nicht öffentliche Methode privat und dann kann niemand darauf zu greifen. Ich selbst habe schon einige große Komponenten in C# und JAVA entwickelt und weiß, wie sich Nutzer verhalten. Dann greift man halt über die Reflection-API auf die privaten Methoden zu. Im Übrigen kennen Sprachen wie Python trotz Objektorientierung keine privaten Member.
Von MasterBlaster am Fr, 3. August 2007 um 02:41 #
> Dann greift man halt über die Reflection-API auf die privaten Methoden zu.
Wie kann man nur so murksen? Warum nicht einfach gleich ein Kernel Modul schreiben und damit direkt im Speicher herumwurschteln, aber wer tut so etwas?
Also bezügl. der privaten Methoden & OOP hat dein Vorposter schon recht.
Wie kann man nur so murksen? Warum nicht einfach gleich ein Kernel Modul schreiben und damit direkt im Speicher herumwurschteln, aber wer tut so etwas? Es gibt genug Bibliotheken, die die Reflection-API verwenden, z.B. um ein Objekt zu klonen (inkl. der privaten Attribute). Und wenn man dem Nutzer einer Bibliothek nicht trauen kann, dass er z.B. Konventionen nicht einhält, dass Attribute und Methoden mit _ zu Beginn nicht benutzt werden sollen, dann kann man ihm auch nicht trauen, dass er nicht einfach ein Method.invoke ausführt. Die Interna kennt er ja, da er den Quellcode zur Verfügung hat.
Also bezügl. der privaten Methoden & OOP hat dein Vorposter schon recht. Dann wäre mit Programmiersprachen wie Python OOP unmöglich.
Von MasterBlaster am Fr, 3. August 2007 um 02:35 #
> Musste letztes Jahr mit GTK# arbeiten und das setzt ja auf gtkmm auf. So einen Mist wie dieses Zeug habe ich noch nicht gesehen. > Die API ist einfach nicht objektorientiert, auch wenn jetzt die C-Leute wieder meinen werden, dass es so ist.
Eine Behauptung und wo ist die Argumentation bzw. Beweisführung? Wie wäre es mit einem Beispiel?
Ok, wenn man z.B. in GTK# ein TreeStore füllen will, erzeugt man einen Knoten und bekommt einen Iterator zurückgeliefert. Soweit so gut. Aber wenn ich jetzt den Knoten füllen will, muss ich den Iterator wieder dem Modell übergeben, damit es weiß, wo der Wert gesetzt werden soll. Warum kann man nicht einfach über den Iterator den Wert zuweisen, was viel sinnvoller wäre.
Hier ist der entsprechende Code dafür:
Gtk.TreeStore model = new Gtk.TreeStore(typeof(string), typeof(string)); Gtk.TreeIter iter = model.AppendNode(); model.SetValue(iter, 0, "Wert1"); model.SetValue(iter, 1, "Wert2");
GtkListStore und GtkTreeStore besitzen keine Referenz auf GtkTreeIter. Da GtkTreeIter kein GObject ist, wäre so eine Beziehung sowieso völlig Banane.
Eigentlich ist es ein Problem von Gtk#. Welcher Dödel auf die Idee gekommen ist die C API dort 1:1 nachzubastel... Naja, zum Glück ist es in anderen Sprachbindungen (z.B. Gtkmm und pyGtk) besser gelöst.
Nicht fuer ungut, aber_nicht_jeder_findet_solche_APIs_toll. Da hinkt Gnome 10 Jahre hinter Win/Mac/KDE her. Ich weiß übrigens daß es Bindings für Gnome gibt, das ändert aber nichts dran, daß ich die C-Api von Gnome einfach häßlich finde und ich es für einen fundamentalen Fehler halte, eine Desktop-Umgebung und die dazugehörigen Bibliotheken in C zu schreiben. Solange das so ist, werd ich einen weiten Bogen um Gnome machen, denn ich find sowas einfach unästhetisch.
Dann sei froh, dass du noch nicht mit der WinApi programmiert hast. Seit ich die WinApi kenne halte ich Gtk für eine der schönsten C-APIs
Du magst schon recht haben, dass sich solche Zusammenfassung leicht falsch verstehen lassen.
Du meinst die Aussage dass "Version 2.19.6 richtet sich an Entwickler und sollte von normalen Anwendern nicht eingesetzt werden" sich auf das ganze GNOME bezieht? ;)
Scherz beiseite - wenn ich die KDE sehe mit den vielen neuen Techniken, dann kann GNOME das nicht aufgeholt haben. Man lese sich bitte dazu mal http://commit-digest.org/issues/2007-07-29/ durch, da sieht man wie die Entwicklung bei der KDE wöchentlich zusammengefasst verläuft. Das ist einfach der Wahnsinn! Da passiert wöchentlich leider mehr, als von Zwischenrelease zu Zwischenrelease bei GNOME.
Ich denke die gnome sollten nicht immer ein problem auf das nächste Problem schieben... Wen die ein schlechtes Marketing haben sollten dann sollten sie das ändern... und vor allem!! mehr mit der community zusammenarbeiten --> siehe Kde, da klappts doch auch...
das ging ja voll daneben, gnome arbeitet nicht mit der Community zusammen, ein Witz! KDE ist wohl eher die Mannschaft die bewegt werden muss um Desktop übergreifend an Lösungen zu arbeiten.
Was das Marketing betrifft, mich stört es nicht das es nicht X Seiten gibt wo Gnome gepriesen wird. Und wo jedes neue Icon Theme als der Gral alles Seins geheiligt wird. Als Gnome User bekommst die Änderungen mit der Zeit schon mit, und las DEV weißt du wo du die Infos her bekommst.
Man könnte ihn auch nett darauf hinweisen, das bei der Toolkit Entwicklung + viel Bindings keinerlei Community zum tragen kommt, dann müsste auch Troll einsehen das er murks erzählt.
Als Gnome User bekommst die Änderungen mit der Zeit schon mit, und las DEV weißt du wo du die Infos her bekommst.
Als GNOME-User wirst du bevormundet und bekommst etwas vorgesetzt, als Entwickler biste in einem geschlossenem Zirkel, wo Informationen ausgetauscht werden. Das ist ja wie in der Diktatur des Proletariats und dem Politbüro...
Aber sag doch einfach mal, wo ich die Entwicklung von GNOME zusammengefasst (also ohne x-Blogseiten oder E-Mails lesen, dafür fehlt mir die Zeit) verfolgen kann. Danke.
> und nicht für jedes Tool einzeln die Newsdateien zu lesen.
Musst du auch nicht, es gibt genau 5 davon, welche in die Bereiche Platform, Desktop, Admin, Bindings und Devtools aufgeteilt sind (siehe die News oben). Je nachdem welche Bereiche dich interessieren kannst du diese 0-5 Dateien anschauen.
Wenn du es etwas kompakter haben willst, dann kann ich auch nur auf die Roadmap verweisen. Klar, diese wird nicht zu 100% eingehalten, ist aber die Planung welche im Vorraus gemacht wird, was davon fertig wird kommt in das nächste Release. Sobald feststeht welche Features es genau ins nächste Release schaffen, wird es auch die offiziellen ReleaseNotes geben, in welchem auch mit schönen Screenshots beschrieben wird was neu ist.
das ist doch nur gelaber, bitte nicht auf solch einem Niveau. Niemand bekommt was vorgesetzt, nur weil es nicht in einer GUI zu confen ist. "Geschlossener Zirkel" bitte, bitte, bitte lass doch sowas in Zukunft, wenn du davon keine Ahnung hast.
Von MasterBlaster am Fr, 3. August 2007 um 02:46 #
> Als GNOME-User wirst du bevormundet und bekommst etwas vorgesetzt,
Lieber ein schlanker funktioneller durchdachter Desktop wie Gnome, als ein Versuch einer Eierlegendenwollmilchsau, die einem als Anwender gleich mit Featuritis erschlagen will.
/* Was das Marketing betrifft, mich stört es nicht das es nicht X Seiten gibt wo Gnome gepriesen wird. Und wo jedes neue Icon Theme als der Gral alles Seins geheiligt wird. Als Gnome User bekommst die Änderungen mit der Zeit schon mit, und las DEV weißt du wo du die Infos her bekommst.*/
Du hast die Nat-Miguel connection vergessen, jene Kludgefabrik vom Dienst, die neue Projekte in Serie generiert und Leute darauf aufmerksam macht, die dann aber nicht halten was sie versprechen oder von den Initiatoren schnell auf der Suche nach neuer Publicity verlassen werden, hauptsache man hat alles mit seinen hauseigenen dependencies verseucht und die Leute müssen dann deine kaputten Apis fixen.
Ja er wurde verbessert. Leider ist die Idee mit dem aufklappen in die Hose gegangen, ich kann zumindest mit dem kleinen Dialog nichts anfangen. Weiteres Problem - wenn man ihn aufklappt ist das Fenster so klein das gerade mal 2 Zeilen angezeigt werden...
Gnome/Nautilus hat leider einen Optionen-Allergie, es kommen fast keine gconf-schlüssel mehr hinzu um das Verhalten/Größe anzupassen an meine Vorstellungen. Das ist es was mich am meisten nervt.
1. Hat Nautilus/GNOME keine Optionen-Allergie, sondern hat die besten Einstellungen wurden für dich bereits ausgewählt. Warum sollte es da Optionen geben um die besten Einstellungen rückgängig zu machen?
2. Soll nicht der User Vorstellungen von GNOME haben - die haben die Entwickler. Wenn jeder User eigene Vorstellungen hätte, würde GNOME aussehen wie die KDE...
>> Ja er wurde verbessert. Leider ist die Idee mit dem aufklappen in die Hose gegangen, ich kann zumindest mit dem kleinen Dialog nichts >> anfangen. Weiteres Problem - wenn man ihn aufklappt ist das Fenster so klein das gerade mal 2 Zeilen angezeigt werden...
ich weiss ja nicht wie das bei dir ist, aber bei habe ich den Expander einmal aufgeklappt, wobei sich das Fenster insgesamt vergrößert hat und dieser Status ist auch gespeichrt, dh. es ist jetzt immer offen und groß. Wenn das bei dir nicht klappt dann hat a) den Distributor keine Ahnung b) du hast ne Asbach-Uralt Version von Gnome oder c) du hast keine Ahnung.
Danke für den Screenshot, aber: Könntet ihr beim nächsten mal vielleicht einen shot nehmen, der in etwa den Standardeinstellungen entspricht und nicht so immens gethemed (<- denglish) ist? Man erkennt ja gar nicht mehr, was zu Gnome gehört und was nach persönlichem Geschmack geändert wurde...
danke für den Beitrag. Schöne Zusammenfassung der Änderungen.
Gruß
Mike
Neue Applikationen oder wirklich neue Funktionen bekommt man nur, wenn man auch mono + apps installiert, oder ?
Irgendwie merkt man, dass es bisher erst einmal an der Basisinfrastruktur aufgeräumt wurde, gerade wenn man durch die API doku geht und schon gar nicht mehr weiss, welche der vielen reimplemtierungen man nehmen soll. KDE scheint ja gerade zum 3ten mal aufzuräumen und schiebt die kompatibilitätsklassen in eigene compat libs, das ist schon deutlich übersichtlicher und schlanker.
Des weiteren ist es schon erstaunlich das bei jedem Beitrag über eine Gnome-Testversion, sich über den Mangel an Neuheiten beschwert wird, technisch gesehen Gnome aber jetzt schon auf Höhe eines evt. bald erscheinenen KDE ist. Woher kommen die ganzen Sachen, wenn alles immer nur Bugfix Releases sind?
Wer sich wirklich für die Entwicklung interessiert weiß das sich viel geändert hat und sich noch einiges ändert bis zur Final. Hier ein kleiner Einstieg: http://live.gnome.org/RoadMap
mfg
> Beitrag über eine Gnome-Testversion, sich über den
> Mangel an Neuheiten beschwert wird, technisch gesehen
> Gnome aber jetzt schon auf Höhe eines evt. bald
> erscheinenen KDE ist. Woher kommen die ganzen Sachen,
> wenn alles immer nur Bugfix Releases sind?
Das liegt wohl an der Release-Politik. Gnome Releast nun mal nach einem bestimmten Zeitraum, KDE nachdem eine bestimmte Feature-List abgearbeitet wurde.
KDE "teasert" z.B. schon lange Features welche in 4.0 kommen werden, das auch schon zu Zeitpunkten in denen es noch nicht mal eine richtige Alpha-Version gab. Bei Gnome läuft die Entwicklung eher im Hintergrund, was zu einem bestimmten Zeitpunkt fertig ist und für gut befunden wurde kommt in die neue Version.
Das hat zur Folge dass es bei KDE kein Problem ist, bei einem neuen Major Release, eine entsprechend lange Feature List aufzuzählen. Dass es bei Gnome in der gleichen Zeit mehrere Releases gegeben hat wird oft "vergessen", damit auch die Tatsache, dass 3 oder 4 mal wenig auch gleich viel oder auch mehr sein kann als einmal viel.
So weit die leere Theorie.
Nun zur vollen Praxis: wir starten, auf demselben Rechner (!), zwei verschiedene X server-Sitzungen, einmal mit dem letzten Gnome, einmal mit dem letzten KDE. Und dann vergleichen wir...
...und der Sieger ist:
Nee, soll jeder selbst entscheiden.
BlaBlaBlubb, woher nimmst du die info?
Aber ich will hier auch gar kein Streit wieder vom Zaun brechen, KDE4 wird sicher cool, und den Konkurrenzkampf wieder ordentlich beleben.
mfg
KDE hatte und hat noch seinen Nachholbedarf hinsichtlich den HIG, aber technisch war es schon immer das ambitioniertere Projekt. Alles andere zu behaupten ist nun wirklich bodenloser Unsinn.
Akonadi -> EDS
Strigi/Nepumik -> Tracker
Plasma -> Compiz mit Screenlets etc.
Oxygen -> da sind wieder die tollen Icons, ich kann dazu nur "Tango" sagen (ach ja auch da hat sich ja KDE raus gehalten)
Netzwerktranzparenz -> wer versucht denn gerade einen KDE Abklatsch vom NetworkManager zu etablieren?
bodenloser Unsinn... jaja
Das Weiterleiten eines C++ Funktionsaufrufs ist wirklich ein ziemlich vernachlässigbarer Einfluss.
D.h. ob ein Programm den Pfad zu einer Audiodatei direkt an die GStreamer API übergibt, oder zuerst an eine Methode in Phonon, die es dann an GStreamer weiterleitet, dürfte die Dauer bis zum Start der Audioausgabe so unwesentlich beeinflussen, dass es nicht merkbar ist.
Das Laden der Audiodaten und deren Dekodierung dürfte bei weitem länger dauern.
Akonadi -> EDS
Konzeptionell richtig, praktisch wie D-Bus -> DCOP. Eine neue Implementierung, die aus den Schwachstellen der alten Implementierung gelernt hat.
Nicht umsonst besteht seitens der Evolution Entwickler Interesse an Akondai als eine gemeinsamen Datenhaltungsinfrastruktur.
Oxygen -> da sind wieder die tollen Icons, ich kann dazu nur "Tango" sagen
Oxygen ist mehr als nur Icons. Und die Oxygen Icons benutzen die selbe Namenskonvention wie die Tango Icons.
Wir Entwickler von freier Desktopsoftware nennen das Shared Specification.
Netzwerktranzparenz -> wer versucht denn gerade einen KDE Abklatsch vom NetworkManager zu etablieren
NetworkManager hat erstens nichts mit Netzwerktransparenz zu tun und zweitens ist NetworkManager (unter Linux) das Default-Netzwerkstatusbackend von Solid.
bodenloser Unsinn
Und dazu noch uninformiert!
Das Weiterleiten eines C++ Funktionsaufrufs ist wirklich ein ziemlich vernachlässigbarer Einfluss.
D.h. ob ein Programm den Pfad zu einer Audiodatei direkt an die GStreamer API übergibt, oder zuerst an eine Methode in Phonon, die es dann an GStreamer weiterleitet, dürfte die Dauer bis zum Start der Audioausgabe so unwesentlich beeinflussen, dass es nicht merkbar ist.
Das Laden der Audiodaten und deren Dekodierung dürfte bei weitem länger dauern.
Gut dran vorbei geredet, bei allen Vorteilen die Phonon bringen könnte oder nicht, so leicht sollte man sich das leben nicht machen! Die Taktik ist gut, so müssen sie keine ManPower in die Backends stecken und wählen sich dann einfach das beste... imho wäre eine Zusammenarbeit an einem Backend besser gewesen.
Konzeptionell richtig, praktisch wie D-Bus -> DCOP. Eine neue Implementierung, die aus den Schwachstellen der alten Implementierung gelernt hat.
Nicht umsonst besteht seitens der Evolution Entwickler Interesse an Akondai als eine gemeinsamen Datenhaltungsinfrastruktur.
Ich habe damit nur sagen wollen, dass es sowas schon seit Jahren gibt. Und man es nicht als Gral der Weisheit def. soll, nur weil man es nicht besser weiß, wie dein Vorredner.
Ich hoffe es kommt da zu Codeaustausch... die Vergangenheit lehrte uns leider anderes. Und wenn man sich die Entwicklung um EDS anschaut (MC, DBUS-Port, Tracker ...) glaube ich eher weniger daran.
Oxygen ist mehr als nur Icons. Und die Oxygen Icons benutzen die selbe Namenskonvention wie die Tango Icons.
Wir Entwickler von freier Desktopsoftware nennen das Shared Specification.
Du bist doch sehr informiert, dann weißt du was es für Probleme gab, wegen den Specs und das die Einigung auf die Namenskonvention der kleinste Nenner war, und viele unzufrieden waren mit der Zusammenarbeit.
Aber auch hier wollte ich nur sagen, das es dies schon gibt!
NetworkManager (unter Linux) das Default-Netzwerkstatusbackend von Solid.
Habe ich was anderes gesagt?
Wir können die Liste ja gerne noch weiter führen... Dolphin, Okular nichts was es nicht schon geben würde. Deswegen versteh ich den ganzen Hype einfach nicht und die Aussagen deines Vorredners schon gar nicht!
Sorry wenn du das falsch verstanden hast, ich wollte nur sagen, das es vergleichbare (sei dahin gestellt ob besser/schlechte) Technologien es bereits gibt und z.T. schon seit Jahren genutzt werden.
Ich bin auf den Einwand eingegangen, Phonon würde Performance kosten. Da wie gesagt weiterhin das Backend die Medienhandhabung macht, ist das nicht der Fall.
Selbst bei der Wahl einer Mediaengine hätte man ein Qt/KDE API Binding gebraucht.
Und ein Binding, das soweit unabhängig sein muss, dass API/ABI Änderungen der zugrunde liegenden Engine keine Auswirkung auf das Binding haben wäre vom Design her auch nicht viel anders ausgefallen. Die Möglichkeit andere Backends benutzen zu können ist quasi ein Bonus.
Ich hoffe es kommt da zu Codeaustausch...
Hoffe ich auch. Erstmal muss sich Akonadi im Einsatz bei KDE beweisen. Wenn das gut klappt ist eine der Möglichkeiten, den Akonadi Server als Projekt bei freedesktop.org zu führen, eventuell auch ein paar der Agents.
Sorry wenn du das falsch verstanden hast, ich wollte nur sagen, das es vergleichbare (sei dahin gestellt ob besser/schlechte) Technologien es bereits gibt und z.T. schon seit Jahren genutzt werden.
Ja, sorry. Ohne die, hmm, gewagte Aussage zu Phonon hätte ich es auch nicht kommentiert
aber meiner Meinung nach führt KDE die Entwicklung an, nicht Gnome.
In ziemlich allen Bereichen! (Bis auf den dcop Ersatz)
Bei KDE wird stattdessen immer erstmal die Datei lokal in ein Temp Verzeichnis kopiert.
Das ist Beweis genug, daß Gnome moderner und weiter fortgeschritten ist.
War schon bei den anderen GNOME Release/Roadmap Meldung falsch.
http://www.pro-linux.de/cgi-bin/NB2/nb2.cgi?show.11243.2010.41012110133.
Sollte mir das vielleicht bookmarken
Schlechte Nachricht:
naja noch nicht. Dazu müsste man zumindest ORBit und GnomeVFS überarbeiten
Gute Nachricht:
Gnome 2.20 ist die letzte Gnome-version mit GnomeVFS, ab Version 2.21/2.22 wird das neue GVFS mit geliefert.
Orbit2 wurde doch schon längst durch dbus ersetzt oder?
Ob technisch gesehen Gnome mit KDE mithalten kann, weiß ich nicht. Aber Qt/KDE bietet einfach eine viel schönere API. Ein Beispiel aus der GTK API:
void gtk_text_view_buffer_to_window_coords
(GtkTextView *text_view,
GtkTextWindowType win,
gint buffer_x,
gint buffer_y,
gint *window_x,
gint *window_y);
void gtk_text_view_window_to_buffer_coords
(GtkTextView *text_view,
GtkTextWindowType win,
gint window_x,
gint window_y,
gint *buffer_x,
gint *buffer_y);
Nicht fuer ungut, aber_nicht_jeder_findet_solche_APIs_toll. Da hinkt Gnome 10 Jahre hinter Win/Mac/KDE her. Ich weiß übrigens daß es Bindings für Gnome gibt, das ändert aber nichts dran, daß ich die C-Api von Gnome einfach häßlich finde und ich es für einen fundamentalen Fehler halte, eine Desktop-Umgebung und die dazugehörigen Bibliotheken in C zu schreiben. Solange das so ist, werd ich einen weiten Bogen um Gnome machen, denn ich find sowas einfach unästhetisch.
Was hast du dagegen, dass eine C-API existiert?
Als DEV suchst du dir eine API aus, C, C++, C#, Python, Java, Ruby, Haskell
Du hast die Wahl, bei QT und WIN wird das schon schwerer.
Ich finde es eher fatal zu wenig Bindungs zu haben, bzw. LowLevel Sprachen zu vernachlässigen.
my 2c
Was hast du dagegen, dass eine C-API existiert?
Ich habe gar nichts gegen eine C-Api. Was mich stört ist daß Gnome in C geschrieben ist. Eine Desktop-Umgebung in C zu schreiben ist einfach keine gute Idee.
Als DEV suchst du dir eine API aus, C, C++, C#, Python, Java, Ruby, Haskell
Die Haskell-Bindings wären wirklich der einzige Grund, mir doch mal GTK anzuschauen.
Du hast die Wahl, bei QT und WIN wird das schon schwerer.
Qt hat auch ziemlich viele Bindings: Java, Python, Ruby, um nur einige zu nennen. Leider kein Haskell, da hast du Recht.
Ich finde es eher fatal zu wenig Bindungs zu haben, bzw. LowLevel Sprachen zu vernachlässigen.
C++ ist zwar nicht unbedingt eine wirklich tolle Sprache, aber den low-level Kram kann man damit mindestens genauso gut wie mit C machen. C++ ist auch nicht langsamer as C (siehe http://shootout.alioth.debian.org/) und zusätzlich ist es objektorientiert, was ich bei GUI-Anwendungen als riesigen Vorteil ansehe.
Bei GTKmm (GTKs C++ binding) kann ich gtkmm statisch linken (ist auch nur ein Wrapper) und die stabilen C-Libraries nutzen, brauch ich nur einmal kompilieren. C hat durchaus Vorteile.
Und dass GNOME in C programmiert ist doch nicht schlimm, als Entwickler kannst du dir ja ein Binding aussuchen. Mein Favorit ist PyGTK zusammen mit Glade 3. PyQT hab ich allerdings noch nicht ausprobiert.
hasst du'n Tutorial oder sowas, für PyGTK gibt's eins, aber das behandelt PyGlade ja nicht ...?
Wie meinen? Auf der PyGTK Homepage gibt's doch einige Tutorials, die erklären, wie man Glade-Designs lädt?
Im Wesentlichen:
import pygtk
import gtk
import gtk.glade
und dann an entsprechender Stelle im Programm:
widget_tree = gtk.glade.XML("layout.glade")
Wobei "layout.glade" halt die Datei ist, in der du dein Layout mit Glade gespeichert hast...
Die einzelnen Widgets kriegst du dann z.B. mit widget_tree.get_widget("name_des_widgets")
HTH
CU
Dread_Lord
Das hat nur etwas mit der GCC-Entwicklung zu tun. Die ständigen ABI-Änderungen sind einfach eine Unverschämtheit. Sowas sollte allenfalls bei Major-Releases vorkommen.
Mir persönlich gefällt eager besser. Und kontrolliertes destructive update ist a must have. Ehrlich, diesen Monad, Arrow, Rational kramm bereitet nur Kopfschmerzen ;-)
Vielleicht werde ich eines Tages noch meine Haskell-Lektion lernen.
Für mich ist Ocaml the way to go. GTK programming mit ocaml ist so einfach.
Gibt es eigentlich ein gutes Einführungs-Buch in OCaml? Würde ich mir auch gerne mal anschauen.
Du hast die C++ API noch nicht benutzt sonst hättest du sie hier nicht erwähnt, aus Scham jemand könnte sie ausprobieren
Aber was mir generell auffällt bei GTK, ist, dass die Programmierer versuchen ihre Unfähigkeit eine angemessene Sprache (für GUI-Programmierung) zu benutzen durch sinnlosen Einsatz von Design-Patterns zu kompensieren zu versuchen. Anscheinend wollen sie zeigen, wie toll sie doch sind und die Prinzipien der Software-Entwicklung verstanden haben.
Ich habe nichts gegen Design-Patterns, insofern sie sinnvoll eingesetzt werden. Aber wenn ich zig Klassen instanziieren muss, um eine TreeView mit 5 Elementen durch zu iterieren, dann ist da etwas faul. Sicher hat MVC auch seine Berechtigung, aber gerade im Bereich von kleinen Listen und wo das Daten-Modell genau einmal angezeigt wird, sollte man leichtgewichtige Alternativen zur Verfügung stellen.
Und noch besser sind die Scherze, dass man Methoden aufrufen kann, welche laut Dokumentation erlaubt sind und man einfach nicht das gewünschte Ergebnis bekommt. Z.B. die Schriftfarbe eines Buttons konnte ich nicht setzen, obwohl die entsprechende Methode aufgerufen wurde. Im Netz fand ich die Begründung, dass man ein einheitliches Look and Feel haben will und deshalb die Methode wirkungslos ist.
Ähnliches ist ja auch bei KDEPrinter passiert, dass sie eine "private" Methode in CUPS benutzt haben und dadurch mit einmal inkompatibel nach einem CUPS-Update waren, da die Methode entfernt/umbenannt wurde. Im Quellcode von CUPS stand über der Methode ungefähr: "This method is private. Don't use it." Das ist lächerlich. Bei OOP mache ich nicht öffentliche Methode privat und dann kann niemand darauf zu greifen. Ich selbst habe schon einige große Komponenten in C# und JAVA entwickelt und weiß, wie sich Nutzer verhalten. Die lesen nicht erst die Doku. Die schauen in der IDE, welche Methoden sie benutzen dürfen und greifen dann darauf zu.
Und so kann man die Liste, C nicht für solche Aufgaben zu benutzen (fehlende Typsicherheit etc), immer weiter führen. Noch ein kleiner Tipp an die C-Befürworter. Objektorientierte Programme kann man übrigens mit dem Compiler viel besser optimieren, da die Optimierung auf viel höherer Ebene statt findet. Also hört endlich auf, C als ultimative Sprache darzustellen. Sie gehört wirklich nur in den Low-Level Bereich!
Das tut auch keiner. Das GTK Tutorial weist sogar explizit darauf hin, dass man C nicht benutzen soll, wenn es vermeidbar wäre. Und Bindings gibt es ja mehr als genug.
Es ist einfach so, dass die GTK und GNOME-Entwickler ein gutes Ziel verfolgen, aber leider auf Grund der technischen Gegebenheiten, die sie nutzen, immer mehr an Boden gegenüber anderen Projekten verlieren. Und die Versuche, das über schicke Themes reinzuholen, helfen da auch nicht weiter. Irgendwann hat auch der letzte Anwender begriffen, dass GNOME hinterhinkt.
Warum entwickeln sie dann in C und nicht in C++
- Wegen Bindings?
- Warum C++? Eiffel ist doch objektorienterter oder?
auf Grund der technischen Gegebenheiten, die sie nutzen, immer mehr an Boden gegenüber anderen Projekten verlieren
Autsch. Scheint ein Troll zu sein. Schade, ich habe mehr von der Konversation erwartet. Bye.
Am Ende ist GNOME einfach kein guter Entwurf: Themes mögen den reinen Anwender eine schöner Oberfläche zeigen und täuschen, im Hintergrund aber stehen Bibliotheken, die alte Techniken fortführen und mehrfach die gleichen Probleme lösen. Ein typisches Problem bei nicht objektorientierter Programmierung. Was GNOME fehlt ist da einfach ne Linie (und ich rede dabei nicht von Schnee).
aha. nur das 99% dieser schicken Themes von der Commnunity und nicht von den Gnome Entwicklern kommen. und wenn du das im Screenshot meinst: das Thema kommt von mir und auch die Icons sind 3rdparty. abgesehen von Clearlooks und dem gnome-icon-theme gibt's von den Gnome Entwicklern keine "schicken" Themes. Das GnomeThemesExtra Packet enthält auch nur 3rdparty Artwork.
mag ja alles sein, aber ich glaube nicht daß dies das Kernthema seines Forumsposts war. Ich denke daß was er meint stimmt schon, woher auch immer die Themes sind. Aus Ingenieurs-Perspektive ist das GTK-Design einfach mal großer Mist und ein häßliches Entlein.
Dann greift man halt über die Reflection-API auf die privaten Methoden zu. Im Übrigen kennen Sprachen wie Python trotz Objektorientierung keine privaten Member.
Wie kann man nur so murksen?
Warum nicht einfach gleich ein Kernel Modul schreiben und damit direkt im Speicher herumwurschteln, aber wer tut so etwas?
Also bezügl. der privaten Methoden & OOP hat dein Vorposter schon recht.
Und Reflection-API bäh.
Es gibt genug Bibliotheken, die die Reflection-API verwenden, z.B. um ein Objekt zu klonen (inkl. der privaten Attribute).
Und wenn man dem Nutzer einer Bibliothek nicht trauen kann, dass er z.B. Konventionen nicht einhält, dass Attribute und Methoden mit _ zu Beginn nicht benutzt werden sollen, dann kann man ihm auch nicht trauen, dass er nicht einfach ein Method.invoke ausführt. Die Interna kennt er ja, da er den Quellcode zur Verfügung hat.
Also bezügl. der privaten Methoden & OOP hat dein Vorposter schon recht.
Dann wäre mit Programmiersprachen wie Python OOP unmöglich.
> Die API ist einfach nicht objektorientiert, auch wenn jetzt die C-Leute wieder meinen werden, dass es so ist.
Eine Behauptung und wo ist die Argumentation bzw. Beweisführung?
Wie wäre es mit einem Beispiel?
Hier ist der entsprechende Code dafür:
Gtk.TreeStore model = new Gtk.TreeStore(typeof(string), typeof(string));
Gtk.TreeIter iter = model.AppendNode();
model.SetValue(iter, 0, "Wert1");
model.SetValue(iter, 1, "Wert2");
iter.SetValue(0, "Wert1");
dann müsste iter intern eine Referenz auf model halten. Da model auch eine Referenz auf iter hat, haben wir cyclic dependencies. Schön ist es nicht.
Eigentlich ist es ein Problem von Gtk#. Welcher Dödel auf die Idee gekommen ist die C API dort 1:1 nachzubastel...
Naja, zum Glück ist es in anderen Sprachbindungen (z.B. Gtkmm und pyGtk) besser gelöst.
Dann sei froh, dass du noch nicht mit der WinApi programmiert hast. Seit ich die WinApi kenne halte ich Gtk für eine der schönsten C-APIs
Du meinst die Aussage dass "Version 2.19.6 richtet sich an Entwickler und sollte von normalen Anwendern nicht eingesetzt werden" sich auf das ganze GNOME bezieht? ;)
Scherz beiseite - wenn ich die KDE sehe mit den vielen neuen Techniken, dann kann GNOME das nicht aufgeholt haben. Man lese sich bitte dazu mal http://commit-digest.org/issues/2007-07-29/ durch, da sieht man wie die Entwicklung bei der KDE wöchentlich zusammengefasst verläuft. Das ist einfach der Wahnsinn! Da passiert wöchentlich leider mehr, als von Zwischenrelease zu Zwischenrelease bei GNOME.
dann sollten sie das ändern... und vor allem!! mehr mit der community zusammenarbeiten --> siehe Kde, da klappts doch auch...
das ging ja voll daneben, gnome arbeitet nicht mit der Community zusammen, ein Witz!
KDE ist wohl eher die Mannschaft die bewegt werden muss um Desktop übergreifend an Lösungen zu arbeiten.
Was das Marketing betrifft, mich stört es nicht das es nicht X Seiten gibt wo Gnome gepriesen wird. Und wo jedes neue Icon Theme als der Gral alles Seins geheiligt wird.
Als Gnome User bekommst die Änderungen mit der Zeit schon mit, und las DEV weißt du wo du die Infos her bekommst.
mfg
Als GNOME-User wirst du bevormundet und bekommst etwas vorgesetzt, als Entwickler biste in einem geschlossenem Zirkel, wo Informationen ausgetauscht werden. Das ist ja wie in der Diktatur des Proletariats und dem Politbüro...
Aber sag doch einfach mal, wo ich die Entwicklung von GNOME zusammengefasst (also ohne x-Blogseiten oder E-Mails lesen, dafür fehlt mir die Zeit) verfolgen kann. Danke.
NEWS Dateien.
ProLinux.
Ist Wunschdenken.
NEWS Dateien
Ich würde es begrüßen, an einer Stelle das Projekt verfolgen zu können - und nicht für jedes Tool einzeln die Newsdateien zu lesen.
ProLinux
Schreibt häufig auch nur Hinweise wie "zahlreiche Bugfixes/Verbesserungen und neue Features wurden hinzugefügt".
Die Roadmap ist ok wie sie ist. Ansonsten planet.gnome.org.
Musst du auch nicht, es gibt genau 5 davon, welche in die Bereiche Platform, Desktop, Admin, Bindings und Devtools aufgeteilt sind (siehe die News oben). Je nachdem welche Bereiche dich interessieren kannst du diese 0-5 Dateien anschauen.
Wenn du es etwas kompakter haben willst, dann kann ich auch nur auf die Roadmap verweisen. Klar, diese wird nicht zu 100% eingehalten, ist aber die Planung welche im Vorraus gemacht wird, was davon fertig wird kommt in das nächste Release. Sobald feststeht welche Features es genau ins nächste Release schaffen, wird es auch die offiziellen ReleaseNotes geben, in welchem auch mit schönen Screenshots beschrieben wird was neu ist.
das ist doch nur gelaber, bitte nicht auf solch einem Niveau. Niemand bekommt was vorgesetzt, nur weil es nicht in einer GUI zu confen ist. "Geschlossener Zirkel" bitte, bitte, bitte lass doch sowas in Zukunft, wenn du davon keine Ahnung hast.
Danke.
Lieber ein schlanker funktioneller durchdachter Desktop wie Gnome, als ein Versuch einer Eierlegendenwollmilchsau,
die einem als Anwender gleich mit Featuritis erschlagen will.
Als Gnome User bekommst die Änderungen mit der Zeit schon mit, und las DEV weißt du wo du die Infos her bekommst.*/
Du hast die Nat-Miguel connection vergessen, jene Kludgefabrik vom Dienst, die neue Projekte in Serie generiert und Leute darauf aufmerksam macht, die dann aber nicht halten was sie versprechen oder von den Initiatoren schnell auf der Suche nach neuer Publicity verlassen werden, hauptsache man hat alles mit seinen hauseigenen dependencies verseucht und die Leute müssen dann deine kaputten Apis fixen.
Gnome/Nautilus hat leider einen Optionen-Allergie, es kommen fast keine gconf-schlüssel mehr hinzu um das Verhalten/Größe anzupassen an meine Vorstellungen. Das ist es was mich am meisten nervt.
1. Hat Nautilus/GNOME keine Optionen-Allergie, sondern hat die besten Einstellungen wurden für dich bereits ausgewählt. Warum sollte es da Optionen geben um die besten Einstellungen rückgängig zu machen?
2. Soll nicht der User Vorstellungen von GNOME haben - die haben die Entwickler. Wenn jeder User eigene Vorstellungen hätte, würde GNOME aussehen wie die KDE...
>> anfangen. Weiteres Problem - wenn man ihn aufklappt ist das Fenster so klein das gerade mal 2 Zeilen angezeigt werden...
ich weiss ja nicht wie das bei dir ist, aber bei habe ich den Expander einmal aufgeklappt, wobei sich das Fenster insgesamt vergrößert hat und dieser Status ist auch gespeichrt, dh. es ist jetzt immer offen und groß. Wenn das bei dir nicht klappt dann hat a) den Distributor keine Ahnung b) du hast ne Asbach-Uralt Version von Gnome oder c) du hast keine Ahnung.
Dieses finde ich nämlich grauenhaft.