Login
Newsletter
Werbung

Thema: Aktueller Status von Mono

75 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von pinky am Mo, 21. November 2005 um 13:56 #
Ich habe 3 wünsche an zukünftige Mono Versionen:
1. hoffe ich, dass es Gtk# bald zu den "GNOME Platform Bindings" schafft, so dass es in Zukunft zeitnahe und aktuelle Gtk# bindings gibt.
2. native Gtk# auf MacOSX. Momentan scheint die einzige GUI-Konstante zwischen windows-MacOS-unix window.forms zu sein. Da man aber auch bei Novell (richtiger weise) auf Gtk# setzt wäre es wichtig, dass der Mono installer auf allen Platformen alles mitbringt um GUI (Gtk#) Anwendungen aus zu führen.
3. crossplatform internationalisierung von GUI (gtk#, glade#) anwendungen. Unter unix verwendet man ja gettext&Co. Aber das funktioniert nicht out-of-the-box unter windows und MacOS. Entweder man kann das irgendwie in das Mono-bundle integrieren oder man sollte nach einer anderen Lösung ausschau halten.

Hoffe diese drei Punkte werden in Zukunft gelöst bzw. wurden vielleich sogar schon gelöst...

[
| Versenden | Drucken ]
  • 0
    Von sven am Mo, 21. November 2005 um 14:14 #
    mach doch mal eben fertig ;-)
    [
    | Versenden | Drucken ]
    0
    Von Arnomane am Mo, 21. November 2005 um 14:22 #
    Ähem. Kleine Korrektur. Es gibt da schon seit längerem (sprich lange bevor GTK+/GTK# in entsprechenden Versionen existierte) eine native "GUI-Konstante" für Windows, X11 und OSX: Sie heißt Qt. Seit der Version 4.0 ist das Toolkit Qt für alle drei Grafiksysteme auch unter der GPL verfügbar (davor bis zur Version 3.x nur für X11 und OSX unter GPL und für Windows auschließlich proprietär).

    Ich will dem Monoprojekt nicht seine Wichtigkeit absprechen (im Grunde ist die Kritik diesselbe wie gegen das mittlerweile mehr als akzeptierte Wine), aber ich würde mich doch freuen, wenn einige Mono/GTK/Gnome-Wortführer doch ab und zu ein wenig bescheidener auftreten und lieber die Qualität ihres Codes still für sich sprechen lassen und nicht jeden ihrer oft leider noch nichtmal als nutzbare Version existierenden Ansätze bei jeder Gelegenheit als die größte Erfindung seit Brot in Scheiben feiern (einige Beispiele der GTK+ Welt die zurecht ein Erfolg sind also als solche gebührend gefeiert werden können sind bspw. Gimp und Inkscape und nein OpenOffice und Firefox zählen nicht dazu ;-) ).

    [
    | Versenden | Drucken ]
    • 0
      Von fuffy am Mo, 21. November 2005 um 14:42 #
      | Es gibt da schon seit längerem (sprich lange bevor GTK+/GTK# in entsprechenden Versionen existierte) eine native "GUI-Konstante" für Windows, X11 und OSX: Sie heißt Qt.
      Dass eine Qt-Anwendung ohne Neukompilation auf allen Plattformen läuft, ist mir neu. Windows kann also mit ELF umgehen? ;-)

      Wieso zählen OpenOffice.org und Firefox nicht dazu? Ihre "Wrapper" greifen schließlich auch auf Gtk+ zu. Sie hätten ja was eigenes nehmen können.

      [
      | Versenden | Drucken ]
      • 0
        Von Arnomane am Mo, 21. November 2005 um 15:22 #
        Kennst du Lyx? Würdest du Lyx als Qt-Anwendung einstufen? Nach deiner Logik wäre das der Fall, da Lyx mittlerweile fast ausschließlich mit Qt genutzt wird. Lyx gab es lange Zeit nur für XForms. Da es vom Begründer von Lyx (Mathias Ettrich, der auch KDE als freie Antwort auf CDE initialisiert hat) bereits einmal auf KDE portiert worden war (in einem Klyx genannten Fork) entschied man sich im Interesse aller Lyx-Nutzer Lyx in Zukunft eine Art Wrapper zu spendieren, der verschiedene Toolkits nutzen kann. Im Moment sind es XForms und Qt, die Arbeit am GTK-Backend ist bereits weit fortgeschritten und ist hoffentlich bald abgeschlossen.

        Also dann schauen wir unter diesem Vorzeichen uns Mozilla/Firefox an. Mozilla hat einen Wrapper, der unter Windows kein GTK nutzt und unter Linux auf GTK setzt, gleichwohl ein instabiles Qt-Backend existiert (etwa dem GTK-Backend von Lyx gleichzusetzen). Das es keine echte GTK-Anwendung ist erkennt man auch daran, dass er nicht die üblichen GTK-GUI-Elemente benutzt und sich auch sonst im Stil von GTK-Anwendungen unterscheidet.

        So und nun zu OpenOffice. In der Version 1.x wird ein komplett selbst gestricktes Toolkit genutzt was rein garnichts mit GTK oder Qt zu tun hat. Ab der Version 2.0 hat man sich für einen Wrapper entschieden für den technisch gleichwertige Backends für Qt/KDE wie GTK/Gnome existieren. Das OpenOffice-Projekt, welches dieses ermöglichte nennt sich Native-Framework-Project. Und ja OpenOffice 2.0 läuft bei mir auf Qt und nutzt KDE-Dialoge.

        Alle drei genannten Projekte verwenden deshalb Wrapper, weil deren frühere Insellösungen technisch vielen nicht mehr genügten. Alle drei Projekte sind vollkommen unabhängig von und vor den Toolkits entstanden, die sie jetzt auch alternativ nutzen können, aber nicht müssen und betonen auch weiterhin ihre Nichtbindung an ein bestimmtes Toolkit und sind deshalb auch vollkommen eigenständige Projekte die nicht den Stilvorschriften eines bestimmten Desktops folgen, sondern im Falle von OpenOffice und Mozilla/Firefox folgerichtig eigene Entitäten im Rahmen des Freedesktop.org-Projekts sind.

        [
        | Versenden | Drucken ]
        • 0
          Von fuffy am Mo, 21. November 2005 um 16:16 #
          So und nun zu OpenOffice. In der Version 1.x wird ein komplett selbst gestricktes Toolkit genutzt was rein garnichts mit GTK oder Qt zu tun hat.
          Dann kann man ja libgtk* ruhig löschen und OpenOffice.org läuft weiter.

          Ab der Version 2.0 hat man sich für einen Wrapper entschieden für den technisch gleichwertige Backends für Qt/KDE wie GTK/Gnome existieren. Das OpenOffice-Projekt, welches dieses ermöglichte nennt sich Native-Framework-Project. Und ja OpenOffice 2.0 läuft bei mir auf Qt und nutzt KDE-Dialoge.
          Ja siehst du, bei dir ist OpenOffice.org eine Anwendung, die Qt nutzt, so wie sie bei manch anderem Gtk+ oder GDI nutzt. Davon, dass OpenOffice.org eine reinrassige Gtk+-Anwendung wäre, hab ich nie gesprochen. OpenOffice.org nutzt Gtk+, je nach Konfiguration, aber baut nicht drauf auf. Davon war aber nicht die Rede. Anderenfalls reden wir aneinander vorbei.

          Alle drei genannten Projekte verwenden deshalb Wrapper, weil deren frühere Insellösungen technisch vielen nicht mehr genügten. Alle drei Projekte sind vollkommen unabhängig von und vor den Toolkits entstanden, die sie jetzt auch alternativ nutzen können, aber nicht müssen und betonen auch weiterhin ihre Nichtbindung an ein bestimmtes Toolkit und sind deshalb auch vollkommen eigenständige Projekte die nicht den Stilvorschriften eines bestimmten Desktops folgen, sondern im Falle von OpenOffice und Mozilla/Firefox folgerichtig eigene Entitäten im Rahmen des Freedesktop.org-Projekts sind.
          Also integriert sich OpenOffice.org 2.0 von Look & Feel weder in Win32, noch in GNOME oder KDE, oder was willst du damit aussagen?

          [
          | Versenden | Drucken ]
          • 0
            Von Arnomane am Mo, 21. November 2005 um 16:35 #
            Ich habe keine Lust mich zu streiten. Ich bin eigentlich immer bemüht meine Aussagen sorgfältig zu begründen und halte auch nicht viel von Toolkit/Desktop-Bashing (Einfach weil ich das nutze, was für mich am besten funktioniert und das ist eine bunte Mischung), aber mich ärgert es, dass einige verdiente Open-Source-Protagonisten meinen sie müssten in der Aufmerksamkeitsökonomie des Internets auf Kosten anderer Open-Source-Protagonisten, die vielleicht sogar mal eine bessere Lösung als sie haben, permanent ihr Ego streicheln oder sich gar mit fremden Federn schmücken wollen, anstatt einfach mal nur ihre eigenen Leistungen die auch beeindruckend sind für sich sprechen zu lassen.

            Du hast mich gefragt, warum Mozilla und OpenOffice keine Anwendungen sind auf die GTK/Gnome als GTK-Anwendung und somit "eigene Babies" stolz sein könnte und ich habe es denke ich doch sehr gut begründet. Mir dann Tautologie vorzuwerfen ärgert mich ehrlich gesagt.

            Ansonsten würde ich dich doch bitten mal genauer zu lesen. Wo habe ich gesagt dass OpenOffice sich nun nirgendwo mehr integriert? Eine der Highlights an OpenOffice 2.0 ist ja gerade, das es sich nun in KDE und Gnome gleichermaßen integriert (auch wenn man da immer noch eine Menge dran feilen kann), aber eben nicht eben mal so in seiner kompletten Ausrichtung einem Desktop folgt und durchaus immer noch eigene Wege geht, wo man noch keine Lösung gefunden hat wie man verschiedene Konzepte unter einen Hut bringt.

            [
            | Versenden | Drucken ]
            • 0
              Von fuffy am Mo, 21. November 2005 um 16:46 #
              Du hast mich gefragt, warum Mozilla und OpenOffice keine Anwendungen sind auf die GTK/Gnome als GTK-Anwendung und somit "eigene Babies" stolz sein könnte und ich habe es denke ich doch sehr gut begründet.
              Dann war es ein Missverständnis. Das ist natürlich klar, zumal ich selbst NeroLinux nicht als "Gtk+-Baby" bezeichnen könnte, obwohl es wirklich auf Gtk+ aufsetzt.

              Wo habe ich gesagt dass OpenOffice sich nun nirgendwo mehr integriert? Eine der Highlights an OpenOffice 2.0 ist ja gerade, das es sich nun in KDE und Gnome gleichermaßen integriert (auch wenn man da immer noch eine Menge dran feilen kann), aber eben nicht eben mal so in seiner kompletten Ausrichtung einem Desktop folgt und durchaus immer noch eigene Wege geht, wo man noch keine Lösung gefunden hat wie man verschiedene Konzepte unter einen Hut bringt.
              Das war meine Schlussfolgerung aus deiner Aussage, dass OpenOffice.org bei freedesktop.org extra aufgeführt wird, was einen annehmen lässt, dass OpenOffice.org 2.0 ein eigenes Look & Feel wäre, wobei es eher zu KDE und GNOME gehört, was das Look & Feel angeht.

              [
              | Versenden | Drucken ]
              0
              Von Jens am Mo, 21. November 2005 um 18:16 #
              Moin!

              > ... Tautologie ...

              Man(n), gut das die Welt Wikipedia erfunden hat! ;)

              - Jens

              [
              | Versenden | Drucken ]
              0
              Von neo am Mo, 21. November 2005 um 18:52 #
              Mozilla & OpenOffice sind vielleicht keine "Babies" von GNOME, aber sie arbeiten mit dem GNOME-Projekt wesentlich enger zusammen als mit KDE, ob es den KDElern gefällt oder nicht.
              [
              | Versenden | Drucken ]
              • 0
                Von Arnomane am Di, 22. November 2005 um 01:29 #
                Also deine Aussage impliziert irgendwie, als wäre es die Schuld von KDE, dass sie sich nicht genug darum gekümmert hätten. Um mal so kurz in die Runde einzustreuen: Es ist leider nicht so leicht bei Mozilla oder OpenOffice als jemand der eine optionale (!) Integration in KDE vorantreiben möchte CVS-Zugang zu bekommen.

                Ansonsten ist die Aussage, dass die beiden genannten Projekte irgendwie enger mit Gnome zusammenarbeiten auch nicht ganz richtig. Dank einiger eifriger Enthusiasten aus der KDE-Welt, die einfach mal Code statt heißer Luft geliefert haben, arbeitet OpenOffice 2.0 nun mindestens genauso eng mit KDE wie mit Gnome zusammen. Bei Mozilla gibt es da den Gecko als KPart in Konqueror statt KHTML. Der Code ist da nur zierte man sich bei Mozilla wie eine alte Jungfer einfach mal unbürokratisch allen Leuten, die diesen interessanten Code beigesteuert haben, nen CVS-Account zu geben. Das war sicher nicht gerade eben dem Engagement der Leute, die die KDE-Integration von Mozilla vorantreiben, zuträglich.

                In beiden Fällen gab es nachweislich eine ablehnende Haltung einiger Beteiligter der beiden Projekte allen Dingen gegenüber, die etwas mit Qt/KDE zu tun hatten, was erstmal mit viel Geduld und vor allem durch gute Arbeit die für sich sprach durchbrochen werden musste. Ich hoffe, derartige Fehler, die eindeutig nicht auf KDE-Seite lagen, können in Zukunft vermieden werden.

                [
                | Versenden | Drucken ]
                • 0
                  Von Horst am Di, 22. November 2005 um 08:56 #
                  > Also deine Aussage impliziert irgendwie, als wäre es die Schuld von KDE, dass sie sich nicht genug darum gekümmert hätten.

                  Man kann auch zu viel hinein interpretieren. Sorry, aber das ist Stuss.

                  GTK/GNOME geht es übrigens bei diesen Projekten auch nicht zwangsläufig besser. Die Epiphany Entwickler - die 'ne Menge mit dem Mozilla Code zu tun haben - bekommen so weit ich noch aktuell bin auch keinen eigenen CVS Account und müssen warten bis die Mozilla Entwickler die Bugs gefixed haben. Aber vielleicht ist das auch das Problem, eventuell wollen die KDE Entwickler immer zu viele Rechte und wollen sich in zu viele Dinge zu weit rein hängen? :-)

                  Dass Openoffice GNOME etwas bevorzugt behandelt(e) liegt wohl daran, dass Openoffice immernoch von SUN gesponsort ist. Den Rest brauch ich glaub ich nicht zu erläutern.

                  [
                  | Versenden | Drucken ]
                  • 0
                    Von fuffy am Di, 22. November 2005 um 09:38 #
                    | Dass Openoffice GNOME etwas bevorzugt behandelt(e) liegt wohl daran, dass Openoffice immernoch von SUN gesponsort ist.
                    Gesponsort würde ich nicht sagen. Eher dass die Anwendung zum Großteil von Sun entwickelt wurde, was ja nochmal ne Steigerung ist.
                    [
                    | Versenden | Drucken ]
                    0
                    Von cm am Di, 22. November 2005 um 09:54 #
                    > Aber vielleicht ist das auch das Problem, eventuell wollen die KDE Entwickler
                    > immer zu viele Rechte und wollen sich in zu viele Dinge zu weit rein hängen?:-)

                    Nein.


                    > Dass Openoffice GNOME etwas bevorzugt behandelt(e) liegt wohl daran, dass Openoffice
                    > immernoch von SUN gesponsort ist. Den Rest brauch ich glaub ich nicht zu erläutern.

                    Das klingt dagegen plausibel. SUN wird sich jedenfalls nicht selbst um KDE-Unterstützung kümmern.

                    Wobei... wie sieht denn die GNOME-Unterstützung in OOo eigentlich aus? Dass OOo GTK als Toolkit verwenden kann, meine ich damit jetzt nicht.

                    [
                    | Versenden | Drucken ]
        0
        Von Arnomane am Mo, 21. November 2005 um 15:56 #
        Ansonsten zu deiner Bemerkung mit ELF. Mono nutzt wie Java bekanntlich in der Hauptsache eine Virtual Machine und ist auf jeder Plattform ohne Neukomplilation lauffähig. Aber der Clou an GTK# ist gerade, dass es zwar von Anwendungen genutzt werden kann die nicht neukompiliert werden müssen, aber das GTK/GTK# auf jeder Plattform selber schon wie die Virtual Machine kompiliert werden muss. Dies hat einen gewaltigen Integrations- und Performancevorteil, wenn man es mal mit Swing von Java vergleicht.

        Qt geht nun in der Philosphie große Performance und Integration ohne Neuschreiben zu erreichen noch einen Schritt weiter. Nicht nur das Toolkit auch die Anwendung wird auf jeder Zielplattform kompiliert. Das Ziel bei Qt ist "Write once compile everywhere" im Gegensatz zu Java mit seinem "Write once run everywhere". Genau aus diesem Grund war Qt von Anfang an nicht als reines GUI-Toolkit konzipiert, sondern als komplettes Framework, da es von seinen Programmierern explizit als Java-Alternative konzipiert wurde.

        [
        | Versenden | Drucken ]
        • 0
          Von fuffy am Mo, 21. November 2005 um 16:17 #
          Das Ziel bei Qt ist "Write once compile everywhere" im Gegensatz zu Java mit seinem "Write once run everywhere". Genau aus diesem Grund war Qt von Anfang an nicht als reines GUI-Toolkit konzipiert, sondern als komplettes Framework, da es von seinen Programmierern explizit als Java-Alternative konzipiert wurde.
          Da die Ziele von Qt und Java so unterschiedlich sind, kann Qt gar keine J2SE-Alternative sein.
          [
          | Versenden | Drucken ]
          • 0
            Von Arnomane am Mo, 21. November 2005 um 16:40 #
            Das würde ich als reine Ansichts- und Definitionsache definieren.

            In bestimmten Bereichen/Anwendungen mag Java besser sein bei anderen Qt. Wieder andere Bereiche mögen besser durch Mono abgedeckt sein. Alle haben sie zum Ziel ein Programm möglichst unkompliziert auf allen möglichen Betriebssystemsumgebungen laufen zu lassen und sind von daher verschiedene Lösungsalternativen für dasselbe Problem.

            Und dass Trolltech selbst Qt als Alternative zu Java sieht ist Tatsache (obs tatsächlich so ist mag jeder für sich anhand seines Anforderungsprofils entscheiden).

            [
            | Versenden | Drucken ]
            • 0
              Von fuffy am Mo, 21. November 2005 um 16:55 #
              | Das würde ich als reine Ansichts- und Definitionsache definieren.
              Naja, schau dir mal Opera an und zähle die Kompilate, die allein für ein Release erzeugt werden mussten. Dieser Wildwuchs wäre mit Java z.B. nicht notwendig. Dafür hat Qt andere Vorteile. Somit überlappen sich zwar einige Teilgebiete, als vollwertige Alternative würde ich Qt allerdings nicht sehen. Auf www.trolltech.com kann ich übrigens nichts davon lesen.
              [
              | Versenden | Drucken ]
            0
            Von naseweiss am Mo, 21. November 2005 um 16:56 #
            Nicht ganz, eine J2SE-Alternative sehr wohl , eine J2EE-Alternative eher weniger ;)
            [
            | Versenden | Drucken ]
            • 0
              Von fuffy am Mo, 21. November 2005 um 16:57 #
              Auch eine J2SE-Alternative nicht oder hast du schon mal Qt-Applets im Browser gesehen? ;-)
              [
              | Versenden | Drucken ]
          0
          Von Jens am Mo, 21. November 2005 um 18:23 #
          Moin,

          > da es von seinen Programmierern explizit als Java-Alternative konzipiert wurde.

          das wage ich doch mal zu bezweifeln! War Qt nicht eher als gut durchdachter Motif-Ersatz geplant?

          - Jens

          [
          | Versenden | Drucken ]
      0
      Von pinky am Mo, 21. November 2005 um 15:14 #
      >Ähem. Kleine Korrektur. Es gibt da schon seit längerem (sprich lange bevor GTK+/GTK# in entsprechenden Versionen existierte) eine native "GUI-Konstante" für Windows, X11 und OSX: Qt

      ja, und es gibt auch wxwidgets, java und was weiß ich noch alles.
      Aber hier geht es um Mono und meine Aussage ist natürlich auch in diesem Zusammenhang zu verstehen!

      [
      | Versenden | Drucken ]
      • 0
        Von Arnomane am Mo, 21. November 2005 um 15:28 #
        Ich wusste dass dieser Hinweis kommt. ;-) Aber du stimmst mir sicher zu, dass Swing von Java nicht gerade als nativ bezeichnet werden kann. Gerade deswegen habe ich extra das unscheinbare Wörtchen "nativ" genannt. Wxwidgets kenne ich zu wenig, als dass ich profund darüber mir ein Urteil erlauben könnte. Hier kann ich eher nur auf Mutmaßungen gründend behaupten, dass es sich im Wettstreit der Toolkits scheinbar nur einen Nischenplatz erobern konnte und wohl von vielen als suboptimal für Crossplattform-Entwicklung betrachtet wird.
        [
        | Versenden | Drucken ]
        • 0
          Von pinky am Mo, 21. November 2005 um 15:40 #
          und trotzdem hat dein Einwand nichts mit meinem ursprünglichen Beitrag zu tun. ;)
          Da es eben kein stabiles und aktuelles Qt# für alle Mono Platformen gibt und schon garnicht als Bestandteil des Mono-Bundles. Deswegen nochmal der Hinweis, es geht hier um Mono und nicht um irgendein beliebiges cross-platform toolkit! Daher ist hier Qt völlig fehl am Platz.
          [
          | Versenden | Drucken ]
          0
          Von neo am Mo, 21. November 2005 um 16:05 #
          So "suboptimal" scheint wxWidgets nicht zu sein:

          http://www.videolan.org
          http://audacity.sourceforge.net
          http://www.amule.org

          [
          | Versenden | Drucken ]
          • 0
            Von clausi am Mo, 21. November 2005 um 17:35 #
            ...zumal derjenige, der hier mit Urteilen wie "suboptimal" aufwartet, in seinem obigen Beitrag anderen anrät, "doch ab und zu ein wenig bescheidener auf(zu)treten".
            [
            | Versenden | Drucken ]
            • 0
              Von Arnomane am Di, 22. November 2005 um 01:34 #
              Ich habe doch sehr vorsichtig über Wxwidgets geschrieben und lasse mich in diesem Punkt gerne eines besseren belehren (wie ja bereits anhand einer Applikationsliste geschehen), da ich freimütig eingeräumt habe in diesem Punkt mich nur auf anderer Leute Meinung zu beziehen. Aber einige wollen halt einfach stänkern.
              [
              | Versenden | Drucken ]
          0
          Von fuffy am Mo, 21. November 2005 um 16:18 #
          | Aber du stimmst mir sicher zu, dass Swing von Java nicht gerade als nativ bezeichnet werden kann.
          Noch nicht. Aber hier gehts sowieso um Mono und nicht um Qt vs. Java.
          [
          | Versenden | Drucken ]
          0
          Von Mike am Mo, 21. November 2005 um 16:30 #
          Nur kurz: In Java 6 wird Swing auch Gtk nutzen können als Look. Dann hast auch native Look mit Java.

          Gruß

          Mike

          [
          | Versenden | Drucken ]
          • 0
            Von fuffy am Mo, 21. November 2005 um 16:36 #
            Und unter Windows die uxtheme.dll.
            [
            | Versenden | Drucken ]
            • 0
              Von Mike am Mo, 21. November 2005 um 16:38 #
              Hi,

              ich nehme mal an, dass das für native Look unter Windows ist :) Was ich noch ergänzen wollte:

              Vorteil hier ist, dass ich unter Windows nicht wieder Gtk oder so installieren muss, sondern alles in Swing schreibe und die VM kümmert sich darum, dass es native aussieht. Ich hab dann vielleicht nicht all die Möglichkeiten, wie ich mit Gtk# und GNOME# habe, wenn ich eine speziell eine GNOME-Anwendung schreibe (Gconf und co), aber ich habe ein wirklich plattformunabhängiges Toolkit.

              Gruß

              Mike

              [
              | Versenden | Drucken ]
              • 0
                Von fuffy am Mo, 21. November 2005 um 16:48 #
                ich nehme mal an, dass das für native Look unter Windows ist
                Richtig. Es ist die mit Windows XP eingeführte Theme-API, die der Welt unter anderem Luna beschert hat.

                Vorteil hier ist, dass ich unter Windows nicht wieder Gtk oder so installieren muss, sondern alles in Swing schreibe und die VM kümmert sich darum, dass es native aussieht.
                Ack. Und vor allem reicht es, ein Binary der Anwendung auszuliefern und muss nicht, wie bei SWT, für jedes Betriebssystem und jede CPU-Architektur ein eigenes erzeugen. Es reicht, wenn die VM portiert wurde.

                [
                | Versenden | Drucken ]
            0
            Von pinky am Mo, 21. November 2005 um 16:51 #
            >Nur kurz: In Java 6 wird Swing auch Gtk nutzen können als Look. Dann hast auch native Look mit Java.

            naja, nur weil swing Gtk zum zeichnen verwenden wird hat das noch nicht unbedingt was mit native look zu tun. Bei WxWidget Anwendungen erkennt man auch schnell den Unterschied zu richtigen Gtk+ Anwendungen.

            [
            | Versenden | Drucken ]
            • 0
              Von fuffy am Mo, 21. November 2005 um 16:59 #
              Selbst bei Gtk+-Anwendungen erkennt man schnell den Unterschied zu richtigen Gtk+-Anwendungen.
              [
              | Versenden | Drucken ]
              • 0
                Von pinky am Mo, 21. November 2005 um 17:28 #
                >Selbst bei Gtk+-Anwendungen erkennt man schnell den Unterschied zu richtigen Gtk+-Anwendungen.

                was du meinen ???

                [
                | Versenden | Drucken ]
                • 0
                  Von Erlaubte HTML-Tags am Mo, 21. November 2005 um 18:43 #
                  Er meinen Unterschied von foo zu foo offensichtlich sein ;-)
                  [
                  | Versenden | Drucken ]
                  0
                  Von fuffy am Mo, 21. November 2005 um 20:32 #
                  Ich meine, dass es selbst zwischen Gtk+-Anwendungen Unterschiede im Look & Feel gibt. Manche verwenden GtkFileSelector, andere GtkFileChooser. Toolbars gibt es ebenfalls mehrere, wobei sich nicht alle via gconf konfigurieren lassen (Text unter Icons, Nur Icons, etc.). Hängt halt unter anderem davon ab, ob die Anwendung mit GNOME-Support kompiliert wurde.
                  [
                  | Versenden | Drucken ]
                  • 0
                    Von pinky am Mo, 21. November 2005 um 22:47 #
                    das sind einfach Programme die noch nicht updated wurde. Die alten widgets sind aus Stabilitätsgründen drin geblieben. Jedes halbwegs aktuelle Projekt wird aber die aktuellen widgets verwenden, welche auch weiter gepflegt werden und den Wechsel zu Gtk+3 überleben werden (im Gegensatz zu den alten widgets).

                    Bei wxwidgets gibt es aber teilweise sehr deutliche Unterschiede die _nicht_ in Gtk+ begründet sind. Ein Beispiel wäre der Treeview.

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von fuffy am Di, 22. November 2005 um 08:54 #
                      das sind einfach Programme die noch nicht updated wurde.
                      Abiword-Gtk wurde also noch nicht upgedated? ;-)
                      [
                      | Versenden | Drucken ]
          0
          Von Alex am Mo, 21. November 2005 um 22:42 #
          > Wxwidgets kenne ich zu wenig, als dass ich profund darüber mir ein Urteil erlauben könnte. Hier kann ich eher nur auf
          > Mutmaßungen gründend behaupten, dass es sich im Wettstreit der Toolkits scheinbar nur einen Nischenplatz erobern konnte
          > und wohl von vielen als suboptimal für Crossplattform-Entwicklung betrachtet wird.

          wer sind diese "vielen"?

          als nischenplatz würde ich es auch nicht bezeichnen. wenn ich spnotan daran denke welche plattformunabhänigegen projekte QT verwenden und welche wxwidgets, da fallen mir weit es mehr wx- als qt-projekte ein. klar ist qt sicher das öfters genutzte tollkit weil es durch kde große verbreitung gefunden hat, aber die wenigsten projekte sind plattformunabhängig.

          das wxwidgets suboptimal zur entwicklung ist würde ich auch auf keinen fall behaupten. das ergebnis welche man mit wxwidgets bekommt gefällt mir besser als das von qt, aus dem einfachen grund dass wxwidget (bis auf ein paar ausnahmen) nur ein wrapper auf native tookits ist.
          qt hat programmiertechnisch sicher vorteile, aus dem einfach grund, das als wxwidgets zu entwickeln begonnen wurde c++ noch in den kinderschuhen steckte, und man - um wirklich plattforum und compiler unabhänigig zu sein - auf viele sprachfeatures verzichten musste.

          QT ist ein interessantes, brauchbares toolkit, aber es ist bestimmt nicht der stein der weisen, der alle probleme optimal löst. QT (oder wxwidgets) mit mono oder java zu vergleichen ist meiner meinung sowieso vollkommen überflüssig. QT ist nun mal ein ein toolkit (welches man, wenn des die entsprechenden bindigs gibt, auch mit mono oder java verwenden kann), java und mono sind bytecode interpretierte sprachen, und bringen einge vorteile die man mit c oder c++ nie bekommen wird (z.b. GC, pattformunabhäniger bytecode, ...).

          [
          | Versenden | Drucken ]
          • 0
            Von pinky am Mo, 21. November 2005 um 23:01 #
            >java und mono sind bytecode interpretierte sprachen

            java ist eine Sprache _und_ eine Plattform, Mono ist _nur_ eine Platform! Die Sprachen bei Mono heißen z.B. C#, Java, Boo, Python, Nemerle,..

            [
            | Versenden | Drucken ]
