Eto: [필수] 네이티브(순수 C#) wayland 백엔드 지원

제안 감사합니다! 하지만 이미 GTK(wayland 상단에 위치)를 사용하고 있는데 왜 wayland에 직접 바인딩할까요? 이것은 바퀴를 재발명하지 않습니까? 내가 이해한 바에 따르면 우리는 모든 위젯, 창 기능 등을 구현해야 합니다.

이 접근 방식의 이점은 무엇이라고 보십니까?

좋은 생각이지만 eto 프레임워크가 아닌 모노 프레임워크 또는 .net 코어용입니다. 장점은 분명합니다. Eto -> gtk# -> mono/.net 코어 -> gtk+ -> xwindow. eto -> mono/.net 코어 -> wayland만 가능합니다.

내가 틀릴 수도 있지만 Wayland는 단지 합성기를 제공하는 것 같습니다. 선, 그라디언트, 텍스처 등을 그리기 위한 드로잉 API를 제공하지 않는 것 같습니다. 이것은 cairo와 같은 것이 제공하고 매우 잘 수행하는 것입니다. Eto.Forms가 버퍼에 렌더링하는 자체 드로잉 API를 구현하는 것을 상상하지 않습니다. 이렇게 하면 휠이 다시 만들어지고 제대로 작동하지 않을 수 있기 때문입니다.

그러나 Eto.Drawing API를 사용하여 Eto의 각 컨트롤(예: Button, TextBox 등)에 대해 사용자 정의 그려진 핸들러를 만드는 것에 대해 종종 생각했습니다. 이것은 플랫폼을 지원하기 위해 플랫폼에 대한 Eto.Drawing 핸들러만 래핑해야 함을 의미합니다(시각적으로 보이는 방식에 신경 쓰지 않는 경우).

Eto.Forms는 이미 cairo(wayland 지원)를 래핑하므로 각 컨트롤에 대해 사용자 정의 처리기를 생성하기만 하면 되며 최소한 GTK+는 잘라낼 수 있습니다. 그러나 이것은 여전히 ​​많은 작업입니다. 누군가가 충분히 열성적이라면 환영할만한 추가 사항이 될 것이며 시작하는 데 도움이 될 수 있지만 많은 작업을 할 수는 없습니다.

아직도 이 아이디어에 관심이 있는 사람이 주변에 있습니까? C#이 Wayland를 사용하여 사용자 인터페이스를 쉽게 만들 수 있도록 하는 Wayland에 대한 바인딩을 만들었습니다. 리포지토리를 업로드하기 전에 디자인을 마무리할 계획입니다. (기본적으로 DL 라이브러리를 사용하여 기본 Wayland 라이브러리를 동적으로 로드하는 것입니다. 이 라이브러리는 Mono가 DLL 함수를 가져오고 직접 인터페이스하는 데 사용하는 것과 동일한 라이브러리입니다. Wayland와 C# 간의 P/Invoke를 처리하기 위해 중간 라이브러리가 필요하지 않습니다.) 저도 Cairo 대신 ImageSharp 사용(Cairo는 분명히 공유 메모리 버퍼와 상호 작용할 수 없으며 내 노력을 직접 경멸합니다.)

왜이 문제가 문제인지 정말 모르겠습니다 ... 무엇을 얻을 수 있습니까?

GTKSharp 및 GTK 종속성에 대한 필요성을 제거하는 것은 큰 일입니다. Wayland는 Skia, OpenGL, ImageSharp와 같은 라이브러리를 사용할 수 있을 만큼 충분히 빠르고 유연합니다. Eto.Form을 렌더링하기 위해 아직 라이브러리를 나열하지 않은 기타 라이브러리는 GTK와 같은 매우 거친 라이브러리를 고수하는 대신 더 작고 슬림한 라이브러리를 사용할 수 있습니다. 특히 임베디드 환경에서 사용자에게 더 많은 옵션을 제공하는 사용자 인터페이스(ARM 장치에서 Wayland가 어떻게 사용되는지 보려면 https://www.youtube.com/watch?v=GtXQJ0c5q0k).

도대체 어떻게 gtk/qt를 중계하지 않고 그냥 wayland로 버튼을 렌더링하고 여전히 기본적으로 보이도록 만들 수 있습니까?

이미지로 테두리를 렌더링하거나 코드로 그립니다. 생각보다 쉽고 HTML 웹 디자인과 매우 유사합니다. ImageSharp는 C#용 Gimp와 유사한 많은 기능을 제공하여 해당 작업을 쉽게 수행할 수 있도록 합니다.

이미지로 테두리를 렌더링하거나 코드로 그립니다. 생각보다 쉽고 HTML 웹 디자인과 매우 유사합니다.

Eto Forms의 요점은 플랫폼에 기본 사용자 인터페이스를 제공하는 것입니다. 이 문제에서 요구하는 것은 https://github.com/AvaloniaUI/Avalonia 와 같은 프로젝트에 더 적합할 것입니다.

그리고 제 요점은 여전히 ​​유효합니다. Eto에서 C# 플랫폼을 만들어 Linux뿐만 아니라 모든 플랫폼에서 작동할 수 있는 기본 사용자 인터페이스를 제공할 수 있습니다.

그리고 제 요점은 여전히 ​​유효합니다. Eto에서 C# 플랫폼을 만들어 Linux뿐만 아니라 모든 플랫폼에서 작동할 수 있는 기본 사용자 인터페이스를 제공할 수 있습니다.

사용자 정의 그림이 될 것이며 UI는 기본적으로 보이지 않을 것입니다.

이 환경에서는 다른 UI 툴킷이 없으므로 '네이티브'라는 것이 없을 것입니다. 나는 종종 그리기 스택을 구현하기만 하면 되는 Drawable 컨트롤로 요약되는 테마 핸들러를 만드는 것을 생각했습니다. 그러나 @cra0zy 는 Avalonia가 이미 그 라인에 더 가깝고 이미 작업 중인 Skia 백엔드가 있다고 믿습니다.

그래서 당신은 Eto 프로젝트가 대안에 열려 있지 않고 GTK와 같은 부풀려진 라이브러리를 고수할 것이라는 말입니까?

@CsharpOnLinuxDev 아니요, 저는 이에 대해 열려 있습니다. Eto가 무엇인지를 제한하는 것은 의미가 없으며, 귀하(또는 누군가)가 대체 플랫폼의 기반이 되는 훌륭한 프레임워크가 될 것이라고 생각한다면 전적으로 지지합니다. 임베디드 플랫폼용 GTK나 QT와 같은 기존 UI 툴킷이 없는 플랫폼을 지원하는 유스 케이스가 분명히 있다고 생각합니다. 또한 .NET Core가 있는 창을 지원하는 데 사용할 수도 있습니다.

즉, 그러한 플랫폼을 개발하거나 유지 관리할 주기가 없으므로 이에 대한 모든 진전은 커뮤니티에서 이루어져야 합니다. 또한 반드시 기본 Eto 리포지토리의 일부일 필요는 없으며 누구나 Eto용 플랫폼 구현을 만들고 원하는 대로 게시할 수 있습니다. (;

나는 (항상) 요청하는 사람에게 도움과 안내를 제공할 수 있습니다.

안녕하세요, 이것에 진전이 있습니까? Wayland가 Eto에 통합됩니까?

글쎄, 당신이 Gtk 3 백엔드를 사용하고 있다면 당신은 이미 wayland를 사용하고 있습니다 ...

@cra0zy 답변 감사합니다!
하지만 eto -> mono/.net core -> wayland 가 아니라 Eto -> gtk# -> mono/.net core -> gtk3 -> wayland 입니다.

사실 저는 wayland C# 워퍼를 찾으려고 합니다. 😃