6 ms·

> Electron and PHPDesktop might be considered the future of desktop development as they allow rapid development of desktop like software. And unfortunately als

by bmitc 4y ago

> 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.

jventura 4y ago
You got my curiosity. Any links to share?
- bmitc 4y ago
  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.
wooque 4y ago
>Flutter and Electron can't even manage multiple windows How so? I use multi window Electron apps, VS Code is one of them
- makeitdouble 4y ago
  Do your VS Code windows interact with each other? I think parent is thinking about a behavior like the tool panels in Photoshop.
  - sleazebreeze 4y ago
    I work on an Electron app that has multiple windows interacting with each other in all kinds of ways. It's quite possible.
    - bmitc 4y ago
      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. https://www.electronjs.org/docs/latest/tutorial/process-model https://www.electronjs.org/docs/latest/tutorial/process-mode... This is not how native desktop applications handle multiple windows, although they could obviously.
  - jaredklewis 4y ago
    Yea, it can be done: https://www.electronjs.org/docs/latest/tutorial/ipc https://www.electronjs.org/docs/latest/tutorial/ipc
    - bmitc 4y ago
      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)
323 4y ago
> I really don't see any massive barrier to creating a cross-platform, desktop-only GUI framework Developer adoption is a big one. Why should I trust your NewGui to still be updated and improved 5 years from now? Even Microsoft has a whole graveyard of dead GUI frameworks (WinForms anyone?)
- bmitc 4y ago
  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.
- the_only_law 4y ago
  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.
  - markdoubleyou 4y ago
    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.
  - RugnirViking 4y ago
    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++
karencarits 4y ago
So true. I love tools like https://tiddlywiki.com/ 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!
warning26 4y ago
> Because for a team of competent folks, I really don't see any massive barrier to creating a cross-platform, desktop-only GUI framework 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.
- Macha 4y ago
  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.
  - ryandrake 4y ago
    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.
    - karencarits 4y ago
      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...
    - krapp 4y ago
      >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.
scythe 4y ago
>wxWidgets 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.
- bmitc 4y ago
  I'm not sure there's no interest. See the uptake in Electron apps. And people are chomping at the bit for Flutter to fully support all desktop OSs.
  - DomesticMouse 4y ago
    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 https://github.com/sony/flutter-embedded-linux Disclosure: I'm a Developer Relations Engineer for Flutter
    - bmitc 4y ago
      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 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 https://github.com/flutter/flutter/issues/30701. The original issue has been sitting around for four years.
nicoburns 4y ago
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.
- bmitc 4y ago
  > 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#.
JasonFruit 4y ago
> the gap left by GTK, Qt... What happened to Qt? As far as I've seen, it's actively developed and as good as ever.
- bmitc 4y ago
  By "gap left" I mean gap in usability and complexity. All those frameworks are both complex and limited.
  - sudosysgen 4y ago
    Hmm, perhaps I'm missing something, but for most apps, I don't really see how you could do it much simpler than Qt does.
AshamedCaptain 4y ago
> 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.
- bmitc 4y ago
  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.
  - pessimizer 4y ago
    Electron is extremely complex too, seeing as it embeds a webview.
    - bmitc 4y ago
      I absolutely agree with that, and that's why I don't want to use it either. Flutter is intriguing, but it uses Dart, something I'm not interested in.
  - indymike 4y ago
    > (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.
dragonwriter 4y ago
> 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.
eloisius 4y ago
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.

by bmitc 4y ago

jventura 4y ago

You got my curiosity. Any links to share?

bmitc 4y ago
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.

wooque 4y ago

>Flutter and Electron can't even manage multiple windows How so? I use multi window Electron apps, VS Code is one of them

makeitdouble 4y ago
Do your VS Code windows interact with each other? I think parent is thinking about a behavior like the tool panels in Photoshop.
- sleazebreeze 4y ago
  I work on an Electron app that has multiple windows interacting with each other in all kinds of ways. It's quite possible.
  - bmitc 4y ago
    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. https://www.electronjs.org/docs/latest/tutorial/process-model https://www.electronjs.org/docs/latest/tutorial/process-mode... This is not how native desktop applications handle multiple windows, although they could obviously.
- jaredklewis 4y ago
  Yea, it can be done: https://www.electronjs.org/docs/latest/tutorial/ipc https://www.electronjs.org/docs/latest/tutorial/ipc
  - bmitc 4y ago
    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)

323 4y ago

> I really don't see any massive barrier to creating a cross-platform, desktop-only GUI framework Developer adoption is a big one. Why should I trust your NewGui to still be updated and improved 5 years from now? Even Microsoft has a whole graveyard of dead GUI frameworks (WinForms anyone?)

bmitc 4y ago
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.
the_only_law 4y ago
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.
- markdoubleyou 4y ago
  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.
- RugnirViking 4y ago
  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++

karencarits 4y ago

So true. I love tools like https://tiddlywiki.com/ 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!

warning26 4y ago

> Because for a team of competent folks, I really don't see any massive barrier to creating a cross-platform, desktop-only GUI framework 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.

Macha 4y ago
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.
- ryandrake 4y ago
  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.
  - karencarits 4y ago
    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...
  - krapp 4y ago
    >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.

scythe 4y ago

>wxWidgets 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.

bmitc 4y ago
I'm not sure there's no interest. See the uptake in Electron apps. And people are chomping at the bit for Flutter to fully support all desktop OSs.
- DomesticMouse 4y ago
  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 https://github.com/sony/flutter-embedded-linux Disclosure: I'm a Developer Relations Engineer for Flutter
  - bmitc 4y ago
    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 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 https://github.com/flutter/flutter/issues/30701. The original issue has been sitting around for four years.

nicoburns 4y ago

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.

bmitc 4y ago
> 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#.

JasonFruit 4y ago

> the gap left by GTK, Qt... What happened to Qt? As far as I've seen, it's actively developed and as good as ever.

bmitc 4y ago
By "gap left" I mean gap in usability and complexity. All those frameworks are both complex and limited.
- sudosysgen 4y ago
  Hmm, perhaps I'm missing something, but for most apps, I don't really see how you could do it much simpler than Qt does.

AshamedCaptain 4y ago

> 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.

bmitc 4y ago
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.
- pessimizer 4y ago
  Electron is extremely complex too, seeing as it embeds a webview.
  - bmitc 4y ago
    I absolutely agree with that, and that's why I don't want to use it either. Flutter is intriguing, but it uses Dart, something I'm not interested in.
- indymike 4y ago
  > (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.

dragonwriter 4y ago

> 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.

eloisius 4y ago

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.