0
Von André am Mo, 21. November 2005 um 14:32 #
Ich vertraue Worten aus dem Hause Ximian oder dem Munde Icaza nicht. Gibt es vielleicht Externe, die das mal auf Herz und Nieren testen können? Für mich sieht es so aus, dass es Mono seit einigen Jahren gibt, daran entwickelt wird, zig Entwickler daran arbeiten, aber abgesehen von Schnickschnack nie wirklich bedeutende Anwendungen bekannt werden, die drunter laufen. Also alles Zukunftsmusik, wenn den nicht .NET überhaupt floppt. Und beim Hause Ximian ist natürlich mal wieder die übliche ideologische KDE-Interoperationssabotage zu erwarten. Insofern bin ich ein Skeptiker.

"We had plans last year to complete a free Visual Basic compiler. Today the compiler exists in beta form and Novell will no longer fund the development of this compiler."

Das wäre das einzig interessante gewesen aus meiner Sicht. Miguel hat irgendwie die Macke sich mit voller Kraft in irgendwelche Projekte rein zu stürzen, aber nie was 100% zu beenden, sondern bei 60% auszusteigen und die Projekte leise ihrer Vollendung zudümpeln zu sehen. Wirklich merkwürdig. Oder Projekte anzukündigen, bei denen schon klar ist, dass draus nichts wird. Wie kann man sicher sein, dass nicht mit Mono ein weiterer 85% Müllhaufen geschaffen wird, bei dem sich Novell schliesslich zurückzieht, weil eine Vollendung die finanziellen Ressourcen und den zeitlichen Horizont übersteigt? Wie glaubwürdig ist ein "bald sind wir am Ziel", wenn es über 5 Jahre zum Credo wird? Wie viel Geduld hat Novell mit seinen "Desktop-Strategen" von Ximian? Man denke nur wie sich Corel damals mit dem Wine-Projekt verhoben hat, das sogar heute noch einen weiten Weg hat.

