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?
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.
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.
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.
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).
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.
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?
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.
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.
mkay, danke
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.
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).
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.
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.
Besten Dank für die Kurzinfo.