Eto: [Req] Native (reine C#) Wayland-Backend-Unterstützung

Danke für den Vorschlag! Aber warum sollten wir uns direkt an Wayland binden, wenn wir bereits GTK verwenden (das auf Wayland sitzt)? Erfindet das nicht das Rad neu? Soweit ich weiß, müssten wir alle Widgets, Fensterfunktionen usw. implementieren.

Worin sehen Sie den Vorteil dieses Ansatzes?

Es ist eine gute Idee, aber für Mono Framework oder .net Core nicht für Eto Framework. Die Vorteile liegen auf der Hand. Eto -> gtk# -> mono/.net core -> gtk+ -> xwindow. Nur eto -> mono/.net core -> wayland.

Ich könnte mich irren, aber es scheint, dass Wayland nur einen Compositer bereitstellt. Es scheint keine Zeichen-API zum Zeichnen von Linien, Verläufen, Texturen usw. bereitzustellen. Dies würde so etwas wie Kairo bieten und macht es sehr gut. Ich kann mir nicht vorstellen, dass Eto.Forms eine eigene Zeichen-API implementiert, die in einen Puffer rendert, da dies das Rad neu erfinden und wahrscheinlich schlecht machen würde.

Ich habe jedoch oft darüber nachgedacht, benutzerdefinierte gezeichnete Handler für jedes Eto-Steuerelement (wie Button, TextBox usw.) mithilfe der Eto.Drawing-API zu erstellen. Dies würde bedeuten, dass man nur die Eto.Drawing-Handler für eine Plattform einpacken müsste, um sie zu unterstützen (wenn Sie sich nicht darum kümmern, wie es optisch aussieht).

Eto.Forms umschließt bereits Kairo (das Wayland unterstützt), also müssten wir nur benutzerdefinierte Handler für jedes Steuerelement erstellen und wir können GTK+ zumindest wegschneiden. Dies ist jedoch noch viel Arbeit. Wenn jemand daran interessiert ist, wäre dies eine willkommene Ergänzung und ich könnte helfen, dies zu starten, aber ich kann nicht viel von der Arbeit erledigen.

Gibt es noch jemanden, der sich für diese Idee interessiert? Ich habe es geschafft, eine Bindung zu Wayland zu erstellen, die es C# ermöglicht, Wayland zum einfachen Erstellen einer Benutzeroberfläche zu verwenden. Ich plane, das Design fertigzustellen, bevor ich ein Repo dafür hochlade. (Es verwendet im Wesentlichen die DL-Bibliothek, um die native Wayland-Bibliothek dynamisch zu laden, die dieselbe Bibliothek ist, die Mono zum Importieren von DLL-Funktionen verwendet und direkt mit ihr kommuniziert. Keine Zwischenbibliothek erforderlich, um P/Invoke zwischen Wayland und C# zu verarbeiten.) Ich bin auch die Verwendung von ImageSharp anstelle von Kairo (Kairo kann anscheinend nicht mit dem gemeinsam genutzten Speicherpuffer interagieren, verachte meine Bemühungen.)

Ich verstehe wirklich nicht, warum dieses Thema überhaupt eine Sache ist ... Was würden Sie gewinnen?

Die Eliminierung der Anforderungen für GTKSharp- und GTK-Abhängigkeiten ist ein großes Problem. Wayland ist relativ schnell und flexibel genug, dass wir Bibliotheken wie Skia, OpenGL, ImageSharp oder andere Bibliotheken verwenden könnten, um unsere Eto.Form zu rendern Benutzeroberfläche, die den Benutzern insbesondere in eingebetteten Umgebungen mehr Optionen bietet ( https://www.youtube.com/watch?v=GtXQJ0c5q0k , um zu sehen, wie Wayland auf ARM-Geräten verwendet wird).

Wie um alles in der Welt würden Sie einen Button nur mit Wayland rendern, ohne auf gtk/qt weiterzuleiten und ihn trotzdem nativ aussehen zu lassen?

Sie zeichnen es entweder durch Bilder, um die Ränder zu rendern, oder durch Code. Es ist einfacher als Sie denken und ähnelt dem HTML-Webdesign. ImageSharp bietet viele ähnliche Funktionen wie Gimp für C#, um diese Aufgabe zu vereinfachen.

Sie zeichnen es entweder durch Bilder, um die Ränder zu rendern, oder durch Code. Es ist einfacher als Sie denken und ähnelt dem HTML-Webdesign.

Der Sinn von Eto Forms besteht darin, eine native Benutzeroberfläche für die Plattform bereitzustellen, was dieses Problem erfordert, wäre für ein Projekt wie: https://github.com/AvaloniaUI/Avalonia . besser geeignet

Und mein Punkt steht immer noch, wir können eine C#-Plattform unter Eto erstellen, um eine native Benutzeroberfläche bereitzustellen, die auf allen Plattformen funktioniert, nicht nur auf Linux.

Und mein Punkt steht immer noch, wir können eine C#-Plattform unter Eto erstellen, um eine native Benutzeroberfläche bereitzustellen, die auf allen Plattformen funktioniert, nicht nur auf Linux.

Sie würden eine benutzerdefinierte Zeichnung sein, die Benutzeroberfläche sieht nicht nativ aus.

Ich vermute, in dieser Umgebung gäbe es kein anderes UI-Toolkit, also gäbe es so etwas wie „nativ“ nicht. Ich habe oft daran gedacht, thematische Handler zu erstellen, die alle auf Drawable-Steuerelemente hinauslaufen, für die nur ein Zeichnungsstapel implementiert werden muss. @cra0zy hat jedoch Recht, da Avalonia bereits mehr in diese Richtung ist und ich glaube, dass bereits ein Skia-Backend in Arbeit ist.

Sie sagen also, dass das Eto-Projekt für Alternativen nicht offen sein wird und einfach bei aufgeblähten Bibliotheken wie GTK bleiben würde, die verachten, dass es möglich ist, sich davon zu entfernen?

@CsharpOnLinuxDev nein, ich bin dafür offen. Es macht keinen Sinn, das, was Eto ist, einzuschränken, und wenn Sie (oder jemand) der Meinung sind, dass es ein großartiges Framework wäre, auf dem alternative Plattformen basieren könnten, dann unterstütze ich das voll und ganz. Ich denke, es gibt definitiv einen Anwendungsfall, um Plattformen ohne vorhandene UI-Toolkits wie GTK oder QT für eingebettete Plattformen zu unterstützen. Es könnte auch verwendet werden, um Windows mit .NET Core zu unterstützen, was anscheinend viele Leute nach dem Bissen kauen.

Davon abgesehen habe ich keine Zyklen, um eine solche Plattform zu entwickeln oder zu warten, daher muss jeder Fortschritt in dieser Hinsicht von der Community kommen. Es muss auch nicht unbedingt Teil des Eto-Hauptrepo sein, jeder kann eine Plattformimplementierung für Eto erstellen und nach Belieben veröffentlichen. (;

Ich kann (wie immer) jedoch Hilfe und Anleitung geben, für jeden, der fragt.

Hallo, gibt es diesbezüglich Fortschritte? Wird Wayland in Eto integriert?

Nun, wenn Sie das Gtk 3-Backend verwenden, verwenden Sie bereits Wayland ...

@cra0zy Danke für deine Antwort!
Aber ich meine eto -> mono/.net core -> wayland , nicht Eto -> gtk# -> mono/.net core -> gtk3 -> wayland .

Eigentlich versuche ich einen Wayland C# Warpper zu finden. 😃