Eto: [Req] Suporte de back-end de wayland nativo (C # puro)

Obrigado pela sugestão! Porém, por que nos ligaríamos diretamente ao wayland quando já usamos GTK (que fica em cima do wayland)? Isso não reinventa a roda? Pelo que entendi, teríamos que implementar todos os widgets, funcionalidade de janelas, etc.

O que você vê como benefício dessa abordagem?

É uma boa ideia, mas para o framework mono ou .net core não para o framework eto. As vantagens são óbvias. Eto -> gtk # -> mono / .net core -> gtk + -> xwindow. Apenas eto -> núcleo mono / .net -> wayland.

Posso estar errado, mas parece que a Wayland apenas fornece um compositor. Ele não parece fornecer uma API de desenho para desenhar linhas, gradientes, texturas, etc. Isso é o que algo como o Cairo forneceria e o faz muito bem. Não imagino o Eto.Forms implementando sua própria API de desenho que renderiza em um buffer, já que isso reinventaria a roda e provavelmente faria mal.

No entanto, sempre ponderei a criação de manipuladores de desenho personalizados para cada um dos controles do Eto (como Button, TextBox, etc) usando a API Eto.Drawing. Isso significaria que seria necessário apenas agrupar os manipuladores Eto.Drawing de uma plataforma para suportá-la (se você não se importar com a aparência visual).

Eto.Forms já envolve cairo (que suporta wayland), então seria apenas uma questão de criar manipuladores personalizados para cada controle e podemos pelo menos cortar GTK +. Isso, no entanto, ainda dá muito trabalho. Se alguém estiver interessado o suficiente, isso seria uma adição bem-vinda e eu poderia ajudar a começar, mas não poderei fazer muito do trabalho.

Ainda existe alguém interessado nesta ideia? Consegui criar uma ligação para o Wayland que permite que o C # use o Wayland para criar a interface do usuário com facilidade. Pretendo finalizar o design antes de enviar um repositório para ele. (Basicamente, está usando a biblioteca DL para carregar dinamicamente a biblioteca nativa do Wayland, que é a mesma biblioteca que o Mono usa para importar funções DLL e fazer interface diretamente com ela. Não há necessidade de biblioteca intermediária para lidar com P / Invoke entre Wayland e C #.) fazendo uso de ImageSharp em vez de Cairo (Cairo aparentemente não pode interagir com o buffer de memória compartilhada, despreza diretamente meus esforços.)

Eu realmente não vejo porque esse problema é uma coisa ... O que você ganharia?

Eliminar as necessidades de dependências GTKSharp e GTK é um grande problema. Wayland é relativamente rápido e flexível o suficiente para que pudéssemos usar bibliotecas como Skia, OpenGL, ImageSharp ou outras para listar bibliotecas para renderizar nosso Eto.Form em vez de ficar com uma biblioteca muito chucky como GTK, podemos ir para uma biblioteca menor e mais estreita interface de usuário que oferece mais opções aos usuários, especialmente em ambiente embarcado (https://www.youtube.com/watch?v=GtXQJ0c5q0k para ver como o Wayland é usado no dispositivo ARM).

Como no mundo você renderizaria um botão apenas com wayland sem retransmitir em gtk / qt e ainda o faria parecer nativo?

Você desenha, seja por imagens para renderizar as bordas ou por código. É mais fácil do que você pensa e muito parecido com o design da web em HTML. ImageSharp fornece muitos recursos semelhantes ao Gimp para C # para tornar essa tarefa mais fácil para o que já fizemos.

Você desenha, seja por imagens para renderizar as bordas ou por código. É mais fácil do que você pensa e muito parecido com o design da web em HTML.

O objetivo do Eto Forms é fornecer interface de usuário nativa para a plataforma, o que esse problema está pedindo seria mais adequado para um projeto como: https://github.com/AvaloniaUI/Avalonia

E meu ponto ainda é válido, podemos fazer uma plataforma C # sob Eto para fornecer uma interface de usuário nativa que pode funcionar em todas as plataformas, não apenas no Linux.

E meu ponto ainda é válido, podemos fazer uma plataforma C # sob Eto para fornecer uma interface de usuário nativa que pode funcionar em todas as plataformas, não apenas no Linux.

Você seria um desenho personalizado, a IU não parecerá nativa.

Eu acho que neste ambiente, não haveria qualquer outro kit de ferramentas de IU, então não haveria algo como 'nativo'. Eu sempre pensei em criar manipuladores temáticos que se resumem a controles Drawable, o que exigiria apenas uma pilha de desenho para ser implementada. No entanto, @ cra0zy está certo em que Avalonia já é mais nesse sentido e eu acredito que já tem um back-end do skia em desenvolvimento.

Então você está dizendo que o projeto Eto não estará aberto a alternativas e apenas ficaria com bibliotecas inchadas como GTK desprezam que seja possível se afastar delas?

@CsharpOnLinuxDev não, estou aberto a isso. Restringir o que é Eto não faz sentido, e se você (ou qualquer pessoa) acha que seria uma ótima estrutura para basear plataformas alternativas, então eu apoio totalmente isso. Acho que definitivamente há um caso de uso para oferecer suporte a plataformas sem kits de ferramentas de IU existentes, como GTK ou QT para plataformas incorporadas. Ele também pode ser usado para oferecer suporte a janelas com .NET Core, o que parece que muitas pessoas estão ansiosas.

Dito isso, não tenho nenhum ciclo para desenvolver ou manter essa plataforma, então qualquer progresso terá que vir da comunidade. Também não precisa necessariamente fazer parte do repositório Eto principal, qualquer pessoa pode criar uma implementação de plataforma para Eto e publicá-la como quiser. (;

Eu (como sempre) posso fornecer ajuda e orientação para qualquer pessoa que pedir.

Olá, há algum progresso nisso? O wayland será integrado ao Eto?

Bem, se você está usando o backend Gtk 3, você já está usando o wayland ...

@ cra0zy Obrigado pela sua resposta!
Mas quero dizer eto -> mono/.net core -> wayland , não Eto -> gtk# -> mono/.net core -> gtk3 -> wayland .

Na verdade, estou tentando encontrar um wayland C # warpper. 😃