3 ms·
The reality is I can just target winforms on windows, or GDI if I need that. To open a window there is exactly one way if I want it. To open a window on Linux
by jpc0 2y ago
The reality is I can just target winforms on windows, or GDI if I need that.
To open a window there is exactly one way if I want it.
To open a window on Linux do I call into X11 or wayland? Do I need to also provide a DRM layer for incase it needs to be run directly ontop of DRM because BIG_USER_WITH_MONEY wants that.
Should I use QT to get a decent UI library, or GTK, or one of the many other less popular ones.
As a developer that would want to release a GUI app it's not extremely easy to pick for linux. There's no clear guidelines stating X has these features but Y doesn't (winforms vs whatever Microsoft's latest attempt at UI is).
Let's not even get into actually needing to ship a fully cross platform app. C# is blessed on windows, swift on MacOS and C on linux... Which means all the business logic will end up at the very least exporting a C API if I'm not deciding to just bite the bullet and pay QT.
All this ia why you will likely find that someone will develop a Windows release and maybe MacOS if they have a userbase that can justify the development cost. Maybe they are nice and run a test on wine and treat that as a supported platform but I only know of exactly one company that does that outside of maybe some game devs.
And that doesn't even touch anything in the article on why Linux on the desktop won't happen because the 1% of devs that went down this rocky road then also finds ABI breaks.
- neonsunset 2y ago> C# is blessed on windows Not as much anymore. Part of it due to the mess that is the first-party Microsoft's GUI frameworks situation, part of it due to .NET's own APIs and semantics not evolving together with Windows since long time ago. Funny anecdata: someone* recently made a small app to indicate when (now broken) CTRL+C is actually triggered in Windows. It was initially written in WPF and was exhibiting a weird unmanaged memory leak. Only after porting it to Avalonia (which works everywhere) the issue went away: https://x.com/KooKiz/status/1873726346897330243 https://x.com/KooKiz/status/1873726346897330243 So your experience might actually be better with a cross-platform GUI framework! Mind you, it's still in its "homeland" on Windows - things like access to Registry are part of the standard library, but you may find it performing better on Unix systems otherwise. The IO abstractions certainly do! * well, not someone but one of the co-authors of Pro .NET Memory Management.
- jpc0 2y agoHis journey tracks exactly what I've heard from windows development. If you need more than winforms use avalonia because Microsoft cannot create a viable UI toolkit... Which is extremely funny concidering the article we are having a discussion under... My point however was that compared to C# you are fighting an uphill battle using any other language to do native windows UI development... Also why I stopped looking pretty early into native on windows and built a webapp...
- neonsunset 2y agoWell, Uno (AvaloniaUI's competitor) uses WinUI 3 as a back-end on Windows. And NAOT-compiled Avalonia on Windows is practically native anyway. You can use both to build against macOS too if you want to target both major OSes. The offerings have improved significantly over the years. But yes, I get your point, if you're not familiar with C# (or Dart or Kotlin for that matter), there is motly a one way out in the form of a web app.
- yjftsjthsd-h 2y ago> The reality is I can just target winforms on windows, or GDI if I need that. And the reality is that you can just target GTK on Linux. That you happen to have picked a single option on NT doesn't magically make it different, it just means you already made the decision.
- jpc0 2y agoWhich version of GTK should I pick since you seem so confident? And should I target X or Wayland? Which Wayland extensions are ubiquitous enough so that I don't need to manually reimplement things in my app? Should I target pipewire for audio? Pulse? If I pick a modern stack like Wayland + GTK 4 + pipewire it might not work on older linux distros. Maybe that's fine for my needs, maybe it's not. If I pick X + GTK 3 + pulse I might end up reimplementing half of the desktop manager in my app and need to constantly rewrite my app. Do I distribute deb/rpm or do I distribute a flatpack/snap... Actually which one. And don't bring up that GTK abstracts Wayland/X because if I target Wayland I have access to a ton of Wayland extensions which aren't there in X so I do need to make that decision the moment I need to get access to that stuff. So even just picking GTK I now have a matrix of 9 different configurations. GTK is not the defacto framework on linux. We now need to add QT to the mix and the whole collection of things there.
- yjftsjthsd-h 2y agoIt seems like you've picked 1 option for Windows and decided that it's perfect, and then looked at every single remotely possible option on Linux, and then pretended that that was somehow a fair comparison. If we use every GUI toolkit that Microsoft has ever offered, and also every sound API they've ever offered, and also every distribution format (do you use the store? .msi? bundle up a Portable App so you don't need an installer?), your matrix will also blow up.
- jpc0 2y agoFeel free to look at the other comment thread here for my opinion on windows toolkits. But to answer ypur question, if I pick winforms + an exe + wasapi for audio it will work on all supported versions of windows and I don't need to compromise on features. It will very likely also work under wine on linux and macos for that matter...