"Windows.Forms, die einzige noch nicht vollständige Komponente für Mono 1.2, soll bis Ende dieses Monats fertig werden. Danach sollen rund drei Monate nur auf die Korrektur von Fehlern verwandt werden, um danach Mono 1.2 offiziell freizugeben."

Was wenn Windows.forms nicht fertig wird, sondern in 5 Monaten ein Windows.forms mit Mono 1.2 released wird und innerhalb von 2-3 Jahren ein Stück buggige Scheisse in eine funktionsfähige Form gebracht wird, bei der man sich wie ein Schneekönig freut über jeden kleinen Schritt, die der kleine gelernt hat. Nach 2-3 Jahren schmeisst man den Dreck schliesslich weg, weil man keinen Bock mehr hat oder MS auch inzwischen auf was anderes setzt oder mit der Patentkeule gute Nacht gesagt hat...

Ich will's ja nicht hoffen.

[
| Versenden | Drucken ]
  • 0
    Von pinky am Mo, 21. November 2005 um 15:19 #
    sorry, aber für mich ist dein Beitrag viel heiße Luft um nichts. Zumindest kann ich darin keine Fakten erkennen.
    Und was deine "interessanten" Teile (Visual Basic und window.forms) betrifft, so ist es für mich und ich denke viele andere in der GNU/Linux Welt auch so ziemlich das uninteressanteste an Mono. Ich hätte darin z.B. von Anfang an kein Geld, keine Zeit und keine Arbeit gesteckt...
    [
    | Versenden | Drucken ]
    • 0
      Von anon am Mo, 21. November 2005 um 15:24 #
      ACK!
      [
      | Versenden | Drucken ]
      0
      Von André am Mi, 23. November 2005 um 00:15 #
      Wine 3.x war en Erfolg wegen Visual Basic und der gigantischen Menge Applikationen, die RAD-mässig erzeugt wurden. Wenn du Vb.NET nicht bedeutsam nennst kann ich das verstehen, denn VB ist als Entwicklungsplattform beinahe tot. Aber: VB for Applications hat eine große Bedeutung als Makrosprache in Betrieben und ist Haupthindernis, warum man nicht zu Linux oder OO.org wechseln kann. Makrokompatibilität zu MS Office wäre ein Killerfeature.

      Windows.forms is interessant, weil es GUI-Kompatibilität zwischen der Windows und der Linuxwelt herstellt, sofern denn .NET die zukünftige Entwicklungsplattform sein wird.

      Windows.forms und VB.NEt support ist daher so eine Art Wine der Zukunft, nur mit weniger Aufwand und leichter+stabiler zu erreichen.

      Alles andere was .NET bietet ist für mich wiederum uninteressant. Denn wir haben ja längst Java. Und wir haben gute oder bessere Entwicklungspakete.

      [
      | Versenden | Drucken ]
    0
    Von Christian am Mo, 21. November 2005 um 15:23 #
    > ... aber abgesehen von Schnickschnack nie wirklich bedeutende Anwendungen bekannt werden....

    Beagle würde ich nicht als "Schnickschnack" bezeichnen. (http://www.beagle-project.org)

    [
    | Versenden | Drucken ]
    • 0
      Von pinky am Mo, 21. November 2005 um 15:45 #
      >Beagle würde ich nicht als "Schnickschnack" bezeichnen. (http://www.beagle-project.org)

      Für das alter von Mono gibt es schon relativ viel:
      http://www.mono-project.com/Software

      Und auch deutsche Unternehmen verwenden bereits Mono: http://www.novell.com/news/leadstories/2005/feb28/

      [
      | Versenden | Drucken ]
      • 0
        Von MaXe am Mo, 21. November 2005 um 16:25 #
        "Für das alter von Mono gibt es schon relativ viel:
        http://www.mono-project.com/Software"

        Mono ist jetzt knapp 5 Jahre alt. Die Seite listet dennoch nicht einmal 3 Dutzend Applikationen. Davon werden knapp 30% Novell-Intern maintained. Eine ganze Reihe der genannten Programme werden inzwischen nicht mehr weiterentwickelt (z.B. der KStars-Clone SkyNET oder WorldWind2D, dessen Author inzwischen wieder zu Java zurückgekehrt ist).
        Die meisten anderen haben eher Demo-Charakter als dass sie für ernsthaften Produktiveinsatz taugen.

        "Und auch deutsche Unternehmen verwenden bereits Mono: http://www.novell.com/news/leadstories/2005/feb28/"

        Und das ist dann auch schon der einzige Report, den ich in den letzten Jahren über einen "größeren" Einsatz von Mono in Deutschland gefunden habe -- außerhalb von Novell.

        [
        | Versenden | Drucken ]
        • 0
          Von fuffy am Mo, 21. November 2005 um 16:50 #
          | Mono ist jetzt knapp 5 Jahre alt.
          Dann gibt es Mono ja schon länger als .NET. Das wurde nämlich erst 2002 eingeführt. ;-)
          [
          | Versenden | Drucken ]
          • 0
            Von MaXe am Mo, 21. November 2005 um 16:57 #
            > Dann gibt es Mono ja schon länger als .NET. Das wurde
            > nämlich erst 2002 eingeführt

            http://en.wikipedia.org/wiki/Mono_development_platform

            "Miguel de Icaza became interested in the .NET technology as soon as the .NET documents came out in December 2000. At GUADEC 2001 Miguel de Icaza showed a demo for a few folks of their C# compiler and how it was able to parse itself.
            [...] The Mono team didn't have the strength to build a full .NET replacement on their own and on July 19, 2001 the Mono open source project was announced at the O'Reilly conference."

            [
            | Versenden | Drucken ]
            • 0
              Von fuffy am Mo, 21. November 2005 um 17:01 #
              Und war das schon ein Release? Eher nicht.
              Wann kam nochmal Mono 1.0 raus? 2004! ;-)
              [
              | Versenden | Drucken ]
              • 0
                Von MaXe am Mo, 21. November 2005 um 17:09 #
                Das erste Release (meist eine eher willkürlich-subjektive "1.0") einer OpenSource-Software hat nichts mit dem Alter zu tun. Da zählt man eher seit dem ersten Announcement (z.B. "15 Jahre Linux, 10 Jahre KDE"). Insbesondere weil bei OSS Software die Software oft schon deutlich vor dem 1.0-Release von Entwicklern als Grundlage für Eigenentwicklungen genutzt werden kann - so auch bei Mono. Ansonsten wäre Wine auch noch 0 Jahre alt ;-)
                [
                | Versenden | Drucken ]
                • 0
                  Von pinky am Mo, 21. November 2005 um 17:31 #
                  aber du kannst nur schlecht davon ausgehen, dass Leute ein Programm verwenden, welches bisher nur aus einer Ankündigung besteht, oder ;)
                  Bei einem Framework kommt noch dazu, dass man (zumindest für eine gewisse Zeit) gerne eine stabile API hätte, die 1.0 Version spielt da also auch eine entscheidende Rolle.
                  Also ist Mono effektiv nicht viel älter als ein gutes Jahr!
                  [
                  | Versenden | Drucken ]
                  • 0
                    Von Hans-Wurst am Mo, 21. November 2005 um 17:53 #
                    Trotzdem sind diese paar Dutzend Programme lächerlich. Auf www.kde-apps.org werden ja wöchentlich mehr neue Programme veröffentlicht, als es für Mono überhaupt gibt.

                    Ich rechne eher damit, dass Miguel bald gekündigt wird, wenn Mono nicht überraschende Fortschritte macht.

                    C++ wurde schon 1000mal totgesagt, die Realität schaut aber anders aus: >90% aller Software wird in c++ geschrieben, ein paar prozent fallen auf ObjectivC (hauptsächlich Mac-Software), und den Rest teilen sich interpretierte Sprachen, C und pascal.

                    [
                    | Versenden | Drucken ]
      0
      Von schnick am Mo, 21. November 2005 um 16:04 #
      Bei Beagle ist lediglich das _Frontend_ mit Mono erstellt worden. Das Backend verwendet C. Sowas würde auch ich als "Schnickschnack" bezeichnen.
      [
      | Versenden | Drucken ]
