> Electron and PHPDesktop might be considered the future of desktop development as they allow rapid development of desktop like software.
And unfortunately also Flutter.
I am developing my own cross-platform, desktop-only GUI system. It is rough going for me, but the ideas in it are really not that hard. What surprises me is that no company has stepped up to fill the gap left by GTK, Qt, wxWidgets, and the OS-specific frameworks other than Flutter and Electron. Flutter and Electron can't even manage multiple windows. It's a shame. Because for a team of competent folks, I really don't see any massive barrier to creating a cross-platform, desktop-only GUI framework. And for some reason, academia doesn't seem to be interested at all in GUIs and other such things, despite there being a lot of interesting and difficult problems.
Hah, WinForms is still my go-to for quick Windows GUIs. Perhaps is WPF used CSS instead of god awful XML boilerplate overrides for styling I might use that.
Same here! Hard to match WinForms productivity for small apps, especially if you cut your teeth in the 90's VB era. And you can push WinForms really far with the fancy controls in the Syncfusion Community License.
Winforms is absolubtely my go-to as well after using it briefly at work for a project around 2015. It was old then, but I really liked the way it worked, it was sensible and c# is always easy compared to c++
I doubt I ever release mine, if I even complete it. For companies that can manage this, there's no reason why they couldn't obtain adoption. Just look at Electron, Flutter, VS Code, etc.
Microsoft is one of the examples of what not to do. They have made great strides with .NET Core and now .NET 6+, but I have no idea why they're doing what they're doing in the GUI scene.
There's an attempt to make this work for Rust desktop applications. There's the winit crate, which does cross-platform windowing and event loops. There's egui, for menus and subwindows. There's rfd, for file dialogs, which are special for security reasons. And there's wgpu, for cross-platform 3D.
I'm using all of these in my ui-mock,[1] which is a GUI for a game without the game. It has 3D graphics with 2D GUI elements on top. I'm using this to shake down all the cross-platform problems for my metaverse client. My own code, which is 100% safe Rust, has no platform dependent code.
Results are pretty good. There's minor dirty laundry in those libraries, which has been reported to the various maintainers. Stuff like this:
- You can get a file dialog hidden behind the main window, which, in a full screen program, is a real problem. Mostly a Linux problem; works fine on Windows.
- Full screen on Windows mode under Wine 7 crashes Wine. Known Wine bug.
- Warnings from WGPU, but it works around all of them with some minor performance loss.
- Cross-platform packaging, to make a Windows installer without Windows, isn't implemented yet.
So, not big stuff. A lot of stuff works that you might not expect to work, such as profiling with tracy. Wgpu is taking care of Vulkan vs Apple's Metal. (Apple just had to Think Different, to the annoyance of everybody doing 3D.) Opening a web page in the default browser is cross-platform. You can cross-compile - I build the Windows version on Linux, without using any Microsoft tools.
With some more work, I could make this work on WASM and Android as well, but that requires some special casing, mostly because WASM doesn't have proper threads.
So cross-platform desktop development is working pretty well. Most of the problems I'm running into would not appear in a more typical application.
Incidentally, if there's anyone into Windows installers and Rust, see [1][2] There's a Rust bundler for making installers cross-platform. Mac is done, Linux is partly done, and Windows needs someone familiar with the arcane world of Windows install files.
Worth noting for c (and hence your niche language of choice via ffi) there is also glfw for windowing and webgpu-native which is from the same folk as wgpu.
EDIT: and also libuv which is the cross platform event loop for node.
> Here's one: cross-platform GUI apps will, without exception, feel subtly wrong on every platform. Each platform has its own "way" of doing things.
Is that really true though? No one cares about this for webapps, so why do they care about it on desktop apps? In my opinion, this is one thing that web apps have taught people, in that there isn't much sense anymore about having OS-specific "look and feel", if that is even a thing, and I think the OS-makers agree because even Windows and macOS are chock full of inconsistencies. And in general, I hate moving across apps, like Visual Studio and Outlook for example, that adopt the OS-isms of their host OS, because it means you gotta learn the same app twice.
About the only real difference are the way menu bars, toolbars, and docking are handled, and probably file pickers. Outside of that, I don't see why an app that looks the same across three different OSs is bad.
But is subtly feeling wrong a massive barrier? And feeling wrong for who - I would guess that it is mostly people who would have done fine without a GUI that would notice, for the others (or us all?), most GUI apps would feel slightly off anyway
>Here's one: cross-platform GUI apps will, without exception, feel subtly wrong on every platform. Each platform has its own "way" of doing things.
You're stating as an objective fact what is you own aesthetic opinion.
Yes, different platforms are different, and the same app behaves differently on different platforms. But most people don't switch platforms or use the same app on different platforms routinely, and it wasn't an issue prior to Electron, when the most likely manifestation of this would be the use of the same browser on different platforms.
You’re reading it the wrong way around I think. Think in terms of cross platform applications that try to fit in on their host application, except they aren’t using the native widgets, similar to what Qt did historically.
Then you have something that looks as if it should behave like a certain widgets you’re used to, except they behave in subtly different ways. That’s where that idea comes from.
Now if you go all 90s WinAmp and create all your own widgets, then that mostly
goes out the window, until you enter a text box…
Right, but the alternative is rarely a native app for each platform, it's Electron in most cases.
I imagine you could make something that at least gives you as much opportunity to fit in as electron, with accessibility support, and some new ideas, be it from a development paradigm, inbuilt widget sets, or something else.
I mean, the better (for users, maybe not for developers) alternative is to buck up and build a native client for each platform. Share as much code as you can portably, but you'll have a small platform-specific shim around the edges to call into the shared business logic and implement the platform-specific window management and bling.
Yes, this is very reasonable for some kinds of software. For other kinds of software, the users may consist of a small team - say the teachers at a school or a specific research group or a family - where some are using Mac and others are using Windows
Sometimes, developing a simple tools should be simple (without all the overhead of shared business logic, etc.), but in my experience, there is too many obstacles to make simple GUI tools that just works. It's a shame, I believe that many teams would have increased their efficiency if there were easier ways for individuals to make simple tools adapted to their specific needs. Now, they are typically stuck with Excel...
>but you'll have a small platform-specific shim around the edges to call into the shared business logic and implement the platform-specific window management and bling
No you won't. We've had cross-platform libraries like SDL to do that for ages.
Electron isn't that revolutionary - it's basically just shipping applications in containers. It just happens that the container is a web browser, but it could just as well be the JVM or any language runtime with a GUI layer.
The "interesting" part, if anything, is using a document-based paradigm to build a GUI-driven application, with separation of concerns between code, layout and semantics. But none of that has to be done with webcode.
> Electron isn't that revolutionary - it's basically just shipping applications in containers. It just happens that the container is a web browser
Except that the backend part of the app doesn't run in the browser, it runs in Node. So it's not shipping applications in containers, even if one views a web browser as a container.
> What surprises me is that no company has stepped up to fill the gap left by GTK, Qt, wxWidgets, and the OS-specific frameworks other than Flutter and Electron. Flutter and Electron can't even manage multiple windows. It's a shame.
It's not that these toolkits are gone -- it's that the desktop metaphors you are looking for are gone. Or at least, as gone as these toolkits: neither of which is dead by any measure, but your assumption that they are dead likely comes from the fact that the target users for these have almost completely vanished.
Even most builtin Windows apps these days are single window square boxes with a webpage inside. There is a reason Qt the company was trying like crazy to target the "single window, no widgets, 3D graphics" market.
I don't think they're gone. What I meant by "gap left" is that they are not very good, in that they are extremely complex.
And I don't buy the argument that the market is gone. Everything we interact with on the computer is through a desktop app. The fact that so many apps are written in Electron tells us two things: (1) many people still need to write desktop apps, (2) there is no good cross-platform framework to do so.
> (2) there is no good cross-platform framework to do so.
Chrome and Firefox are pretty good cross-platform frameworks. They are so good than the OS vendors keep coming out with workalikes like Edge and Safari (and by the way, both are really good).
As a software publisher I love it because if it works in Chrome and Firefox, I mostly don't have to even care if you have a Mac, PC, smartphone, or something completely different. You go to my URL, and there it is. Stuff like PWAs and Electron are great, too, because I can make it easier for users to get into my app - just launch the application. No more two step, launch browser, type in URL or click on bookmark.
For web app development, you need, at a minimum, three separate programming languages but typically more, a host server, and a desktop app to render your app. That is not a "good" framework, in my opinion. And the number one thing support people ask is "have you tried it in Chrome?". Isn't that weird thing to ask? "Can you use another desktop app to verify that my app is working or not?"
Web and mobile apps do not support the types of apps and functionality that I am interested in. That's fine that people are happy enough with web and mobile app development. That's also why I do not care to even address those scenarios, not to mention that they are completely different from desktop apps.
> Because for a team of competent folks, I really don't see any massive barrier to creating a cross-platform, desktop-only GUI framework.
The barrier is opportunity cost; there's plenty of actively maintained, cross-platform—often desktop-only or desktop-first—GUI frameworks, both ones with many language bindings and ones that are specific to particular languages. Sure, a competent team could make and maintain another one that maybe fits their preferences better than the existing ones—or they could make a useful app using one of the existing ones.
> And for some reason, academia doesn't seem to be interested at all in GUIs and other such things,
Academia is interested in them if it's about new UI paradigms or something, but not it is just bikeshedding.
This is, in theory, what you're asking for. It's not perfect. But nobody uses it and there are few contributors. In most threads lamenting Electron, it barely gets mentioned. So:
>I really don't see any massive barrier
I think the barrier is a lack of interest. If anyone thinks about building a cross-platform native-widget GUI framework, they only have to consider briefly the near-total obscurity of wxWidgets and how much work it would take (a lot!) to even reach feature parity with the same.
I'm curious which operating systems people are still waiting for. We have delivered Windows, macOS and Linux on stable as of Flutter 3. We don't have plans to add more, but people in the community are working on things like embedded Linux: https://github.com/sony/flutter-embedded-linux
Disclosure: I'm a Developer Relations Engineer for Flutter
Thanks for the update, although it should be pointed out that that was apparently very recent, as in May 2022. It's not like it's been there and makes my comment that people have been waiting on it inaccurate. I wasn't aware of stable macOS and Linux support, so thanks for pointing it out. As far as I know, Windows was the first to get stable desktop support from Flutter, and that was just at the very beginning of this year. Even now, the official Flutter Desktop webpage links back to that release as "new": https://flutter.dev/multi-platform/desktop
Flutter still cannot manage multiple windows on desktop, which makes it a no-go for my use cases, and it doesn't look like it's coming anytime soon: https://github.com/flutter/flutter/issues/30701. The original issue has been sitting around for four years.
It's possible to do, but it's not what I meant. I have four windows open in Visual Studio Code right now, and Visual Studio Code has 81 separate OS processes running. There is not one application, one OS process, nor even one programming language running all of that.
That's a low barrier for what is meant by managing multiple windows.
What I mean by "managing multiple windows" is a single OS-process and application managing multiple windows: creating them, destroying them, hiding them, etc. Electron cannot do this. You are basically creating separate applications that talk to each other through inter-process communication. I mean, it says it right there in the link you posted. The process model of Electron is complex.
Here's how you create multiple windows in my in-work prototype:
let windowing = Windowing()
windowing.Initialize()
windowing.CreateWindow("Window 1")
windowing.CreateWindow("Window 2")
windowing.CreateWindow("Window 3")
while(windowing.WindowsAreOpen) do
System.Threading.Thread.Sleep(100)
Would it be one full electron process for each window ?
That would be quite a load if the user decides each current pane is now an independent window on the screen.
I remember JVM apps hitting this same issue. There are many ways to make two entities talk together (if IPC wasn't an option, a local IP channel would work as well, albeit way more costly), but then the performance would be abysmal, for apps that were already handicapped. Same process windows are way lighter than that.
It's possible in the sense of how webapps do it, because that's basically how Electron does it. Electron creates several different processes that talk to each other through an inter-process communication model. Electron's process model is rather complex.
So true. I love tools like https://tiddlywiki.com/ that *just works* - across platforms, can be shared without problems, and is flexible enough to make all sorts of simple tools without having to use a terminal, add n dependencies and compile things. Please share if you know similar software!
There's also React Native Windows (which despite the name also has a macOS version). It's a little experimental, but Facebook's Messenger app for windows and macOS uses it (and I think Microsoft are shipping something minor using it), so it does have some production usage.
I'm still hopeful we'll get a high-quality cross-platform GUI framework out of the Rust ecosystem at some point. But unfortunately it's looking like it might be at least a decade away at the moment.
> I'm still hopeful we'll get a high-quality cross-platform GUI framework out of the Rust ecosystem at some point. But unfortunately it's looking like it might be at least a decade away at the moment.
Given the way Rust has evolved, I don't really hold much hope that it'll be any better than the existing options. Rust keeps intriguing me, but then I start looking into it, and everything is just extremely complex. I'm not sure I have the time to really learn it or will even like it. For my own work that I'm doing, I'm using F#.
Links to my GUI system? If so, it's early days, and there is nothing public. I am using F#, my own bindings to GLFW, and SkiaSharp, which is an existing .NET binding and library over Skia, to prototype things. At this point, I have a basic windowing system down, and now I'm trying to figure out the right interface to the events that can be sent out to whatever wants them and also basic "widget" elements. But I am considering multiple windows from the start, and I have that working do a decently satisfactory level right now. Things will definitely keep evolving as I learn things though.
To be honest, I never wanted to create this. I originally wanted to experiment with making my own desktop programs but found the existing solutions too unsatisfactory or complicated. I also do not want to use C++. The closest I got was using Racket's GUI toolkit, but I found I was going to have to be writing a lot of custom widgets anyway, and I was also dealing with bugs and slogging through terse documentation.
My personal hunch is that the only gap is a developer training gap. Since ~2014 there were a bunch of copy-pasted bootcamps selling "MEAN stack" or "JAM stack" or whatever, but all of them centered around JavaScript. It seems like the assumption is that everyone does web, so we have to shoe-horn JS into making native apps with tech like Electron, React Native, etc. But, the JavaScript ecosystem is actually very complicated. I'd say it's just as complicated as Qt or GTK, but maybe they lack the kiddie pool introduction that making small JS programs for the browser offers.
If JavaScript isn't your comfort zone or you don't come from frontend web development, Qt in particular is awesome. It comes with a ton of primitives that you don't have to reinvent from scratch. It has UI controls that do the complex stuff you want without having to pile a bunch of event binding code on it. You don't even have to write C++.
It bothers me every time I read about Electron's redeeming quality being that it allows web developers to build native apps. Python is a "web" language, and you don't need to write anything but Python to make a great Qt app. A famous Electron app like Slack could have very well been written by web developers using Python, and I bet it would feel snappier than today's Slack.
Good luck with your GUI system, btw. I'd love to see what you make.
And unfortunately also Flutter.
I am developing my own cross-platform, desktop-only GUI system. It is rough going for me, but the ideas in it are really not that hard. What surprises me is that no company has stepped up to fill the gap left by GTK, Qt, wxWidgets, and the OS-specific frameworks other than Flutter and Electron. Flutter and Electron can't even manage multiple windows. It's a shame. Because for a team of competent folks, I really don't see any massive barrier to creating a cross-platform, desktop-only GUI framework. And for some reason, academia doesn't seem to be interested at all in GUIs and other such things, despite there being a lot of interesting and difficult problems.