Eto: [Req] Soporte de backend nativo de wayland (C # puro)

Creado en 21 nov. 2015  ·  17Comentarios  ·  Fuente: picoe/Eto

Wayland es un protocolo: https://en.wikipedia.org/wiki/Wayland_ (display_server_protocol)

El protocolo se puede implementar en C # puro o como enlaces para libwayland-client
http://www.jlekstrand.net/jason/projects/wayland/language-bindings-guide/
libwayland-server y libwayland-client se publicaron bajo la licencia MIT.

Los kits de herramientas más respetuosos cuentan con el soporte de Wayland: http://wayland.freedesktop.org/toolkits.html

"En particular, esto debería proporcionar una transparencia de red viable para el audio" (???)

help wanted

Todos 17 comentarios

¡Gracias por la sugerencia! Sin embargo, ¿por qué nos uniríamos directamente a wayland cuando ya usamos GTK (que se encuentra en la cima de wayland)? ¿No reinventa esto la rueda? Por lo que tengo entendido, tendríamos que implementar todos los widgets, la funcionalidad de ventanas, etc.

¿Cuál cree que es el beneficio de este enfoque?

Es una buena idea, pero para mono framework o .net core no para eto framework. Las ventajas son obvias. Eto -> gtk # -> mono / .net core -> gtk + -> xwindow. Solo eto -> mono / .net core -> wayland.

Podría estar equivocado, pero parece que Wayland solo proporciona un compositor. No parece proporcionar una api de dibujo para dibujar líneas, degradados, texturas, etc. Esto es lo que proporcionaría algo como el cairo y lo hace muy bien. No imagino que Eto.Forms implemente su propia api de dibujo que se renderiza en un búfer, ya que esto reinventaría la rueda y probablemente lo haría mal.

Sin embargo, a menudo me he planteado la creación de controladores dibujados personalizados para cada uno de los controles de Eto (como Button, TextBox, etc.) utilizando la api de Eto.Drawing. Esto significaría que uno solo tendría que envolver los controladores de dibujo de Eto.Drawing para una plataforma con el fin de admitirla (si no le importa cómo se ve visualmente).

Eto.Forms ya envuelve cairo (que es compatible con wayland), por lo que solo sería cuestión de crear controladores personalizados para cada control y al menos podemos eliminar GTK +. Esto, sin embargo, es todavía mucho trabajo. Si alguien está lo suficientemente interesado, esta sería una adición bienvenida y podría ayudar a comenzar, pero no podré hacer gran parte del trabajo.

¿Hay alguien todavía interesado en esta idea? Me las arreglé para crear un enlace a Wayland que permite a C # usar Wayland para crear una interfaz de usuario con facilidad. Planeo finalizar el diseño antes de cargar un repositorio para él. (Básicamente, se usa la biblioteca DL para cargar dinámicamente la biblioteca Wayland nativa, que es la misma biblioteca que Mono usa para importar funciones DLL e interactuar directamente con ella. No se necesita una biblioteca intermedia para manejar P / Invoke entre Wayland y C #). haciendo uso de ImageSharp en lugar de Cairo (Cairo aparentemente no puede interactuar con el búfer de memoria compartida y desprecia directamente mis esfuerzos).

Realmente no veo por qué este problema es siquiera una cosa ... ¿Qué ganarías?

Eliminar las necesidades de dependencias GTKSharp y GTK es muy importante. Wayland es relativamente rápido y lo suficientemente flexible como para que podamos usar bibliotecas como Skia, OpenGL, ImageSharp u otras para listar bibliotecas para renderizar nuestro Eto.Form en lugar de seguir con una biblioteca muy chucky como GTK, podemos optar por una biblioteca más pequeña y más delgada interfaz de usuario que brinda más opciones a los usuarios, especialmente en entornos integrados (https://www.youtube.com/watch?v=GtXQJ0c5q0k para ver cómo se usa Wayland en el dispositivo ARM).

¿Cómo demonios renderizarías un botón con solo wayland sin transmitir en gtk / qt y aún así hacer que parezca nativo?

Lo dibujas, ya sea por imágenes para renderizar los bordes o por código. Es más fácil de lo que piensa y se parece mucho al diseño web HTML. ImageSharp proporciona muchas características similares a Gimp para C # para facilitar esa tarea, de modo que ya tenemos una cosa.

Lo dibujas, ya sea por imágenes para renderizar los bordes o por código. Es más fácil de lo que piensa y se parece mucho al diseño web HTML.

El objetivo de Eto Forms es proporcionar una interfaz de usuario nativa para la plataforma, lo que pide este problema sería más adecuado para un proyecto como: https://github.com/AvaloniaUI/Avalonia

Y mi punto sigue en pie, podemos hacer una plataforma C # bajo Eto para proporcionar una interfaz de usuario nativa que pueda funcionar en todas las plataformas, no solo en Linux.

Y mi punto sigue en pie, podemos hacer una plataforma C # bajo Eto para proporcionar una interfaz de usuario nativa que pueda funcionar en todas las plataformas, no solo en Linux.

Sería un dibujo personalizado, la interfaz de usuario no se verá nativa.

Supongo que en este entorno, no habría ningún otro conjunto de herramientas de interfaz de usuario, por lo que no habría nada llamado "nativo". A menudo he pensado en crear controladores temáticos que se reduzcan a controles dibujables, que solo requerirían la implementación de una pila de dibujos. Sin embargo, @ cra0zy tiene razón en que Avalonia ya está más en esa línea y creo que ya tiene un backend de skia en proceso.

Entonces, ¿estás diciendo que el proyecto Eto no estará abierto a alternativas y simplemente se quedaría con bibliotecas hinchadas como GTK y despreciaría que sea posible alejarse de ellas?

@CsharpOnLinuxDev no, estoy abierto a esto. Restringir lo que es Eto no tiene ningún sentido, y si usted (o alguien) piensa que sería un gran marco para basar plataformas alternativas, entonces lo apoyo completamente. Creo que definitivamente hay un caso de uso para admitir plataformas sin kits de herramientas de interfaz de usuario existentes como GTK o QT para plataformas integradas. También podría usarse para admitir Windows con .NET Core, que parece que mucha gente está ansiosa por hacerlo.

Dicho esto, no tengo ningún ciclo para desarrollar o mantener una plataforma de este tipo, por lo que cualquier progreso en esto tendrá que provenir de la comunidad. Tampoco necesariamente tiene que ser parte del repositorio principal de Eto, cualquiera puede crear una implementación de plataforma para Eto y publicarla como quiera. (;

Sin embargo, yo (como siempre) puedo brindar ayuda y orientación a cualquiera que lo solicite.

Hola, ¿hay algún progreso en esto? ¿Wayland se integrará a Eto?

Bueno, si estás usando el backend de Gtk 3, ya estás usando wayland ...

@ cra0zy ¡ Gracias por tu respuesta!
Pero me refiero a eto -> mono/.net core -> wayland , no a Eto -> gtk# -> mono/.net core -> gtk3 -> wayland .

En realidad, estoy tratando de encontrar un warpper wayland C #. 😃

¿Fue útil esta página
0 / 5 - 0 calificaciones