Login
Newsletter
Werbung

Thema: GNUstep mit Kickstarter-Kampagne für Cocoa-APIs

23 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Nixchecker am Mi, 7. November 2018 um 09:54 #

Mir als Laien ist die Meldung zu technisch. Was heißt denn das? Gibt es ernstgemeinte Bestrebungen, die MacOSX-Oberfläche unter GNU/Linux zum Laufen zu bringen? Ist das überhaupt das Ziel?

  • 1
    Von safsadf am Mi, 7. November 2018 um 10:47 #

    Nein, das heißt nicht, dass es Bestrebungen gibt die MacOSX-Oberfläche unter GNU/Linux zum Laufen zu bringen. Es bedeutet dass der Portierungsaufwand OSX->Linux für ein für OSX/Coca geschriebenes Programm kleiner wird. Es muss dafür aktiv von dem Hersteller neu compiliert werden. Und fehlende Schnittstellen müssen entweder in GNUStep erweitert werden oder in dem Programm müssen diese getauscht werden.

    • 1
      Von Anonymous Coward am Mi, 7. November 2018 um 11:05 #

      Nein, das heißt nicht, dass es Bestrebungen gibt die MacOSX-Oberfläche unter GNU/Linux zum Laufen zu bringen.
      Im Artikel wird auch darling erwähnt, das genau das tut.

      • 1
        Von safsadf am Mi, 7. November 2018 um 12:42 #

        Ups ja dass mit darling wenn über 100000 hab ich überlesen :/. Man sollte sich aber beim Spenden bewusst sein, dass darling noch einen sehr sehr weiten weg hat.

        • 1
          Von Nixchecker am Mi, 7. November 2018 um 13:45 #

          mkay, danke

          • 1
            Von Ghul am Do, 8. November 2018 um 18:28 #

            Darlin wird auf der Webseite mit Wine verglichen.

            Wine verlangt keine Neucompilierung, sondern kann die Binaries, die für Windows compiliert wurden auch direkt ausführen und bietet damit sicherlich auch eine Art Umgebung an (So Sachen wie bspw. eine Registry, Umgebungsvariablen usw.), die einer Mac OS X App ein Mac OS X vortäuscht.

            Die Gnustep Erweiterungen dürften daher wirklich nur dazu dienen, den Portierungsaufwand etwas zu vereinfachen.
            Programme, deren Quellcode die Cocoa-Api nutzen, können davon profitieren, aber da Gnustep keine vollständige Umgebung emuliert bzw. einen Wrapper stellt, wird es mit einer bloßen Neukompilierung nicht getan sein.
            Hier und da wird man sicherlich noch Linuxspezifische Anpassungen im Quellcode vornehmen müssen.

            • 0
              Von naja doch eigentlich schon am Fr, 9. November 2018 um 10:47 #

              Siehe TextEdit.app sowie Chess.app, die screenshots dazu:
              https://screenshots.debian.net/package/textedit.app
              https://screenshots.debian.net/package/chess.app

              Massiv einfacher. Und noch dazu hat das aktuelle GNUstep kompiliert mit objc-2 support, multithreading support wie macOS, sowie
              bereits jetzt schon macOS Interface (sowie Windows Interface) Support: sprich, Menus mit nicht-entkoppeltem Menu (wie ab Windows 95),
              und bei macOS, topmenus, sowie Theming. Nur dass sich niemand die Muehe gemacht hat das zu praesentieren.

              Ich finde es sehr Schade (dass diese schlanke Software namens GNUstep nicht den verdienten Support an finanziellen Mitteln erhaelt), denn
              es ist so schlank dass es auch sehr spritzing auf einem RaspberryPi laeuft (siehe livecd.gnustep.org fuer ein Image zum probieren).

              • 0
                Von Ghul am Fr, 9. November 2018 um 14:10 #

                denn
                es ist so schlank dass es auch sehr spritzing auf einem RaspberryPi laeuft

                Wenn die API erweitert wird und damit dann Features möglich werden, die ein heutiger moderner Mate, Gnome oder KDE Desktop hat, dann wird es auch nicht mehr so schlank sein wie jetzt.

                Die derzeitige Resourcensparsamkeit basiert wahrscheinlich größten Teils darauf, dass es schon ein sehr altes Projekt ist und im Vergleich zu Gnome oder KDE nur sehr langsam weiterentwickelt wurde.
                Dies hat dann natürlich Vorteile auf Hardware wie den Raspberry Pi, der mit ca. 512 MB - 1024 MB so wenig RAM hat, wie es vor ca. 18 Jahren auf Desktop PCs der Fall war.

                Zukünftige Einplatinencomputer in der Preisklasse eines Raspberry Pi und dessen Nachfolger dürften in wenigen Jahren oder gar Monaten 2 GB RAM oder mehr RAM haben. Damit wären das Geräte, auf denen man einen umfangreichen ausgereiften Desktop wie Mate sehr gut benutzen könnte.
                Dazu kommen noch zu erwartende Leistungssteigerungen seitens der CPU.

                Insofern sehe ich in der derzeitigen Resourcensparsamkeit von Gnustep, die sich ja noch ändern könnte, keinen Grund, da viel Geld reinzustecken, wenn wir jetzt mal die Annahme treffen, dass das Geld aus einem gemeinsamen Topf kommen würde und sich viele andere Open Source Projekte dieses Geld untereinander aufteilen müssten.

                Da ist die Kompatibilität zur Cocoa-Api, damit Mac OS X Anwendungen leichter portiert werden können, ein wesentlich überzeugenderes Argument.

                Schlanke Umgebungen kann man ansonsten auch mit XFce und LXQt schon jetzt für den Raspberry Pi haben.

    2
    Von maxxx am Mi, 7. November 2018 um 11:32 #

    Also, fangen wir mal vorne an:
    Eine API ist eine Programmierschnittstelle.

    Wine ist der Nachbau der Windows API.
    Mono ist der Nachbau der .NET API.
    GnuStep ist der Nachbau der NextStep API.

    MacOS X basiert auf NEXTStep.

