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.
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.