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.
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.
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.
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.
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.
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.
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.
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.
Hab leider nichts dazu gefunden ob es einen Bug dazu gibt. Wine XDG Menü Einträge abzugewöhnen sollte Programmiertechnisch nicht so schwer zu implementieren sein. Habt ihr da einen Bug dazu? Oder ist das generell als WONT DO gekennzeichnet.
Das erste was ich mache, wenn ich wine nutzen will ist.
Wine den Zugriff auf den Homeordner zu gewähren. D.h. der wird per winecfg verboten. Wine kriegt dann das, was in .wine/ an C: drives vorhanden ist und eventuell noch ein separates Verzeichnis in meinem Homeordner.
Damit pfuscht mir Wine auch nicht in die Quere und die Schreibzugriffe der Anwendungen die mithilfe von Wine laufen, bleiben auf diese Beschränkungen beschränkt.
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.
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.
Heiratswillige Prinzessin Peaches konnte auch erst erreicht werden, wenn davor genug Pilzmännchen(Toat's?) befreit wurden.
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?
Aus meiner Sicht ist wine eine einzige Useability-Katastrophe...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 07. Nov 2018 um 12:56.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
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.
Ja aber all die Probleme wird darling auch bekommen plus die dass da noch gar nichts GUI mäßiges läuft
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.
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.
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.
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.
Hab leider nichts dazu gefunden ob es einen Bug dazu gibt. Wine XDG Menü Einträge abzugewöhnen sollte Programmiertechnisch nicht so schwer zu implementieren sein. Habt ihr da einen Bug dazu? Oder ist das generell als WONT DO gekennzeichnet.
Hab es gerade gefunden, man kann das disablen!
Winemenubuilder
und
How_can_I_prevent_Wine_from_changing_the_filetype_associations_on_my_system
Das erste was ich mache, wenn ich wine nutzen will ist.
Wine den Zugriff auf den Homeordner zu gewähren.
D.h. der wird per winecfg verboten.
Wine kriegt dann das, was in .wine/ an C: drives vorhanden ist und eventuell noch ein separates Verzeichnis in meinem Homeordner.
Damit pfuscht mir Wine auch nicht in die Quere und die Schreibzugriffe der Anwendungen die mithilfe von Wine laufen, bleiben auf diese Beschränkungen beschränkt.
macOS ist Linux technisch viel näher als Windows.