0
Von Mike am Mo, 21. November 2005 um 16:20 #
Also ich bin schon irgendwie begeistert, wie schnell sich Mono entwickelt. Allerdings weiß ich nicht, wie groß der Anklang außerhalb der eingefleischten Mono-Fans ist. Es gibt zwar hier und da eine Anwendung, die in C# für GNOME entwickelt wird, aber die große Masse ist weiterhin in C geschrieben, oder eben C++. Dann gibt es auch viele Anwendungen in Python und die ein oder andere Anwendung in Ruby.

Die große Vielfalt an Bindings für Gtk/GNOME macht es eben leicht in verschiedensten Sprachen für den GNOME-Desktop zu programmieren. Aber wie schon gesagt ist der Anteil der C# Anwendungen imho nicht viel größer als der von Java-Anwendungen. Sicher gibt es Mono noch nicht so lange, wie Java. Ich persönlich habe bisher um Mono auch noch einen großen Bogen gemacht. Ich finde die Sprache persönlich sehr nett und ich würde es als Windows-Entwickler auch definitiv nutzen. Es hat natives Look and Feel, die .NET Umgebung scheint auch recht fix zu sein und Visual Studio ist auch nicht übel.

Als Linuxer fällt die ganze Sache etwas schwerer. Man kann zwar auch sehr bequem Gtk/GNOME-Anwendungen schreiben, die auch nativen Look haben. Aber das ganze hat ja doch immer diesen üblen Beigeschmack von Microsoft. Ich weiß zwar, dass die rechtliche Lage nicht groß unterschiedlich ist zu der von Java, aber trotzdem würde ich mich für Java entscheiden, wenn ich wählen müsste. .NET und womöglich noch ASP.NET auf meinem Rechner missfällt mir irgendwie. Und ja, es gibt Gründe, warum man sich keine Gedanken machen braucht, aber ich kann das eben nicht abstellen. :)