0
Von schmidicom am Mi, 7. November 2018 um 12:15 #

Würden sie gezielt für Darling um finanzielle Unterstützung bitten dann wären die Chancen wohl erheblich besser die nötige Summe zu erreichen denn bei GNUstep allein dürfte das Interesse wohl kaum ausreichen.

  • 1
    Von Donald_Luck am Mi, 7. November 2018 um 12:33 #

    Heiratswillige Prinzessin Peaches konnte auch erst erreicht werden, wenn davor genug Pilzmännchen(Toat's?) befreit wurden.

    1
    Von safsadf am Mi, 7. November 2018 um 12:44 #

    Vermutlich ja, aber was für Programme vermisst ihr denn von Osx für die es keinen Windows Port (wine ist schon recht fortgeschritten) gibt?

    • 0
      Von schmidicom am Mi, 7. November 2018 um 12:55 #

      Aus meiner Sicht ist wine eine einzige Useability-Katastrophe...
      Allein schon die Angewohnheit, per XDG, sämtliche Dateizuordnungen des aktuellen Benutzers ungefragt zu vermurksen ist schon inakzeptabel. Und noch so ein schönes Beispiel wäre der Status des folgenden Anliegen bei dem es nicht wirklich vorwärts geht: Enable using Wine with Wayland and without X on Linux

      Dieser Beitrag wurde 1 mal editiert. Zuletzt am 07. Nov 2018 um 12:56.
      • 1
        Von homer am Mi, 7. November 2018 um 13:10 #

        Aus meiner Sicht ist wine eine einzige Useability-Katastrophe...
        +1

        Leider ist wine die einzige Möglichkeit, ein Windows-Programm im Linux-Desktop zu starten ohne gleich eine virtuelle Maschine mit einer kompletten Windows-Installation anzuwerfen. Leider ist es auch oft nach dem Start gleich wieder vorbei mit dem Windows-Programm wegen unzähliger API-Probleme, die voraussichtlich erst gelöst werden können, wenn Microsoft den Quellcode für Windows 7 oder 10 frei gibt. Vermutlich wird aber eher die Hölle zufrieren.

        • 1
          Von safsadf am Mi, 7. November 2018 um 13:12 #

          Ja aber all die Probleme wird darling auch bekommen plus die dass da noch gar nichts GUI mäßiges läuft

          • 1
            Von homer am Mi, 7. November 2018 um 14:31 #

            ja, das sehe ich auch so.
            Das Grundproblem sind letztendlich proprietäre ClosedSource-Programme. Solange eine Software auf ein bestimmtes Betriebssystem (inkl. den verfügbaren Libraries) angewiesen ist, wird es Wine, darling, DOSBox, etc. geben. Nichts gegen die wertvolle Arbeit dieser Communities, aber systembedingt kann dabei immer nur eine "Krücke" herauskommen.

        1
        Von safsadf am Mi, 7. November 2018 um 13:11 #

        Puh ich finde die Begründung bei dem Bug aber schon gut. Ist ja nicht so wie wenn sie sich weigern würden das zu implementieren. Wenn die Wayland devs das nicht haben wollen bleibt denen ja nur für jeden compositor wine patches zur Berfügung zu stellen. Was nie alle compositors integrieren werden. Da würde ich mich in dem Fall über die Wayland devs mehr beschweren wie über die von wine.

        • 1
          Von Ghul am Do, 8. November 2018 um 19:16 #

          Sicherheit geht vor.

          Die Wayland Devs machen es daher richtig.
          Die Wine Entwickler müssen sich halt anpassen.

          Ein transparenter virtueller Desktop kann das Problem lösen.
          Der kann eine Anfrage über den Compositor an Wayland stellen, eine Zeichenebene darzustellen und alle Wine Programme können sich dann relativ innerhalb dieser Zeichenebene, also des transparente virtuelle Desktop so positionieren, wie sie es brauchen.

          Jetzt müsste man es nur noch hinkriegen, dass da, wo dieser virtuelle Desktop transparent ist, den Mausfokus nicht Wine bekommt, sondern die Wayland Anwendung dahinter.

        1
        Von Anonymous am Mi, 7. November 2018 um 20:12 #

        Meines Erachtens sind die XDG-Menüs eine einzige Usability-Katastrope.

        Darum verwende ich auch nur WM, bei denen ich das Menü selber anlegen kann und die das Konzept der Globalmenüs nicht kennen (in meinem Falle sind das FVWM und ICEWM).

        Da kann Wine anlegen was es will; das sehe ich nur, wenn ich alle halbe Jahre den Murks aus dem .local - Ordner rauslösche.

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung