Eto: [Req] Prise en charge du backend wayland natif (pur C#)

Merci pour la suggestion! Cependant, pourquoi nous lierions-nous directement à wayland alors que nous utilisons déjà GTK (qui se trouve au sommet de wayland) ? Cela ne réinvente-t-il pas la roue ? D'après ce que j'ai compris, nous devrions implémenter tous les widgets, les fonctionnalités de fenêtrage, etc.

Quel est selon vous l'intérêt de cette approche ?

C'est une bonne idée, mais pour le framework mono ou le noyau .net pas pour le framework eto. Les avantages sont évidents. Eto -> gtk# -> noyau mono/.net -> gtk+ -> xwindow. Uniquement eto -> noyau mono/.net -> wayland.

Je peux me tromper, mais il semble que Wayland ne fournisse qu'un compositeur. Il ne semble pas fournir d'API de dessin pour dessiner des lignes, des dégradés, des textures, etc. C'est ce que fournirait quelque chose comme le Caire et le fait très bien. Je n'envisage pas Eto.Forms d'implémenter sa propre API de dessin qui s'affiche dans un tampon, car cela réinventerait la roue et le ferait probablement mal.

Cependant, j'ai souvent réfléchi à la création de gestionnaires dessinés personnalisés pour chacun des contrôles d'Eto (tels que Button, TextBox, etc.) à l'aide de l'API Eto.Drawing. Cela signifierait qu'il suffirait d'envelopper les gestionnaires Eto.Drawing pour une plate-forme afin de la prendre en charge (si vous ne vous souciez pas de son apparence visuelle).

Eto.Forms enveloppe déjà le Caire (qui prend en charge wayland), il s'agirait donc simplement de créer des gestionnaires personnalisés pour chaque contrôle et nous pouvons au moins découper GTK+. Ceci, cependant, est encore beaucoup de travail. Si quelqu'un est assez enthousiaste, ce serait un ajout bienvenu et je pourrais aider à démarrer, mais je ne serai pas en mesure de faire une grande partie du travail.

Y a-t-il encore quelqu'un qui s'intéresse à cette idée ? J'ai réussi à créer une liaison vers Wayland qui permet à C# d'utiliser Wayland pour créer facilement une interface utilisateur. Je prévois de finaliser la conception avant de télécharger un dépôt pour cela. (Il s'agit essentiellement d'utiliser la bibliothèque DL pour charger dynamiquement la bibliothèque Wayland native qui est la même bibliothèque que Mono utilise pour importer des fonctions DLL et s'interfacer directement avec elle. Pas besoin de bibliothèque intermédiaire pour gérer P/Invoke entre Wayland et C #.) Je suis aussi en utilisant ImageSharp au lieu de Cairo (Le Caire ne peut apparemment pas interagir directement avec la mémoire tampon partagée, méprisant mes efforts.)

Je ne vois vraiment pas pourquoi ce problème est même une chose... Que gagneriez-vous ?

Éliminer les besoins en dépendances GTKSharp et GTK est une tâche importante. Wayland est relativement rapide et suffisamment flexible pour que nous puissions utiliser des bibliothèques comme Skia, OpenGL, ImageSharp ou d'autres encore pour répertorier les bibliothèques pour rendre notre Eto.Form plutôt que de s'en tenir à une bibliothèque très lourde comme GTK, nous pouvons opter pour un plus petit et plus mince interface utilisateur qui offre plus d'options aux utilisateurs, en particulier dans l'environnement intégré ( https://www.youtube.com/watch?v=GtXQJ0c5q0k pour voir comment Wayland est utilisé sur un appareil ARM).

Comment diable pourriez-vous rendre un bouton avec juste wayland sans relayer sur gtk/qt tout en lui donnant un aspect natif ?

Vous le dessinez, soit par des images pour rendre les bordures, soit par du code. C'est plus facile que vous ne le pensez et ressemble beaucoup à la conception de sites Web HTML. ImageSharp fournit de nombreuses fonctionnalités similaires à Gimp pour C# pour faciliter cette tâche afin que nous ayons déjà une chose en cours.

Vous le dessinez, soit par des images pour rendre les bordures, soit par du code. C'est plus facile que vous ne le pensez et ressemble beaucoup à la conception de sites Web HTML.

Le but d'Eto Forms est de fournir une interface utilisateur native pour la plate-forme, ce que ce problème demande serait plus approprié pour un projet comme : https://github.com/AvaloniaUI/Avalonia

Et mon argument est toujours valable, nous pouvons créer une plate-forme C# sous Eto pour fournir une interface utilisateur native qui peut fonctionner sur toutes les plates-formes, pas seulement Linux.

Et mon argument est toujours valable, nous pouvons créer une plate-forme C# sous Eto pour fournir une interface utilisateur native qui peut fonctionner sur toutes les plates-formes, pas seulement Linux.

Vous feriez un dessin personnalisé, l'interface utilisateur n'aura pas l'air native.

Je suppose que dans cet environnement, il n'y aurait pas d'autre boîte à outils d'interface utilisateur, donc il n'y aurait pas de "natif". J'ai souvent pensé à créer des gestionnaires thématiques qui se résument tous à des contrôles Drawable, qui nécessiteraient simplement l'implémentation d'une pile de dessins. Cependant, @cra0zy a raison en ce sens qu'Avalonia est déjà plus dans ce sens et je pense qu'il a déjà un backend skia en préparation.

Donc, vous dites que le projet Eto ne sera pas ouvert aux alternatives et s'en tiendrait simplement à des bibliothèques gonflées comme GTK, malgré le fait qu'il soit possible de s'en éloigner ?

@CsharpOnLinuxDev non, je suis ouvert à cela. Restreindre ce qu'est Eto n'a aucun sens, et si vous (ou quelqu'un) pensez que ce serait un excellent cadre sur lequel baser des plates-formes alternatives, alors je le soutiens pleinement. Je pense qu'il existe certainement un cas d'utilisation pour prendre en charge des plates-formes sans kits d'outils d'interface utilisateur existants comme GTK ou QT pour les plates-formes embarquées. Il pourrait également être utilisé pour prendre en charge les fenêtres avec .NET Core, ce qui semble être le souhait de beaucoup de gens.

Cela étant dit, je n'ai aucun cycle pour développer ou maintenir une telle plate-forme, donc tout progrès à ce sujet devra venir de la communauté. Il ne doit pas non plus nécessairement faire partie du référentiel principal d'Eto, n'importe qui peut créer une implémentation de plate-forme pour Eto et la publier comme bon lui semble. (;

Je peux (comme toujours) fournir de l'aide et des conseils à tous ceux qui le demandent.

Salut, y a-t-il des progrès à ce sujet? Wayland sera-t-il intégré à Eto ?

Eh bien, si vous utilisez le backend Gtk 3, vous utilisez déjà wayland ...

@cra0zy Merci pour votre réponse !
Mais je veux dire eto -> mono/.net core -> wayland , pas Eto -> gtk# -> mono/.net core -> gtk3 -> wayland .

En fait, j'essaie de trouver un warpper wayland C#. ??