Es stellt sich mir eben die Frage, wieso auf einmal alle so einen Hype um Mono machen. Mono steht für mich für eine einfache objektorientierte Programmierplattform insbesondere für den GNOME-Desktop. Wieso wurde um Java mit Java-GNOME nie so ein Hype gemacht? Worin sehen die Leute einen Unterschied von Mono mit Gtk# zu Java und Java-GNOME? Oder kennt einfach keiner Java-GNOME? Oder war das Problem, dass Java nicht frei war? Das dürfte mit GNU-Classpath und offenen VMs ja auch anders aussehen mittlerweile.

Interessant finde ich nun, dass auch Microsoft seine .NET Plattform nicht so pusht, wie ich es eigentlich erwartet hätte. Angeblich soll .NET auch in Windows Vista nicht standardmäßig installiert sein. Gibts sonst Ärger mit SUN?

Fragen über Fragen. Ich bin gespannt, wie die Entwicklung weitergeht. Und selbst, wenn Mono selbst keinen großen Anklang bei Personen findet, die Anwendungen speziell für Linux schreiben, sondern nur ermöglicht viele Programme, die ursprünglich für Windows geschrieben wurden unter Linux laufen zu lassen hat es sich schon gelohnt. Mal schauen, wie oft C# unter Windows zum Einsatz kommt, ob es nur ein Hype ist, oder ob neue Technologien, wie Avalon, Indigo, die sicher nicht ohne weiteres portierbar sind die ganze schöne Idee hinter Mono und der einfachen Ausführung von Windows-Anwendungen unter Linux nicht letztenendes zu Nichte machen. Warten wirs ab.

