Eto: [Обязательно] Собственная (чистый C #) серверная поддержка Wayland

Спасибо за предложение! Хотя, зачем нам привязываться напрямую к Wayland, если мы уже используем GTK (который находится на Wayland)? Разве это не изобретение велосипеда? Насколько я понимаю, нам пришлось бы реализовать все виджеты, функции окон и т. Д.

В чем вы видите преимущество этого подхода?

Это хорошая идея, но для монофреймворка или ядра .net не для этого фреймворка. Преимущества очевидны. Это -> gtk # -> ядро ​​mono / .net -> gtk + -> xwindow. Только это -> mono / .net core -> wayland.

Я могу ошибаться, но похоже, что Wayland предоставляет просто композитор. Кажется, он не предоставляет api для рисования для рисования линий, градиентов, текстур и т. Д. Это то, что может предоставить что-то вроде cairo и делает это очень хорошо. Я не предполагаю, что Eto.Forms реализует свой собственный api для рисования, который отображается в буфер, поскольку это приведет к переизобретению колеса и, вероятно, сделает это плохо.

Однако я часто задумывался о создании настраиваемых обработчиков рисования для каждого элемента управления Eto (например, Button, TextBox и т. Д.) С помощью API Eto.Drawing. Это означало бы, что нужно было бы только обернуть обработчики Eto.Drawing для платформы, чтобы поддерживать ее (если вас не волнует, как она выглядит визуально).

Eto.Forms уже обертывает cairo (который поддерживает wayland), так что это просто вопрос создания настраиваемых обработчиков для каждого элемента управления, и мы можем, по крайней мере, вырезать GTK +. Однако это еще большая работа. Если кто-то достаточно заинтересован, это было бы долгожданным дополнением, и я мог бы помочь начать это, но не смогу выполнить большую часть работы.

Кого-нибудь еще интересует эта идея? Мне удалось создать привязку к Wayland, которая позволяет C # с легкостью использовать Wayland для создания пользовательского интерфейса. Я планирую доработать дизайн, прежде чем загружать для него репо. (По сути, он использует библиотеку DL для динамической загрузки собственной библиотеки Wayland, которая является той же библиотекой, которую Mono использует для импорта функций DLL и непосредственного взаимодействия с ней. Нет необходимости в промежуточной библиотеке для обработки P / Invoke между Wayland и C #.) Я также использование ImageSharp вместо Cairo (Cairo, по-видимому, не может взаимодействовать с буфером общей памяти, прямо презирая мои усилия).

Я действительно не понимаю, почему эта проблема вообще актуальна ... Что вы получите?

Устранение необходимости в зависимостях GTKSharp и GTK - важная задача. Wayland относительно быстр и достаточно гибок, чтобы мы могли использовать библиотеки, такие как Skia, OpenGL, ImageSharp или другие, еще не перечисляющие библиотеки для рендеринга нашего Eto.Form, вместо того, чтобы придерживаться очень сложной библиотеки, такой как GTK, мы можем пойти на меньшую и более тонкую пользовательский интерфейс, который предоставляет пользователям больше возможностей, особенно во встроенной среде (https://www.youtube.com/watch?v=GtXQJ0c5q0k, чтобы увидеть, как Wayland используется на устройстве ARM).

Как, черт возьми, вы визуализируете кнопку с помощью только wayland без ретрансляции на gtk / qt и при этом сохраняете естественный вид?

Вы рисуете его либо изображениями для визуализации границ, либо кодом. Это проще, чем вы думаете, и очень похоже на веб-дизайн HTML. ImageSharp предоставляет множество функций, подобных Gimp для C #, чтобы упростить эту задачу, так что то, что мы уже сделали.

Вы рисуете его либо изображениями для визуализации границ, либо кодом. Это проще, чем вы думаете, и очень похоже на веб-дизайн HTML.

Цель Eto Forms - предоставить собственный пользовательский интерфейс для платформы, то, что задает эта проблема, было бы более подходящим для такого проекта, как: https://github.com/AvaloniaUI/Avalonia

И моя точка зрения по-прежнему остается в силе, мы можем создать платформу C # под Eto, чтобы обеспечить собственный пользовательский интерфейс, который может работать на всех платформах, а не только на Linux.

И моя точка зрения по-прежнему остается в силе, мы можем создать платформу C # под Eto, чтобы обеспечить собственный пользовательский интерфейс, который может работать на всех платформах, а не только на Linux.

У вас будет собственный рисунок, пользовательский интерфейс не будет выглядеть родным.

Думаю, в этой среде не было бы другого инструментария пользовательского интерфейса, поэтому не было бы такого понятия, как «родной». Я часто думал о создании тематических обработчиков, которые все сводятся к элементам управления Drawable, для которых просто потребуется реализовать стек рисования. Тем не менее, @ cra0zy прав в том, что

Итак, вы говорите, что проект Eto не будет открыт для альтернатив и будет просто придерживаться раздутых библиотек, таких как GTK, презирая возможность отказа от них?

@CsharpOnLinuxDev нет, я открыт для этого. Ограничивать то, что такое Eto, не имеет никакого смысла, и если вы (или кто-либо) думаете, что это была бы отличная среда для создания альтернативных платформ, то я полностью это поддерживаю. Я думаю, что определенно есть вариант использования для поддержки платформ без существующих наборов инструментов пользовательского интерфейса, таких как GTK или QT для встроенных платформ. Его также можно использовать для поддержки окон с .NET Core, что, кажется, многие люди не выдерживают.

При этом у меня нет никаких циклов для разработки или поддержки такой платформы, поэтому любой прогресс в этом вопросе должен исходить от сообщества. Он также не обязательно должен быть частью основного репозитория Eto, любой может создать реализацию платформы для Eto и опубликовать ее, как ему нравится. (;

Я (как всегда) могу предоставить помощь и рекомендации любому, кто об этом попросит.

Привет, есть ли в этом прогресс? Будет ли Wayland интегрирована в Eto?

Что ж, если вы используете бэкэнд Gtk 3, вы уже используете Wayland ...

@ cra0zy Спасибо за ответ!
Но я имею в виду eto -> mono/.net core -> wayland , а не Eto -> gtk# -> mono/.net core -> gtk3 -> wayland .

На самом деле я пытаюсь найти обходной С # варпер. 😃