Hello Forum,

some time ago I started research about a proper way to bring DOM-Based GUI to a unified Application/Game solution. During that process, I came across a Problem in the C# language Framework: System.Windows.Forms. It is quite legacy but the standard way of accessing a Window in C# (at least if you don't want to strugle with WPF). As of .NET 5 is out for some time right now, there is no port of Winforms to Linux right now.

Browsing the Internet for an alternative solution, I came across some solutions that aim to target Windows/Linux at least (MAC is not required as we don't want to support it) but are either too monolithic for “just” handling a Window, old and deprectaed or wrappers around C++ libraries and/or the former monolithic solutions.

I know this is a difficult topic as Windows and Linux are different in some aspects but I'd like to have a lightweight library that just handles Windows (Win32/X11), Clipboard, Drag n Drop and Tray Icons.

Does anyone know of a good source for such a library or at least a library which is easier to extract just the window handling from then it is for example in Mono or Avalonia?

Thanks in advance!

I've found something promising but unfortunately seems to be slowing down in development right now. However, since it lacks of most essential features like Drag n Drop, we've decided to work along all those projects (Mono.Winforms, AvaloniaUI and Modern.Forms) and craft our own solution for that

The XAML part of WPF and the form designer on WinForms are indeed quite appealing, and do often raise the idea of why they are not cross-platform. One of the main real reasons they are not, is because WinForms and WPF are very Windows focused, with specific legacy API calls designed only to work with windows. Those things unfortunately mean we will probably never see a real 1:1 port for either.

There is actually a mature UI framework that works with C# and is cross platform called GTK#, however you may not have encountered it unless you've ventured into the Mono/MonoDevelop side of things before. It's often forgotten about because it is not as out of the box friendly as it's counterparts.

Personally I've come to the conclusion in recent years after having a similar mindset, that C# desktop development is best kept for Windows only. And instead for cross-platform, it's best to use some of the more modern solutions like Electron. Yea it means you have to write your app in Node.JS, but the ecosystem has become a lot more friendly in recent years. And of course designing using HTML is so much fun.

Good luck on your ventures.

Shaarigan said:
I know this is a difficult topic as Windows and Linux are different in some aspects but I'd like to have a lightweight library that just handles Windows (Win32/X11), Clipboard, Drag n Drop and Tray Icons.

How much of the Windows stuff do you need?

If it is basically just a top level window to put an OpenGL context or such, with clipboard and explorer/etc. drag-drop integration, I feel a lot of applications and libraries just include their own abstractions. If you don't want the native code part and to just PInvoke the system API's directly, you could probably still look at what SDL etc. do as a starting point if not familiar with all the platforms you need.

If you want all the native child controls, layouts, drawing (GDI etc.), then that gets much bigger, and often the functionality doesn't have a direct 1 to 1 mapping between the different desktop environments. The C++ libraries that try and do this are not lightweight, and I think it would take significant time and effort for someone to write a pure .NET one.

kodaloid said:
C# and is cross platform called GTK#

Isn't that just a C# wrapper/binding around the native GTK?

I think the problem is to provide all the desktop stuff in a cross platform manner is really a huge and complicated thing. wxWidgets is the only one that comes to mind that really does it. QT is another but I recall relies on a lot of their own rendering then stylesheets to try and make things look more native. I think both had some effort on .NET bindings, but not sure how much progress there has been, and to make a pure .NET version calling only system APIs, the size of those projects would give an idea how much that is.

And even then, you can't really just develop on one OS, and hope to move it to another and have it really look and behave right… Probably why there are so few such cross platform applications, you still need to spend effort on each one.

Of course if don't want to try for a really native application, I believe a number of applications basically just bundle a web browser and use HTML/CSS for their UI. Not sure about clipboard, etc., wouldn't surprise me if the libs included the abstractions needed there.

SyncViews said:
Isn't that just a C# wrapper/binding around the native GTK?

That's right, it is and I didn't consider it for this reason. @kodaloid Our software is aimed to be as lightweight as possible and we achieved a quite small package size of 900kb only rather than several GB for like Unreal, in order to get started. We also only provide source and don't have any pre-build assemblies. Everything you need to get started is a compatible version of .NET Framework installed and a small command script to initialize the tooling.

I also had issues more than often in the past on building such huge things like GTK from source, for example when the devs have had a different setup than me or required using third-party tools I didn't had installed to convince the compiler. For this reason, our philosophy and so our build and project management tool Hecate avoids complicated project configuration and instead uses a conventional (almost) zero configuration model

SyncViews said:
Of course if don't want to try for a really native application, I believe a number of applications basically just bundle a web browser and use HTML/CSS for their UI.

That's right and I can see some advantages of going this way. Companies like Microsoft also have done it so far for example in Teams, which is also an Electron application. Anyways, I have worked for such a company as well, that developed it's Windows/Mac software in Electron-Edge and I also saw the downsides of doing it like this. It's not just because you have to be a javascript pro but the biggest disadvantage is debugging the entire thing and coming along some interesting issues like I pointed out in my answer to a topic related to this one.

So yes, HTML/CSS is definietly an option but as input source for our UI Engine only!

kodaloid said:
One of the main real reasons they are not, is because WinForms and WPF are very Windows focused

That's true for the reason that they were developed from Microsoft but the overall technique of WPF for example isn't

SyncViews said:
think the problem is to provide all the desktop stuff in a cross platform manner is really a huge and complicated thing

That's also true, especially the more features you want. But as I said, I just need what I pointed out in my initial post, Window management (without child windows, controls etc., just plain Window), Clipboard, Cursor, Drag n Drop and Tray Icon management (the basics needed for editor software). Since C# offers the drawing library and it is also Mono and .NET 5 included, we decided to develop our own GDI based control system which we want to design along the same concepts that Hecate was designed to. This means we have a node-graph and process those nodes through an actor pipeline which has several renderers attached to. A renderer may be for example handling a button-node in order to draw buttons to the Window (and so on). Also adding some WPF inspired reactive property implementation for the MVVM model

SyncViews said:
And even then, you can't really just develop on one OS, and hope to move it to another and have it really look and behave right… Probably why there are so few such cross platform applications, you still need to spend effort on each one.

Agree, that's why I already installed an XServer on my Windows machine, so it'll be possible for me to work on the X11 stuff as well, up to a certain point and everything else will be done from a team member I already have, which is more familiar with Linux. I believe that it'll work for our needs as the features we want are very basic, propably more basic than those cross-platform solutions are aimed to be

kodaloid said:
Personally I've come to the conclusion in recent years after having a similar mindset, that C# desktop development is best kept for Windows only

Probably that's the reason why there isn't much more effort into going cross-platform C# development these days. Honestly, in my mind I thought I don't have to do that on my own since .NET 5 pointed out to be cross-platform and will remove the need to use Mono from know on but as everything Microsoft does, this was a straight lie and will stay a lie for .NET 6 as well! They already announced that there won't be Linux support for MAUI (their approach for multiplatform UI) and I can't understand that. Yes, there are much more Linux distros out there but supporting at least a Major subset will be not that much of an issue in my opinion. I honestly don't see any reason to develop for Mac but that's from a games perspective so there might be a market for Mac C# … anyways, as we don't support Mac but want to go for Linux as well, there must be a solution that works on windows and Linux

Shaarigan said:
Window management (without child windows, controls etc., just plain Window),

So you are intending to then do all your own drawing (e.g. OpenGL?) with your own custom styling / feel?

So in that case, I think as mentioned just browse what things like SDL, SFML, GLFW, Dear IMGUI, etc. did, should be able to take the same underlying API calls and put in C# easily enough. (EDIT: Also there might already be a .NET equivalent for these parts, I never really looked in .NET as all my portable stuff is C/C++ or JS currently)

I don't recall any library just for these specific abstractions, projects seem to have taken the bits as needed, but ones like those I believe had a fairly simple abstraction layer in just a handful of source files.
And is way less platform specific code than say wxWidgets that tries to use the native look and feel on each platform (which interestingly, I think on Linux these days they basically went with GTK for all the advanced controls and few things are just using X11).

The most difficult thing is probably text layout/rendering, as the platforms have somewhat different api's if you don't want to bundle your own copy of some C libs (e.g. freetype+harfbuzz, since they don't come with Windows).

SyncViews said:
So in that case, I think as mentioned just browse what things like SDL, SFML, GLFW, Dear IMGUI, etc. did, should be able to take the same underlying API calls and put in C# easily enough. (EDIT: Also there might already be a .NET equivalent for these parts

I had a lot of research in this direction and no, there isn't something right now which just covers those basic things. Both, Avalonia UI and Mono Winforms have straightly wired everything in a way that the code looks like a house of cards, taking one thing out lets break everything down into peaces. Avalonia is an extreme example of that as the entire platform layer is spread all over not less than 5 different projects.

Honestly, this is an issue of a lot of libraries out there, not just C# but C++ as well. We try to design our SDK in a way that every code module just fulfills exactly one atomic task as a counter philosophy.

SyncViews said:
The most difficult thing is probably text layout/rendering, as the platforms have somewhat different api

As mentioned, we'll use GDI e.g. System.Drawing, which seems to work on Windows as well as Mono/Linux with .NET 5. It already has a text rendering engine somewhat built-in and I guess it will look somewhat similar on all platforms or else I'll find a way to implement a fully managed one using GDI and some glyph rendering.

I already did some experiments with it (based on Winforms but getting the graphics context works via window pointer e.g. X11 equivalent) and we were able to implement an adaptive render buffer (as described in this post)

Shaarigan said:
Both, Avalonia UI and Mono Winforms have straightly wired everything in a way that the code looks like a house of cards,

That kinda sucks. Well the libraries I mentioned seemed to at a glance have a lot of the basic things in some nice separate files.

Shaarigan said:
As mentioned, we'll use GDI e.g. System.Drawing, which seems to work on Windows as well as Mono/Linux with .NET 5.

Ah nice, I didn't realise Microsoft made System.Drawing work on Mac and Linux. So that is nice ?

Although correct me if wrong but it is depending on a libgdiplus.so native library? I guess they assume each platform includes it themselves somewhere since it didn't appear to be in the .NET Core Runtime?
So I guess kinda like using GTK on Windows, but if it is being distributed for you I guess size and whatever build steps it need doesn't really matter.

You're right, it uses libgdiplus on Linux, which is recommendet to install along with .NET 5 in order to function properly. GTK is not mentioned anywhere in the installation process of any .NET Runtime/SDK for Windows so I guess this counts ?