Eto: [Req] Native (pure C#) wayland backend support

Thanks for the suggestion! Though, why would we bind directly to wayland when we already use GTK (which sit atop wayland)? Doesn't this reinvent the wheel? From what I understand, we'd have to implement all widgets, windowing functionality, etc.

What do you see as the benefit to this approach?

It is good idea, but for mono framework or .net core not for eto framework. The advantages are obvious. Eto -> gtk# -> mono/.net core -> gtk+ -> xwindow. Only eto -> mono/.net core -> wayland.

I could be wrong, but it appears that Wayland just provides a compositer. It does not appear to provide a drawing api to draw lines, gradients, textures, etc. This is what something like cairo would provide and does it very well. I don't envision Eto.Forms implementing its own drawing api that renders to a buffer, since this would re-invent the wheel and probably do it poorly.

However, I have often pondered creating custom drawn handlers for each of Eto's controls (such as Button, TextBox, etc) using the Eto.Drawing api. This would mean that one would only have to wrap the Eto.Drawing handlers for a platform in order to support it (if you don't care about how it looks visually).

Eto.Forms already wraps cairo (which supports wayland), so it would just be a matter of creating custom-drawn handlers for each control and we can at least cut out GTK+. This, however, is still a lot of work. If someone is keen enough, this would be a welcome addition and I could help get this started, but won't be able to do much of the work.

Is there anyone still around interested in this idea? I've managed to create a binding to Wayland that enables C# to use Wayland to create User Interface with ease. I plan on finalizing the design before uploading a repo for it. (It's essentially using DL library to dynamically load native Wayland library which is the same library that Mono uses for importing DLL functions and interface directly with it. No needs for intermediate library to handle P/Invoke between Wayland and C#.) I'm also making use of ImageSharp instead of Cairo (Cairo apparently can't interacts with the shared memory buffer directly despise my efforts.)

I really don't see why this issue is even a thing... What would you gain?

Eliminating the needs for GTKSharp and GTK dependencies is a big one. Wayland is relatively fast and flexible enough that we could use libraries like Skia, OpenGL, ImageSharp, or other yet to list libraries to render our Eto.Form rather than sticking with very chucky library like GTK, we can go for a smaller and more slim user interface that provides more options to the users especially in embedded environment ( https://www.youtube.com/watch?v=GtXQJ0c5q0k to see how Wayland is used on ARM device).

How in the world would you render a button with just wayland without relaying on gtk/qt and still make it look native?

You draw it, either by images to render the borders or by code. It's easier than you think and much akin to HTML web designing. ImageSharp provides a lot of features similar to Gimp for C# to make that task easy so that one thing we have going already.

You draw it, either by images to render the borders or by code. It's easier than you think and much akin to HTML web designing.

The point of Eto Forms is to provide native user interface for the platform, what this issue is asking would be more suitable for a project like: https://github.com/AvaloniaUI/Avalonia

And my point still stands, we can make a C# Platform under Eto to provide native user interface that can work across all platforms, not just Linux.

And my point still stands, we can make a C# Platform under Eto to provide native user interface that can work across all platforms, not just Linux.

You would be custom drawing, the UI will not look native.

I guess in this environment, there wouldn't be any other UI toolkit so there'd be no such thing as 'native'. I've often thought of creating themed handlers which all boil down to Drawable controls, which would just require a drawing stack to be implemented. However, @cra0zy is right in that Avalonia is more along those lines already and I believe already have a skia backend in the works.

So you're saying that the Eto project will not be open to alternatives and would just stick with bloated libraries like GTK despise that it's possible to move away from those?

@CsharpOnLinuxDev no, I am open to this. Restricting what Eto is doesn't make any sense, and if you (or anyone) thinks it would be a great framework to base alternative platforms on, then I fully support that. I think there is definitely a use case to support platforms without existing UI toolkits like GTK or QT for embedded platforms. It could also be used to support windows with .NET Core, which is seems a lot of people are chomping at the bit for.

That being said, I don't have any cycles to develop or maintain such a platform so any progress on this will have to come from the community. It also doesn't necessarily have to be part of the main Eto repo, anyone could create a platform implementation for Eto and publish it however they like. (;

I (like always) can provide help and guidance though, for anyone that asks.

Hi, are there any progress on this? Will wayland be integrated to Eto?

Well if you are using Gtk 3 backend you are already using wayland...

@cra0zy Thanks for your reply!
But I mean eto -> mono/.net core -> wayland, not Eto -> gtk# -> mono/.net core -> gtk3 -> wayland.

Actually I'm trying to find a wayland C# warpper. 😃