Gruß

Mike

[
| Versenden | Drucken ]
  • 0
    Von qwer am Mo, 21. November 2005 um 20:21 #
    .NET muss Bestandteil von Vista sein, da wichtige APIs wie Avalon, Indogo, usw. auf .NET basieren.
    Siehe WinFX: http://tinyurl.com/a4878
    Mit Sun habe man sich angeblich geeinigt (AFAIK), dass Java Zugriff auf niedrigere Dienste bekommt um .NET zu umgehen. Ein Java, welches auf .NET läuft, macht wohl wenig sinn...
    [
    | Versenden | Drucken ]
    • 0
      Von pinky am Mo, 21. November 2005 um 22:43 #
      >Ein Java, welches auf .NET läuft, macht wohl wenig sinn...

      Wieso? Das ist ja eine der großen Stärke der CLI, dass man mit verschiedenen Sprachen Programmieren kann und alle am Ende aufeinander zugreifen können. Ob jetzt Java auf der java-vm oder der CLI läuft sollte für den Anwender keinen Unterschied machen.

      [
      | Versenden | Drucken ]
      • 0
        Von qwer am Mo, 21. November 2005 um 23:37 #
        Ich rede nicht davon, ob man Java zu CIL kompilieren werden kann. Was sicher geht, da die CIL deutlich mächtiger ist als der Java Bytecode. Sun wird das aber nicht so toll finden, wenn ihre Plattform von .NET assimiliert wird.
        Java soll ja schließlich Java bleiben und zu keinem Java.NET werden ;)
        Ich meine eher, dass es wenig Sinn macht, die .NET Klassenstruktur zu wrappen, um sie als Javaklassen zu nutzen. Irgendwie muss Java mit AWT/Swing auf Avalon und Co. zugreifen, um GUIs zu rendern. Bedenke, dass WinFX an die Stelle von Win32 treten wird. Also nix mit C-API und JNI.
        Eine Java VM, die in einer gemanagten .NET Umgebung läuft ist Quatsch - wenn man mit einem akzeptablem Resourcenverbrauch auskommen möchte. Wie das genau aussehen wird, muss erst mal von MS und Sun beantworten werden ...
        [
        | Versenden | Drucken ]
    0
    Von nico am Di, 22. November 2005 um 15:27 #
    Für mich ist mono solange gestorben, bis dies endlich ein echtes unabhängiges und einfach zu installierendes framework ist.
    Solange man als KDE-Nutzer gezwungen ist gnome mit auf der Platte zu haben und diese komische Entwicklungsumgebung noch irgendwelche Mozilla-Pfade verwenden will, ist es einfach nicht einsetzbar. auch ist der haufen von paketen einfach irritierend, da weiss man nicht wirklich was man davon braucht.

    für win gibt es keine ide, die mono wirklich unterstützt.

    solange aber ximian die führungsrolle hat, wird sich nichts ändern. die wollen mono an gnome binden, koste es was es wolle.

    [
    | Versenden | Drucken ]
    • 0
      Von fuffy am Di, 22. November 2005 um 15:31 #
      und diese komische Entwicklungsumgebung noch irgendwelche Mozilla-Pfade verwenden will
      Das hat weniger mit MonoDevelop als mit MonoDoc zu tun, das einen HTML-Renderer braucht. Und da Mono von Ximian entwickelt wird, wird wohl kaum KHTML eingesetzt werden.

      für win gibt es keine ide, die mono wirklich unterstützt.
      SharpDevelop

      [
      | Versenden | Drucken ]
0
Von Gast am Mo, 21. November 2005 um 20:10 #
Ich würde mir eine Zusammenarbeit von mono und Wine wünschen, um .Net Programme die DirectX verwenden
unter Wine zum laufen zu kriegen. Jedenfalls für meine Enkel irgendwann mal.
[
| Versenden | Drucken ]
  • 0
    Von ewr am Mo, 21. November 2005 um 20:27 #
    Naja, so viele .NET Spiele gibt es ja noch nicht.
    Oder spielen deine Enkel etwa ArenaWars oder Alexander The Great? ;)
    [
    | Versenden | Drucken ]
    0
    Von thomas001 am Di, 22. November 2005 um 03:11 #
    Du solltest dir lieber wuenschen das deine Enkel keine Spielen mehr kaufen koennen die auf .NET oder DirectX basieren und stattdessen frei sind und offene Standards nutzen!

    Dieses auf das zwingende Fortbestehen der MS Windoze Herrschaft gerichtete Denken macht mir jetzt irgendwie angst, schliesslich sollen die freien System keine Windows Emulatoren oder Nachbauten werden!

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