Cross-platform GUI Toolkit Trainwreck, 2016 Edition(blog.johnnovak.net)
blog.johnnovak.net
Cross-platform GUI Toolkit Trainwreck, 2016 Edition
http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trainwreck-2016-edition/
74 comments
Yup, love Qt, have been using it since v. 4 for personal stuff, and in the past couple years worked on a cross-platform native GUI app that used Qt professionally.
I'd advise anyone using it to stay away from playing with the stylesheets to customize the look and feel of controls. If you do, you're in for a world of pain, and will shed blood and tears trying to get the app to look consistent and presentable across platforms. Given that cross-platform development is already hard as it is, you don't need that additional difficulty.
I'd advise anyone using it to stay away from playing with the stylesheets to customize the look and feel of controls. If you do, you're in for a world of pain, and will shed blood and tears trying to get the app to look consistent and presentable across platforms. Given that cross-platform development is already hard as it is, you don't need that additional difficulty.
I did an app in wxWidgets a while back, and it was really frustrating how many things didn't work as expected: I spent more time wiring up windows to work correctly than actually coding the app.
I don't know if wxWidgets has gotten any better over the years, and I can't remember the specific details of the problems -- just that certain windows HAD to be parents of certain others in order for them to work, even though there was no obvious reason why this would be the case, and there was no documentation explaining this.
The other two look interesting, though. I'll keep those around for future reference.
I don't know if wxWidgets has gotten any better over the years, and I can't remember the specific details of the problems -- just that certain windows HAD to be parents of certain others in order for them to work, even though there was no obvious reason why this would be the case, and there was no documentation explaining this.
The other two look interesting, though. I'll keep those around for future reference.
I wrote a large wx python app or two in the day and did not have that particular problem.
Good to know. They may have cleaned things up.
Or maybe I was doing something weird. For some reason the projects I'm trying to accomplish always seem to be the thing the library designer didn't anticipate. :|
Or maybe I was doing something weird. For some reason the projects I'm trying to accomplish always seem to be the thing the library designer didn't anticipate. :|
I need to put in a warning about nuklear. As far as I can tell it has no documentation an is very difficult to get to work well in anything but the most trivial case. I put some work into it and came away very disappointed.
Two options that weren't mentioned were Nana and NanoGUI, which are both modern and under active development.
Two options that weren't mentioned were Nana and NanoGUI, which are both modern and under active development.
I use wxWidgets for Tarrasch, a chess GUI project I've been working on for years https://www.triplehappy.com. In general I am pretty happy with it. Largely it "just works" and I can do the things I expect to be able to do in the way I expect to be able to do them.
> I also don’t think that shoehorning web development technologies—which technically don’t provide any advantages over more traditional approaches—into desktop applications is a very sound idea either.
So, isn't sidestepping all of the problems author had with other technologies not an advantage enough? Not only that, using html/css for layout allows for easily created and very flexible responsive layouts which half of the other toolkits can't do at all out-of-the-box. Author seemingly swept this approach under the rug without ever seriously considering it ("I don’t have any personal experience using Light Table", "so developers can use hipster technologies like HTML, CSS and JavaScript", etc), and I can kind of see why he thinks that. But as a frequent user of such applications, I'm willing to take a slight performance hit if that allows me to use the same app on any platform, even if it's size becomes 200 megabytes bigger. Honestly, I'm a bit baffled why people are bothered so much by those 200 MB, it's not a burden to download it, it doesn't take much space on my ssd, or my RAM for that matter.
So, isn't sidestepping all of the problems author had with other technologies not an advantage enough? Not only that, using html/css for layout allows for easily created and very flexible responsive layouts which half of the other toolkits can't do at all out-of-the-box. Author seemingly swept this approach under the rug without ever seriously considering it ("I don’t have any personal experience using Light Table", "so developers can use hipster technologies like HTML, CSS and JavaScript", etc), and I can kind of see why he thinks that. But as a frequent user of such applications, I'm willing to take a slight performance hit if that allows me to use the same app on any platform, even if it's size becomes 200 megabytes bigger. Honestly, I'm a bit baffled why people are bothered so much by those 200 MB, it's not a burden to download it, it doesn't take much space on my ssd, or my RAM for that matter.
>I'm willing to take a slight performance hit if that allows me to use the same app on any platform, even if it's size becomes 200 megabytes bigger.
From personal exeprience, it's beyond slight perf hit. Often js apps are the ones hogging most of the resources on my system.
From personal exeprience, it's beyond slight perf hit. Often js apps are the ones hogging most of the resources on my system.
I don't think it's possible to emphasise this enough.
Slack and Spotify are consistently the worst-performing applications I use frequently, easily by an order of magnitude. Slack manages to absolutely tear through CPU cycles and battery life, while simultaneously being sluggish and shitty to use. Have you ever tried scrolling back in a channel? It's horrifying.
It's got bad enough that I've started to hack together native Mac clients for both in my spare time.
Slack and Spotify are consistently the worst-performing applications I use frequently, easily by an order of magnitude. Slack manages to absolutely tear through CPU cycles and battery life, while simultaneously being sluggish and shitty to use. Have you ever tried scrolling back in a channel? It's horrifying.
It's got bad enough that I've started to hack together native Mac clients for both in my spare time.
That 200M is nothing to you does not make it nothing to everyone. Some of us are working on Raspberry Pi or equivalent hardware, and every MB and Mhz counts.
I doubt amount of such users is substantial. I assume we are talking about business decisions here, and as far as those go ditching 0.1% of userbase to radically simplify development process and architecture is a pretty simple one.
> I doubt amount of such users is substantial
"So screw them. We don't care about their concerns."
This is not a solution. Sure, the majority of users don't care about the performance hit, or size requirement, but solving that problem in a way substantial enough to make those with tighter requirements happy can only help everyone.
I have an 8-core 4ghz CPU, 2 >5tflops GPUs and am not content with the performance of web-based GUI. It's sluggish and bloated. No matter how powerful my system is, I can tell, and it's enough of an issue to warrant complaint.
"So screw them. We don't care about their concerns."
This is not a solution. Sure, the majority of users don't care about the performance hit, or size requirement, but solving that problem in a way substantial enough to make those with tighter requirements happy can only help everyone.
I have an 8-core 4ghz CPU, 2 >5tflops GPUs and am not content with the performance of web-based GUI. It's sluggish and bloated. No matter how powerful my system is, I can tell, and it's enough of an issue to warrant complaint.
Problem is, as author stated there is no such solution right now. It's all about trade offs and in any case you got to sacrifice something. Sure, solving this problem would be amazing and good for all but I know I'm not up to task and there are tons of other people much smarter than me who tried and failed already. I don't think electron is the problem, I just think there are some quirks with it that were not yet ironed out.
> I don't think electron is the problem, I just think there are some quirks with it that were not yet ironed out.
The problem with electron is not that it has quirks, but that it is chromium "ironed out" to be a GUI toolkit. It's effective, and generally well done, considering that fact, but will continue to be noticeably sluggish as long as it even resembles what it was in the first place.
The problem with electron is not that it has quirks, but that it is chromium "ironed out" to be a GUI toolkit. It's effective, and generally well done, considering that fact, but will continue to be noticeably sluggish as long as it even resembles what it was in the first place.
I've built a number of interfaces for applications running on Raspberry Pis using Electron, and it's been great. Space or performance hasn't been an issue. The kiosk mode in Electron is perfect.
The use of "hipster" as a pejorative doesn't even make sense to me here. HTML, CSS, and JavaScript are hipster technologies? They aren't new by any stretch.
Using this term seems like lazy authorship and thinking. Instead of explaining, just call it hipster and assume it's obvious.
Like you said, cross-platform support is the opposite of unimportant. The appeal of the web has a lot to do with the fact that a browser on any platform can (mostly) have the same experience without (too much) extra work. It may not be appropriate for Light Table, but a general hipster-like dismissal of web tech doesn't advance the argument.
Using this term seems like lazy authorship and thinking. Instead of explaining, just call it hipster and assume it's obvious.
Like you said, cross-platform support is the opposite of unimportant. The appeal of the web has a lot to do with the fact that a browser on any platform can (mostly) have the same experience without (too much) extra work. It may not be appropriate for Light Table, but a general hipster-like dismissal of web tech doesn't advance the argument.
This is a great deep-dive into the GUI approaches taken by some nice cross-platform apps, but the author seems to have decided early on to ignore web technologies. It would have been nice to see an Adobe UI broken down, or Spotify, or Steam. (It's not like their HTML/JS-based UIs look any whackier than some of those audio production apps!)
If you have infinite time and need infinitely great performance, writing your own GUI framework on top of each platform's native libraries is probably the way to go. But a huge team of people already built and bulletproofed one called Chromium. It's icky in some ways and abstracted far from the native layer, and it'll probably eat an extra 50ms when someone clicks a button, but you can build and ship a cross-platform app in less than three years. The docs are written, the bugs are known ones, and it's easy to hire people who can help you. Just saying :-)
(full disclosure: I worked on an Electron-based mail client—definitely biased :-) )
If you have infinite time and need infinitely great performance, writing your own GUI framework on top of each platform's native libraries is probably the way to go. But a huge team of people already built and bulletproofed one called Chromium. It's icky in some ways and abstracted far from the native layer, and it'll probably eat an extra 50ms when someone clicks a button, but you can build and ship a cross-platform app in less than three years. The docs are written, the bugs are known ones, and it's easy to hire people who can help you. Just saying :-)
(full disclosure: I worked on an Electron-based mail client—definitely biased :-) )
Are we looking at the same article? Chromium and Electron are very much mentioned, and the author clearly states their position on the topic.
I'll rephrase: Chromium is a browser. An extremely full-featured browser, made to support the monstrous complexity and the security minefield of 20+ years of web standards piled on top of each other, and an impressive feat of backwards-compatibility allowing us to view ancient websites as well as modern ones using a vast array of different technologies. Great work.
A lot of current laptops come with limited RAM and disk space.
In light of this, the idea of a Chromium-based tea timer seems a little disconnected with reality. Somehow people still do it.
I'll rephrase: Chromium is a browser. An extremely full-featured browser, made to support the monstrous complexity and the security minefield of 20+ years of web standards piled on top of each other, and an impressive feat of backwards-compatibility allowing us to view ancient websites as well as modern ones using a vast array of different technologies. Great work.
A lot of current laptops come with limited RAM and disk space.
In light of this, the idea of a Chromium-based tea timer seems a little disconnected with reality. Somehow people still do it.
Horses for courses.
If you're writing a tea timer perhaps chromium isn't the right tool for the job. I'd certainly be the first to agree and the author highlights this too. If your tiny application doesn't add much functionality, I'd even suggest that a multi platform solution isn't necessary.
However, if you are writing a full featured desktop application, it starts to become a sensible option.
If you're writing a tea timer perhaps chromium isn't the right tool for the job. I'd certainly be the first to agree and the author highlights this too. If your tiny application doesn't add much functionality, I'd even suggest that a multi platform solution isn't necessary.
However, if you are writing a full featured desktop application, it starts to become a sensible option.
If your tea-timer only runs on windows 10 with .Net 4.6 installed, that's a bit rubbish isn't it?
Maybe it only took you 2 days to build, but you can't re-use any of that code when you port it to another platforms; ok, so you rewrite it in 2 days for mac. Sure. Maintenance is a bit of a pain but its no big deal.
...but what if it was an app that took 6 months to build, not 2 days?
You're screwed on the delivery and on the maintenance.
I think the point is that there are many examples of electron based applications like slack that have been hugely successful.
Sure, there are other options you could use instead, and it is bloated, and slow, etc. etc.; but there's no denying that its a successful platform, like it or not.
Maybe it only took you 2 days to build, but you can't re-use any of that code when you port it to another platforms; ok, so you rewrite it in 2 days for mac. Sure. Maintenance is a bit of a pain but its no big deal.
...but what if it was an app that took 6 months to build, not 2 days?
You're screwed on the delivery and on the maintenance.
I think the point is that there are many examples of electron based applications like slack that have been hugely successful.
Sure, there are other options you could use instead, and it is bloated, and slow, etc. etc.; but there's no denying that its a successful platform, like it or not.
My daily driver is an i5 Mac Mini, and I find the performance of the Spotify app to be almost unacceptable. Clicking on a playlist is sometimes quick, but sometimes takes 5 seconds or more for it to switch screens. The other day there was the VS Code cursor blinking fiasco[0].
I definitely appreciate the rapid development aspects of Electron. I've used it myself to build a couple of little one-off apps for specific purposes. But, man, I've got my mail client open 24/7, and if it's going to waste my battery life just sitting there, I'm not likely going to be using it for very long. And if it's laggy when I'm trying to quickly rip through my email...
[0] https://github.com/Microsoft/vscode/issues/22900
I definitely appreciate the rapid development aspects of Electron. I've used it myself to build a couple of little one-off apps for specific purposes. But, man, I've got my mail client open 24/7, and if it's going to waste my battery life just sitting there, I'm not likely going to be using it for very long. And if it's laggy when I'm trying to quickly rip through my email...
[0] https://github.com/Microsoft/vscode/issues/22900
Is your mail client always in focus? Because unless this is the case analogy with vs code is not correct, when it loses focus it stops rendering the cursor.
These are the kinds of things that I don't want to even have to think about. The cursor is an example, not an analogy.
To indulge this though, I'm just looking at my cumulative CPU time list on this Mac Mini (not a laptop, so I don't care so much about battery draining and I tend to keep things open and forget about them).
TogglDesktop has used 1h27m of CPU time since I launched it. That's, I'm 99% sure, an Electron app. It's a single window that displays a timer and sends the occasional POST request back to the Toggl servers.
Spotify is at 1h23, but at least it's doing a bunch of audio decoding in the background.
Slack has used 56m of CPU time as well.
I'm a little disturbed to see that Excel has used over 22h, and I've barely used it, but forgot that it was open. Closing that now.
As a decent contrast, I used Remote Desktop for approximately 32hr/wk, and it's sitting at 4h51. That is streaming compressed images/video constantly as it runs.
To indulge this though, I'm just looking at my cumulative CPU time list on this Mac Mini (not a laptop, so I don't care so much about battery draining and I tend to keep things open and forget about them).
TogglDesktop has used 1h27m of CPU time since I launched it. That's, I'm 99% sure, an Electron app. It's a single window that displays a timer and sends the occasional POST request back to the Toggl servers.
Spotify is at 1h23, but at least it's doing a bunch of audio decoding in the background.
Slack has used 56m of CPU time as well.
I'm a little disturbed to see that Excel has used over 22h, and I've barely used it, but forgot that it was open. Closing that now.
As a decent contrast, I used Remote Desktop for approximately 32hr/wk, and it's sitting at 4h51. That is streaming compressed images/video constantly as it runs.
You can make an app that runs like shit with any technology possible, it's not the fault of technology itself. I mean, in the article author was suggesting an option of redrawing the whole window at 60 fps which is also not very efficient and also not electron.
Sure... but when you choose Electron, you're starting off with a 200MB footprint before you've even done anything. And there's so many gotchas, where doing something seemingly innocent causes poor performance (e.g. what the VS Code guys did was totally reasonable, but the underlying Chromium engine did something stupid)
I get that there's a lot of things that Electron makes really nice for doing app development, but there's a tradeoff there: how good is it going to be for development vs. how well is it going to perform? And in a lot of cases, it'll perform just fine. Not nearly as good as the same approach would in an actual native framework, but good enough and with a lot less work.
Re: the 60fps thing, that's exactly what happened in the VS Code example, except it was triggered by CSS. They weren't trying to redraw the window at 60fps, but they were because of a simple chunk of CSS that should have only caused the cursor to change every second.
Anyway, I'm totally speaking from my own experience here, and I agree that it's possible to make software that runs like shit in any language, but every Electron app that I use does run like shit. And these aren't little one-off things, these are apps built by established companies. Toggl is a frickin' timer. How is it possible to make a timer app that is slow to show a pop-up?!
The other question is: if they all have shitty performance, why do I use them? And the answer is: because they're useful. I tolerate them because despite the frustration every day, I still find utility there (and I'm working on a desktop where battery life isn't a concern).
If you've got a good example of an Electron app that doesn't perform poorly compared to an equivalently-designed native app, I'd love to see it! And it'd be awesome if the author of that app could start sharing their techniques, so that all of these well-established companies using Electron could stop making their apps suck at being responsive.
I get that there's a lot of things that Electron makes really nice for doing app development, but there's a tradeoff there: how good is it going to be for development vs. how well is it going to perform? And in a lot of cases, it'll perform just fine. Not nearly as good as the same approach would in an actual native framework, but good enough and with a lot less work.
Re: the 60fps thing, that's exactly what happened in the VS Code example, except it was triggered by CSS. They weren't trying to redraw the window at 60fps, but they were because of a simple chunk of CSS that should have only caused the cursor to change every second.
Anyway, I'm totally speaking from my own experience here, and I agree that it's possible to make software that runs like shit in any language, but every Electron app that I use does run like shit. And these aren't little one-off things, these are apps built by established companies. Toggl is a frickin' timer. How is it possible to make a timer app that is slow to show a pop-up?!
The other question is: if they all have shitty performance, why do I use them? And the answer is: because they're useful. I tolerate them because despite the frustration every day, I still find utility there (and I'm working on a desktop where battery life isn't a concern).
If you've got a good example of an Electron app that doesn't perform poorly compared to an equivalently-designed native app, I'd love to see it! And it'd be awesome if the author of that app could start sharing their techniques, so that all of these well-established companies using Electron could stop making their apps suck at being responsive.
Web technologies only works when the interface is the primary feature. Spotify is a music player, Steam is a game launcher. There isn't that much functionality under the hood. On the other hand if you only need performance, or functionality, something like Qt works. What's hard with "applications for professionals" is that you need both. I doubt Adobe mainly uses web technologies in their creative suite.
What I find a better alternative to Electron is to use the browser control of JavaFX (WebKit). You can program your UI in HTML/CSS/JS, and interact very easily with business logic written in Java, Scala, Clojure, Kotlin, Groovy, Ceylon, etc. (also JS, if you want). JavaFX comes included with the standard JVM. I imagine this approach will get even better with Java 9, especially the size of distributables.
In a world where all the apps are Electron based computers have no memory left and everything is subtly or outright sluggish.
My favorite cross-platform GUI toolkit ever was/is Cocotron:
http://cocotron.org
Let's face it, macOS is the only desktop platform where users give a shit about whether apps look native and use system-provided controls. Mac is also the platform that has the nicest standard UI framework (Linux doesn't have one and Windows is forever haunted by Win32 despite Microsoft's 15 years of trying to push XAML).
Hence it makes sense to build desktop GUIs for Mac first, on the Mac, and cross-compile to other targets. Cocotron delivered just that: a minimalist BSD implementation of Foundation + AppKit, with a footprint light enough that you won't be ashamed to ship it as a DLL with your Windows app.
I've used Cocotron a couple of years ago for some custom graphics apps that needed to be deployed on Windows (one was a title creation app for a TV game show, just to design the graphics they needed for each weekly episode). It worked great. Even accounting for Cocotron's missing pieces and bugs, the UX of Cocoa-on-Windows was lightyears better than what people were used to when it comes to custom Windows apps.
Unfortunately Apple hasn't really made life easy for Cocotron because the platform has moved ahead so fast and Objective-C has accumulated tons of slightly warty features for Swift bridging.
The original OpenStep/Cocoa was clean, small and designed to be portable with light compiler support. Today, Apple APIs are a sprawling foundation for the iOS ecosystem, and it's in Apple's interest to keep making the API surface bigger and harder to port so that nobody can pull off what Microsoft tried with their iOS bridge [1]. (Obviously I don't blame Apple in any way, just feeling slightly nostalgic.)
[1] https://developer.microsoft.com/en-us/windows/bridges/ios
http://cocotron.org
Let's face it, macOS is the only desktop platform where users give a shit about whether apps look native and use system-provided controls. Mac is also the platform that has the nicest standard UI framework (Linux doesn't have one and Windows is forever haunted by Win32 despite Microsoft's 15 years of trying to push XAML).
Hence it makes sense to build desktop GUIs for Mac first, on the Mac, and cross-compile to other targets. Cocotron delivered just that: a minimalist BSD implementation of Foundation + AppKit, with a footprint light enough that you won't be ashamed to ship it as a DLL with your Windows app.
I've used Cocotron a couple of years ago for some custom graphics apps that needed to be deployed on Windows (one was a title creation app for a TV game show, just to design the graphics they needed for each weekly episode). It worked great. Even accounting for Cocotron's missing pieces and bugs, the UX of Cocoa-on-Windows was lightyears better than what people were used to when it comes to custom Windows apps.
Unfortunately Apple hasn't really made life easy for Cocotron because the platform has moved ahead so fast and Objective-C has accumulated tons of slightly warty features for Swift bridging.
The original OpenStep/Cocoa was clean, small and designed to be portable with light compiler support. Today, Apple APIs are a sprawling foundation for the iOS ecosystem, and it's in Apple's interest to keep making the API surface bigger and harder to port so that nobody can pull off what Microsoft tried with their iOS bridge [1]. (Obviously I don't blame Apple in any way, just feeling slightly nostalgic.)
[1] https://developer.microsoft.com/en-us/windows/bridges/ios
> Let's face it, macOS is the only desktop platform where users give a shit about whether apps look native and use system-provided controls.
Citation VERY MUCH needed. I'm on windows, and I care about applications using native widgets. I mostly care because non-native widgets tend to have horrible performance, but windows does have at least some consistent styles (there are several, but there is some consistency), and a lot of custom windowing libraries just look horrible, and more importantly, behave inconsistently.
I'll generally be willing to use odd-looking GUIs, but when you have an odd-looking GUI that has different behaviour then is standard, it really annoys the hell out of me.
Citation VERY MUCH needed. I'm on windows, and I care about applications using native widgets. I mostly care because non-native widgets tend to have horrible performance, but windows does have at least some consistent styles (there are several, but there is some consistency), and a lot of custom windowing libraries just look horrible, and more importantly, behave inconsistently.
I'll generally be willing to use odd-looking GUIs, but when you have an odd-looking GUI that has different behaviour then is standard, it really annoys the hell out of me.
The right-click menu is a different style between the desktop and the title bar. Right out the gate there are so many inconsistencies in Windows I can really see where the person you're replying to is coming from.
Case in point, if you want to change some setting in w10 you may want to look in one of the following locations: Control panel (1), Control panel (2), Registry, Group Policy Editor, some random menu or other program you need to launch. Really screams "consistency" doesn't it?
I agree with your example completely.
However this doesn't mean users don't appreciate native widgets and UI consistency. In fact, this is a common complaint for windows, something that Microsoft is currently working on (at what ever pace)
Microsoft is firmly in the backwards compatibility at all costs camp - something which I definitely appreciate. This however comes at a cost and your example is one of them. I'm not suggesting this is not avoidable, but the complexity should not be understated.
However this doesn't mean users don't appreciate native widgets and UI consistency. In fact, this is a common complaint for windows, something that Microsoft is currently working on (at what ever pace)
Microsoft is firmly in the backwards compatibility at all costs camp - something which I definitely appreciate. This however comes at a cost and your example is one of them. I'm not suggesting this is not avoidable, but the complexity should not be understated.
For cross platform GUIs I use CAPI[1] from Lispworks, and was one of the main reasons I purchased it after using free Common Lisp implementations for many years. It's a well designed and stable system for building native guis on macOS, Windows, Linux, Solaris and others with a single code base and well worth the price of admission for creating desktop software.
[1] http://www.lispworks.com/products/capi.html
[1] http://www.lispworks.com/products/capi.html
Speaking of the lisp family... I don't know how it's implemented, but Racket has a cross-platform GUI story that, based on some of my cursory explorations, seems to be good. DrRacket is presumably built on it, and that's a non-trivial cross-platform app.
http://docs.racket-lang.org/gui/index.html
http://docs.racket-lang.org/gui/index.html
It's a bit barebones, but it's very easy to use. You can also generate standalone executables effortlessly.
it's a pleasure to use, but takes up a huge amount of ram (~100M just to use the gui framework)
Racket seems to utilize GTK under-the-hood, which has a terrible accessibility story.
Racket uses cocoa for macos, win32 for windows, gtk+ for linux.
But it is really minimal and you may find feature lacking.
For anyone interested in how Racket (Matthew Flatt) pulled it off : http://blog.racket-lang.org/2010/12/rebuilding-rackets-graph...
[deleted]
It looks excellent, and I love cl, but it's just too expensive.
These days there's also qtools which is pretty good.
Unfortunately Qtools (or, more precisely, CommonQt) was not ported to Qt5 yet, and thus looks ugly on hidpi displays :(
For me, accessibility is important, too, which rules out immediate mode or canvas-based GUIs. And there are not just desktop, but web and mobile platforms. Like Nim, it would be nicer if there were a better language and framework designed with all this in mind. Elm and others don't seem to be it. Dojo toolkit was great at accessibility but I guess it is a bit out of date now. I know this may not be popular here, but Dart (and Flutter) might be the best option, at least for my needs.
I'm reasonably happy with (Py)Qt for my cross-platform file manager [1]. I didn't use Electron because its startup time is way too slow. I wrote a blog post about this choice, and which other GUI technologies I considered [2].
[1]: https://fman.io
[2]: https://fman.io/blog/picking-technologies-for-a-desktop-app-...
[1]: https://fman.io
[2]: https://fman.io/blog/picking-technologies-for-a-desktop-app-...
If you need to wish to keep it bloatless, there are still unfashionable ways to go, like Tk and Fltk.
Sadly fallen out of use and favour, but straightforward and battlehardened with a charming tendency to Just Work.
Sadly fallen out of use and favour, but straightforward and battlehardened with a charming tendency to Just Work.
You don't even need to go that far. Qt and GTK are just as fast unless you are using a very underpowered system.
fltk is orders of magnitude less bloated than either of those.
It certainly is. When I run it on a system from >10 years ago, I can definitely tell the difference. With the systems I use now, however, the difference is a negligible one.
tk is so awesome. took me a while to grasp the auto resize things, but then you truly understand the genius of it.
I mentioned this a few days ago, but it's a shame he didn't look further into Java. NodeBox may or may not be slow but it isn't doing the same thing as the other apps, and like any GUI toolkit, it's easy for developers to make it slow.
Spine (http://esotericsoftware.com/) is a pro-level skeletal 2D animation app written in Java, though you wouldn't know it from the website. Judging from the videos of it in action it has no trouble doing high speed UI refreshes. Additionally there are lots of slick 60fps animations on Android written in Java too.
So whilst the article is interesting in a way, I do feel like he just blows off quite workable solutions for no better reason than a dubious extrapolation of a single app to all possible apps using that framework. Heck, he even says it looks nice - redraw speed was literally his only issue. Maybe it's just not using buffering very well?
Spine (http://esotericsoftware.com/) is a pro-level skeletal 2D animation app written in Java, though you wouldn't know it from the website. Judging from the videos of it in action it has no trouble doing high speed UI refreshes. Additionally there are lots of slick 60fps animations on Android written in Java too.
So whilst the article is interesting in a way, I do feel like he just blows off quite workable solutions for no better reason than a dubious extrapolation of a single app to all possible apps using that framework. Heck, he even says it looks nice - redraw speed was literally his only issue. Maybe it's just not using buffering very well?
I'm not sure about the difficulty of interfacing with Nim, but I've heard nothing but good things about the Lazarus IDE. It has visual layout tools, it compiles quickly and executables are reasonably small.
http://www.lazarus-ide.org/
http://www.lazarus-ide.org/
I'm having a hard time believing that re-drawing a UI 60 times per second would actually consume 100% of a CPU core. unless implemented in a way that causes spending too much time in the opengl driver (lots of pipeline state changes? extraneous drawcalls?) and making your program CPU bound. Seeing some code would be nice.
Also, you don't have to actually redraw the entire screen. You can use the stencil buffer to render only the parts that need to be updated (i.e. the UI pane).
Also, look into signed distance field technique for text rendering. Valve has a paper on it, look it up. My friend used it in his game, the text is scalable and looks great.
Also, you don't have to actually redraw the entire screen. You can use the stencil buffer to render only the parts that need to be updated (i.e. the UI pane).
Also, look into signed distance field technique for text rendering. Valve has a paper on it, look it up. My friend used it in his game, the text is scalable and looks great.
I've used nanovg and I'm not sure what the author is talking about. The text looks great and I've never seen it use a noticeable amount of CPU. Maybe he was doing UIs that were much more complicated, but the drawing is still being done by openGL, only the vector to triangle conversion is being done on the CPU as far as I know.
In the past I wrote a cross-platform (it supports iOS, Android, and more esotic platforms, like QNX, even on exotic architectures like MIPS) 2D vector graphics rendering engine that implements the Khronos OpenVG 1.1 API (that includes text rendering too). It's lightweight, comes with pure software and opengl/es back-end, closed-source and not free; but if you want to take a look just for fun, full functional evaluation builds are available here for download: http://www.amanithvg.com
Nobody mentioned Xamarin?
You can target Windows, macOS, Linux, iOS, Android.
https://www.xamarin.com/platform
https://www.xamarin.com/platform
i was very hopeful about that, but the toolchain just felt too immature on linux :( still keeping an interested eye on it.
[deleted]
FireMonkey is pretty good these days:
https://www.embarcadero.com/products/rad-studio
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/FireMonkey
https://www.embarcadero.com/products/rad-studio
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/FireMonkey
But clearly targeting enterprise developers:
https://www.embarcadero.com/app-development-tools-store/rad-...
https://www.embarcadero.com/app-development-tools-store/rad-...
if you only take Delphi the price is a little bit better
(still not great)
https://www.embarcadero.com/app-development-tools-store/delp...
and there is not Linux version of FMX either, they just released Linux-Server-only (e.g. apache modules etc) support, for which you have to buy the enterprise version (ugh)
but you can create Android, IOS and macOS Apps with it https://www.embarcadero.com/docs/rad-studio-feature-matrix.p...
and there is not Linux version of FMX either, they just released Linux-Server-only (e.g. apache modules etc) support, for which you have to buy the enterprise version (ugh)
but you can create Android, IOS and macOS Apps with it https://www.embarcadero.com/docs/rad-studio-feature-matrix.p...
I have an old abandoned project inspired by ex widgets.... in assembly. Sometimes I think it might be worth getting back into it just for the GUI part as a lightweight framework, but assembly is so intimidating sometimes.
Honestly because of its package executable nature, I would probably try to do something in go instead.
Honestly because of its package executable nature, I would probably try to do something in go instead.
That would be interesting to have a look at. I'm still yet to properly get into assembly myself, but there isn't enough graphical stuff done in asm out there.
This post is like a copy paste of this one: https://news.ycombinator.com/item?id=13952140
Other way around. This post was published first.
no mention of Adobe AIR which can build GUI app for desktop and mobile
for example: Balsamiq Mockups [0]
also tons of case studies [1]
[0]: https://balsamiq.com/products/mockups/ [1]: http://www.adobe.com/products/air/showcase.html
for example: Balsamiq Mockups [0]
also tons of case studies [1]
[0]: https://balsamiq.com/products/mockups/ [1]: http://www.adobe.com/products/air/showcase.html
AIR doesn't run on Linux, which I believe was a requirement for the author.
Adobe AIR 2.6 does run on Linux
"Supported distributions include Fedora Core 11, Ubuntu 9.04 and OpenSuSe 11.1." And you have to install a ton of 32-bit dependencies.
This is abandoned and insecure. A Linux user would only do this if they were desperate to run an AIR app and were willing to compromise the integrity of their system to do so.
This is abandoned and insecure. A Linux user would only do this if they were desperate to run an AIR app and were willing to compromise the integrity of their system to do so.
[0] https://github.com/wxWidgets/wxWidgets
[1] https://github.com/vurtun/nuklear
[2] https://github.com/andlabs/libui