Login
Newsletter
Werbung

Thema: GNOME 2.19.6 erschienen

16 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von em am Do, 2. August 2007 um 15:33 #
> Als DEV suchst du dir eine API aus, C, C++, C#, Python, Java, Ruby, Haskell:)

Du hast die C++ API noch nicht benutzt sonst hättest du sie hier nicht erwähnt, aus Scham jemand könnte sie ausprobieren ;)

[
| Versenden | Drucken ]
  • 0
    Von tom am Do, 2. August 2007 um 16:12 #
    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!

    [
    | Versenden | Drucken ]
    • 0
      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.
      [
      | Versenden | Drucken ]
      • 0
        Von tom am Do, 2. August 2007 um 18:30 #
        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.

        [
        | Versenden | Drucken ]
        • 0
          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.

          [
          | Versenden | Drucken ]
          • 0
            Von vicbrother am Do, 2. August 2007 um 19:59 #
            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).

            [
            | Versenden | Drucken ]
          0
          Von NANO am Do, 2. August 2007 um 19:01 #
          >> 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.

          [
          | Versenden | Drucken ]
          • 0
            Von em am Fr, 3. August 2007 um 10:55 #
            NANO,

            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.

            [
            | Versenden | Drucken ]
      0
      Von fuffy am Do, 2. August 2007 um 19:39 #
      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.
      [
      | Versenden | Drucken ]
      • 0
        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.

        Und Reflection-API bäh.


        [
        | Versenden | Drucken ]
        • 0
          Von fuffy am Fr, 3. August 2007 um 08:34 #
          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.

          [
          | Versenden | Drucken ]
      0
      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?

      [
      | Versenden | Drucken ]
      • 0
        Von tom am Fr, 3. August 2007 um 06:02 #
        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");

        [
        | Versenden | Drucken ]
        • 0
          Von gnome is people am Fr, 3. August 2007 um 13:25 #
          Meinst du das
          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.

          [
          | Versenden | Drucken ]
          • 0
            Von Volker am Fr, 3. August 2007 um 13:48 #
            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.

            [
            | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung