Rust GUI ecosystem overview(gitlab.com)
gitlab.com
Rust GUI ecosystem overview
https://gitlab.com/z0mbie42/rust_gui_ecosystem_overview
193 comments
I also don't understand the different "License" ratings for Qt and GTK, given they are both LGPL.
The Qt licencing situation is way more complicated than that. Parts of it are available under LGPL, parts are available under GPL, and some parts are only available under a commercial license which is a minimum of $5500/dev/year.
There's a big chart here:
https://doc.qt.io/qt-5/qtmodules.html#gpl-licensed-addons
There's a big chart here:
https://doc.qt.io/qt-5/qtmodules.html#gpl-licensed-addons
But all of the extras parts that are not under the LGPL are things that GTK (nor Electron) doesn't even have, so I would argue it's still an unfair comparison.
I am also baffled by the difference in license ratings. My guess is that some parts of Qt are licensed differently (like their WebAssembly port) and it's not immediately clear which parts are licensed under which license.
Not all Qt libraries are LGPL, some are GPL likce charts.
Hi, thank you for the feedback.
By Look I mean The ability to create advanced UI which are not influenced by the Desktop native theme (as are all successful end user oriented applications). The ability to create a native app which is at least beautiful as modern WebApps.
e.g. Slack or VS Code (Electron) are beautiful, while fractal or notecase (gtk) are not.
By Look I mean The ability to create advanced UI which are not influenced by the Desktop native theme (as are all successful end user oriented applications). The ability to create a native app which is at least beautiful as modern WebApps.
e.g. Slack or VS Code (Electron) are beautiful, while fractal or notecase (gtk) are not.
> (as are all successful end user oriented applications).
That is a very debatable assumption. The large majority of apps I use use the desktop's native theme.
That is a very debatable assumption. The large majority of apps I use use the desktop's native theme.
I don't think this is very debatable. Consider the fact you might be in the vast minority of users.
I'm a dev/technical user, in the key audience for native look & feel powertools, yet the main apps I use on Mac are still Chrome, Spotify, Slack, VS Code. None of these use the desktop's native theme.
Imagine the case for non-technical users.
Average users expect apps to have a custom look and feel. Ever tried SnapChat?
I'm a dev/technical user, in the key audience for native look & feel powertools, yet the main apps I use on Mac are still Chrome, Spotify, Slack, VS Code. None of these use the desktop's native theme.
Imagine the case for non-technical users.
Average users expect apps to have a custom look and feel. Ever tried SnapChat?
> Ever tried SnapChat?
... no
> Imagine the case for non-technical users.
Most non-technical users I know - elderly couples, family, etc don't even install apps, they just use what their OS gives them. I don't know any who does not have VLC or LibreOffice however (but that may be a french thing)
... no
> Imagine the case for non-technical users.
Most non-technical users I know - elderly couples, family, etc don't even install apps, they just use what their OS gives them. I don't know any who does not have VLC or LibreOffice however (but that may be a french thing)
I did say "non-technical", which is open to interpretation, but I did not mean 'computer illiterate' (i.e. only uses apps given by OS).
The discussion here is really about average users, and the baseline assumption here is that we are talking about apps that don't come with the OS, that we'd install, since we're devs, creating new stuff.
> I don't know any who does not have VLC or LibreOffice however [...] (but that may be a french thing)
It's a French or power-user thing.
The discussion here is really about average users, and the baseline assumption here is that we are talking about apps that don't come with the OS, that we'd install, since we're devs, creating new stuff.
> I don't know any who does not have VLC or LibreOffice however [...] (but that may be a french thing)
It's a French or power-user thing.
> I did say "non-technical", which is open to interpretation, but I did not mean 'computer illiterate' (i.e. only uses apps given by OS).
I was about to say "you know that the median mobile-device user has one third-party app installed, right?" but then I thought better and Googled it first. This used to be true, but the stat is far out-of-date; nowadays the median mobile-device user has 40-to-80 apps!
I'm kind of shocked how much user behavior has changed, honestly.
I was about to say "you know that the median mobile-device user has one third-party app installed, right?" but then I thought better and Googled it first. This used to be true, but the stat is far out-of-date; nowadays the median mobile-device user has 40-to-80 apps!
I'm kind of shocked how much user behavior has changed, honestly.
+1000 it's exactly what I'm thinking!
And I also thought about Snapchat as a reference for end user application.
Certainly because it's a model of simplicity and is really far from native themes.
And I also thought about Snapchat as a reference for end user application.
Certainly because it's a model of simplicity and is really far from native themes.
macOS is exactly where people expect native theme. People aren't using the apps you mention because they like the look of them. They're using them because they believe the functionality is better than the native-looking alternatives, or because they have no choice (e.g. with Slack).
> macOS is exactly where people expect native theme
Who are 'people' here? The strawman here is that 'average users' do not expect native theme.
Who are 'people' here? The strawman here is that 'average users' do not expect native theme.
"people" is "most users of the platform". A consistent native platform experience has been one of the cornerstones of macOS since even before OS X came along.
If you ask most people, they probably won't know to identify this as a desirable trait, but what they do know is that if they launch a non-native app it will likely not look or behave according to their expectations. For example, I'm an expert user and even I'm still tripped up by the fact that Slack has a rather anemic menubar, and Discourse's is even worse.
If you ask most people, they probably won't know to identify this as a desirable trait, but what they do know is that if they launch a non-native app it will likely not look or behave according to their expectations. For example, I'm an expert user and even I'm still tripped up by the fact that Slack has a rather anemic menubar, and Discourse's is even worse.
In the native vs not-native look and feel discussion, I hold the opinion that different platforms have different answers. In MacOS, users expect a native look and feel, or at least something close to it.
Windows, Linux and Android users have no such expectations. In fact, in the case of Android, a non-native look and feel could be considered a positive thing since the native android look and feel is kind of terrible.
Windows, Linux and Android users have no such expectations. In fact, in the case of Android, a non-native look and feel could be considered a positive thing since the native android look and feel is kind of terrible.
> or because they have no choice (e.g. with Slack).
Or because they are unaware that there are native apps available, just from third parties. For example: https://volt-app.com/
Or because they are unaware that there are native apps available, just from third parties. For example: https://volt-app.com/
I heard about that a long time ago, back when it looked kind of dead. Glad to see it's still under development. I'm skeptical though, does it actually support all of Slack's features (or even a majority of them)? The screenshot is rather minimal, showing nothing in the way of unfurls, no formatting beyond a link and an @mention, no userlist, no channel info, no pinned messages, no reactions, etc.
I second the 'customization' label (though perhaps themability is a better one?), for me applications that do not use the desktop look and feel are a negative thing and something i try to avoid, so the 'look' is certainly subjective.
> (...) is at least beautiful as modern WebApps.
What? In my dictionary, screenshots of "modern webapps" appear when I search the definition of the word "ugly".
What? In my dictionary, screenshots of "modern webapps" appear when I search the definition of the word "ugly".
Would you consider the Stripe[0] dashboard or Figma[1] ugly? I'm not agreeing with the parent's statement, but whether or not a WebApp or Native App is ugly is impacted more by designers, not implementation.
[0]: https://stripe.com [1]: https://www.figma.com
[0]: https://stripe.com [1]: https://www.figma.com
Yes, they are the worst kind of site and they represent fairly everything that I dislike about the "modern" web. Superfluous animations, not clear where to click, and with an overall design that is so standard that is not evident whether it is a parody or not [0]. I pretty much prefer clean designs with clearly visible links, like wikipedia, or hackernews, or the recently discussed today sourcehut [1]
[0] http://tiffzhang.com/startup
[1] https://git.sr.ht/~sircmpwn/git.sr.ht/tree
[0] http://tiffzhang.com/startup
[1] https://git.sr.ht/~sircmpwn/git.sr.ht/tree
What is good looking in your opinion?
> The ability to create a native app which is at least beautiful as modern WebApps.
I don't consider this desirable or even a reasonable criterion. I want my desktop apps to all use the same toolkit and look consistent. Unless you make a bog-simple app, something like Electron is never going to give you that. With Qt/Gtk/etc. you can certainly make custom widgets if you have special-purpose needs. For someone who comes from a web development background, there's going to be a learning curve for that, of course. But experienced Qt/Gtk developers should not find it meaningfully more difficult.
> e.g. Slack or VS Code (Electron) are beautiful, while fractal or notecase (gtk) are not.
That's incredibly subjective, and I don't agree with it. I think Slack and VS Code are fine looking apps, but I wouldn't rate them meaningfully higher than all the Gtk apps running on my desktop right now. (And regardless, I value consistency over some ill-defined measure of "beauty" when it comes to UI.)
I don't consider this desirable or even a reasonable criterion. I want my desktop apps to all use the same toolkit and look consistent. Unless you make a bog-simple app, something like Electron is never going to give you that. With Qt/Gtk/etc. you can certainly make custom widgets if you have special-purpose needs. For someone who comes from a web development background, there's going to be a learning curve for that, of course. But experienced Qt/Gtk developers should not find it meaningfully more difficult.
> e.g. Slack or VS Code (Electron) are beautiful, while fractal or notecase (gtk) are not.
That's incredibly subjective, and I don't agree with it. I think Slack and VS Code are fine looking apps, but I wouldn't rate them meaningfully higher than all the Gtk apps running on my desktop right now. (And regardless, I value consistency over some ill-defined measure of "beauty" when it comes to UI.)
Slack maybe beautiful, but due to electron, you can't resize even simple things - like the bar on the side with channel/names.
I don't consider Slack beautiful– I think it is really unintuitive. The data flows differently than any native app I use...
Ah ok, make sense this way. "Customization" would be less confusing for me.
I also contend the supposed "ugliness" of gtk. This is at most a personal issue; in my view gtk programs are typically beautiful and Qt and Electron are unbearably ugly.
Definitely depends on the platform. On Linux it's probably great, but on macOS at least, I've yet to see a GTK app that doesn't feel super clunky. GTK breaks lots of expectations about how things should behave on macOS (shortcuts, standard menus, buttons, etc). Gimp or Inkscape are good examples. On the other hand those are examples of what a "native" app is expected to look like:
https://www.sketch.com
https://paw.cloud
https://www.pixelmator.com
Note that the apps above are not implemented with Qt or Electron either, they use the official Apple frameworks.
https://www.sketch.com
https://paw.cloud
https://www.pixelmator.com
Note that the apps above are not implemented with Qt or Electron either, they use the official Apple frameworks.
GIMP and Inkscape are still using the ancient GTK2, GTK3 is generally a lot nicer.
i.e. Transmission uses GTK3 and looks like this[1] on OSX.
[1] https://en.wikipedia.org/wiki/Transmission_(BitTorrent_clien...
i.e. Transmission uses GTK3 and looks like this[1] on OSX.
[1] https://en.wikipedia.org/wiki/Transmission_(BitTorrent_clien...
#/media/File:Transmission_v2.92_on_macOS.png){kind=link}
Are you sure? I don't recall it using GTK3 on Mac.
> A native Mac OS X GUI application
> GTK+ and Qt GUI applications for Linux, BSD, etc.
https://github.com/transmission/transmission
> A native Mac OS X GUI application
> GTK+ and Qt GUI applications for Linux, BSD, etc.
https://github.com/transmission/transmission
Yep, you're right. I forgot about that.
GTK3 in general looks a hell of a lot nicer than GTK2 but now I can't think of any GTK3 applications that actually run on OSX...
GTK3 in general looks a hell of a lot nicer than GTK2 but now I can't think of any GTK3 applications that actually run on OSX...
This is something I've always wondered and still can't find a good answer to: why are MacOS apps so damned beautiful and plentiful compared to linux and windows apps? Are the official Apple frameworks just that easy and pleasant to work with? I hear devs complain about ObjectiveC all the time, so it can't be their language choice. Or is it another example of Steve Job's reality distortion field, but applied to the entire MacOS application developer community?
why are MacOS apps so damned beautiful and plentiful compared to linux and windows apps?
One is developer culture. Going all the way back to the earliest Macintosh days, Apple has always had detailed guidelines about how the one true way a GUI app should look and feel. And the importance of following those guidelines gets drilled into you from your very first Hello World program. This leads to all apps on macs to look both good and consistent, giving developers a lot of inspiration to draw from when they write their own apps. Windows and Linux simply doesn't have this culture ingrained into its developers. It also helps that Apple really only has one GUI framework at a time that it pours all their effort and focus into while Windows and Linux always have at least 2 or 3 competing frameworks that never get quite the attention they need.
Another might simply be financial incentives. Anecdotally Mac user care more about what their apps look like than Windows and Linux users, thus the financial incentives to put in the effort to add the final polish to your apps is higher, since it probably affects sales much more than it does on Linux and Windows. Also (and equally anecdotally) Apple users seem far more willing to pay for small useful applications from indie developers so more indie developers put more effort into producing small useful and beautiful apps for Mac.
One is developer culture. Going all the way back to the earliest Macintosh days, Apple has always had detailed guidelines about how the one true way a GUI app should look and feel. And the importance of following those guidelines gets drilled into you from your very first Hello World program. This leads to all apps on macs to look both good and consistent, giving developers a lot of inspiration to draw from when they write their own apps. Windows and Linux simply doesn't have this culture ingrained into its developers. It also helps that Apple really only has one GUI framework at a time that it pours all their effort and focus into while Windows and Linux always have at least 2 or 3 competing frameworks that never get quite the attention they need.
Another might simply be financial incentives. Anecdotally Mac user care more about what their apps look like than Windows and Linux users, thus the financial incentives to put in the effort to add the final polish to your apps is higher, since it probably affects sales much more than it does on Linux and Windows. Also (and equally anecdotally) Apple users seem far more willing to pay for small useful applications from indie developers so more indie developers put more effort into producing small useful and beautiful apps for Mac.
> Apple users seem far more willing to pay for small useful applications from indie developers so more indie developers put more effort into producing small useful and beautiful apps for Mac.
This rings true to me as well, but why is this the case? If we roughly assume that Mac users are 1 order of magnitude fewer than Windows users, they must be >1 OOM more likely to pay for these kinds of apps to generate this impression.
I struggled with this puzzle for quite a while when I switched from Mac to Windows. Utilities are simply not comparable, either in design, functionality, or simple quantity, for a market which is (on paper) both much larger and much older (if you restrict your view to the OS X era).
As an aside, it totally makes sense to me why Linux utilities are numerous and awesome, but have (usually) poor graphic design, because that Bauhaus-esque function over form describes how I prefer to work, too.
This rings true to me as well, but why is this the case? If we roughly assume that Mac users are 1 order of magnitude fewer than Windows users, they must be >1 OOM more likely to pay for these kinds of apps to generate this impression.
I struggled with this puzzle for quite a while when I switched from Mac to Windows. Utilities are simply not comparable, either in design, functionality, or simple quantity, for a market which is (on paper) both much larger and much older (if you restrict your view to the OS X era).
As an aside, it totally makes sense to me why Linux utilities are numerous and awesome, but have (usually) poor graphic design, because that Bauhaus-esque function over form describes how I prefer to work, too.
> This rings true to me as well, but why is this the case?
Because the Apple macOS ecosystem already has an coherent design at the point where I (as a macOS user) would hate to bring another app that breaks the coherence.
Also Apple's official apps are generally much better than the MS ones or Gnome ones (see IE vs Safari) which makes the expectation of users higher.
IMO Apple really made a great, healthy ecosystem around the macOS.
Because the Apple macOS ecosystem already has an coherent design at the point where I (as a macOS user) would hate to bring another app that breaks the coherence.
Also Apple's official apps are generally much better than the MS ones or Gnome ones (see IE vs Safari) which makes the expectation of users higher.
IMO Apple really made a great, healthy ecosystem around the macOS.
I suspect a lot also has to do with the business opportunities available for developers on the different platforms. First of all, there is a near-limitless number of companies out there looking for Windows desktop developers to work on various inhouse apps.
Secondly, there is a lot more money in the business and specialist app market for Windows. I worked for 3 years at a company developing a Windows application. We charged $5k a year for a license plus a good 50-500 consulting hours to adapt the application to our customers business. That was a solid business targeting a niche market, and there are countless companies like that around in the Windows space. Those opportunities don't really exist for Mac developers. Most people specializing in Windows desktop development end up working on stuff like that if they don't end up at Microsoft/Adobe/Autodesk etc.
If I was to start a company trying to develop desktop applications for Windows there is no doubt I would target business customers willing to pay $1k-10k rather than trying to sell $10-100 to consumers. If I was targeting Mac users I would probably target the $10-100 consumer space.
Secondly, there is a lot more money in the business and specialist app market for Windows. I worked for 3 years at a company developing a Windows application. We charged $5k a year for a license plus a good 50-500 consulting hours to adapt the application to our customers business. That was a solid business targeting a niche market, and there are countless companies like that around in the Windows space. Those opportunities don't really exist for Mac developers. Most people specializing in Windows desktop development end up working on stuff like that if they don't end up at Microsoft/Adobe/Autodesk etc.
If I was to start a company trying to develop desktop applications for Windows there is no doubt I would target business customers willing to pay $1k-10k rather than trying to sell $10-100 to consumers. If I was targeting Mac users I would probably target the $10-100 consumer space.
> "... why are MacOS apps so damned beautiful and plentiful compared to linux and windows apps?"
While that was the case ten years ago, honestly the macOS app ecosystem is mostly running on fumes at this point. There's few people coming into AppKit development, and iOS developers seem to have an irrational fear of putting any effort into learning the desktop paradigm even though the API is largely the same.
Apple is making half-hearted efforts to fix this problem by introducing two new GUI APIs on the Mac. "Catalyst" is a porting layer that lets you put iPad apps on the Mac desktop. The look'n'feel of these apps is pretty much as clunky as you'd expect. Then there's "SwiftUI" which is a new React-like runtime that spans all Apple platforms. SwiftUI is in its early stages and will take years to catch up with AppKit's functionality.
At this point Mac desktop development is effectively in a limbo: no one wants to start new AppKit projects because Apple is strongly implying that it's deprecated (although they don't seem to know exactly what it's being replaced with). So it's pretty much Electron or Qt on the Mac now, unfortunately. As an AppKit developer since 2002, it breaks my heart a bit.
While that was the case ten years ago, honestly the macOS app ecosystem is mostly running on fumes at this point. There's few people coming into AppKit development, and iOS developers seem to have an irrational fear of putting any effort into learning the desktop paradigm even though the API is largely the same.
Apple is making half-hearted efforts to fix this problem by introducing two new GUI APIs on the Mac. "Catalyst" is a porting layer that lets you put iPad apps on the Mac desktop. The look'n'feel of these apps is pretty much as clunky as you'd expect. Then there's "SwiftUI" which is a new React-like runtime that spans all Apple platforms. SwiftUI is in its early stages and will take years to catch up with AppKit's functionality.
At this point Mac desktop development is effectively in a limbo: no one wants to start new AppKit projects because Apple is strongly implying that it's deprecated (although they don't seem to know exactly what it's being replaced with). So it's pretty much Electron or Qt on the Mac now, unfortunately. As an AppKit developer since 2002, it breaks my heart a bit.
> honestly the macOS app ecosystem is mostly running on fumes at this point
I don't have data, but there's no way that the Mac developer ecosystem is worse off than it was in the 00s. There's significantly more Mac users now, and there's orders of magnitude more developers with experience developing for Apple platforms.
Maybe most devs won't venture outside of iOS to try Mac development, but 10 years ago the few long-time Mac devs were (by necessity) putting their Mac projects on hold to work on iPhone apps.
> because Apple is strongly implying that it's deprecated
Lots of iOS developers are writing blog posts claiming things like this, but every single Apple app on the Mac is written using AppKit. You can't deprecate the technology behind your entire platform.
Maybe 15 years from now SwiftUI will have replaced AppKit as the dominant way to write UI code on the Mac, but generations of apps will be born and die between now and then.
I don't have data, but there's no way that the Mac developer ecosystem is worse off than it was in the 00s. There's significantly more Mac users now, and there's orders of magnitude more developers with experience developing for Apple platforms.
Maybe most devs won't venture outside of iOS to try Mac development, but 10 years ago the few long-time Mac devs were (by necessity) putting their Mac projects on hold to work on iPhone apps.
> because Apple is strongly implying that it's deprecated
Lots of iOS developers are writing blog posts claiming things like this, but every single Apple app on the Mac is written using AppKit. You can't deprecate the technology behind your entire platform.
Maybe 15 years from now SwiftUI will have replaced AppKit as the dominant way to write UI code on the Mac, but generations of apps will be born and die between now and then.
> "I don't have data, but there's no way that the Mac developer ecosystem is worse off than it was in the 00s."
I don't have hard data either. But ask any old Mac developer on Twitter whether they're doing better now than ten years ago, and I bet a majority would disagree.
For one thing, the rise of mobile app stores has destroyed the perceived value of software. A $50 app now seems very expensive to most, whereas it was mid-priced back in 2008. Yet the Mac App Store has failed to bring in the mass audience that would compensate for the lower unit prices.
I don't have hard data either. But ask any old Mac developer on Twitter whether they're doing better now than ten years ago, and I bet a majority would disagree.
For one thing, the rise of mobile app stores has destroyed the perceived value of software. A $50 app now seems very expensive to most, whereas it was mid-priced back in 2008. Yet the Mac App Store has failed to bring in the mass audience that would compensate for the lower unit prices.
That isn’t specific to MacOS though, you can see it happening in the Windows world as well.
> why are MacOS apps so damned beautiful and plentiful compared to linux and windows apps?
This is entirely subjective. Several of my colleagues use MacOS and I find their interfaces overcrowded and clunky compared to my minimal linux setup. What is "plenty" to some, is "clutter" to others.
This is entirely subjective. Several of my colleagues use MacOS and I find their interfaces overcrowded and clunky compared to my minimal linux setup. What is "plenty" to some, is "clutter" to others.
You've not seen the Linux desktops of some of the guys in our Unix Ops department. If you're allergic to clutter, you'd have a seizure.
I can't criticize. I paid for every square inch of the screen of my 27" iMac at home, and darn it, I'm going to put something on every last one of them.
I can't criticize. I paid for every square inch of the screen of my 27" iMac at home, and darn it, I'm going to put something on every last one of them.
I think it's mainly the macOS widgets that look good, thus making it easy to build a good looking UI out of those components. You can't make a nice looking UI if the very building blocks you have to build that UI are ugly.
Good designers like good design. The OS has better design consistency, which good designers like, and Mac users can tend to be pickier about design.
Not sure it has much to do with the developers at all.
Not sure it has much to do with the developers at all.
> Not sure it has much to do with the developers at all.
Harsh but fair. I keep thinking that if we just make good app development easier, we could bring some of those well designed apps back to the native desktop instead of losing them all to the web. The reality, as you pointed out, is that the underlying technology is irrelevant. This is a marketing issue.
Harsh but fair. I keep thinking that if we just make good app development easier, we could bring some of those well designed apps back to the native desktop instead of losing them all to the web. The reality, as you pointed out, is that the underlying technology is irrelevant. This is a marketing issue.
> Are the official Apple frameworks just that easy and pleasant to work with? I hear devs complain about ObjectiveC all the time, so it can't be their language choice.
I've found the former to be quite true, though QT comes close. I actually quite like ObjectiveC, but Swift is clearly superior and has had great uptake in the iOS/macOS community.
I've found the former to be quite true, though QT comes close. I actually quite like ObjectiveC, but Swift is clearly superior and has had great uptake in the iOS/macOS community.
Sure, native MacOS Apps are better, but GTK Apps for me still feel significantly better than Qt ones.
I recently started to use a gtk audiobook player (https://github.com/geigi/cozy, small plug as i've been very happy with it), and it looks absolutely fine to me. Of the three frameworks in the title traditional Qt Widgets apps to me look the worst.
What do you not like about Qt? Are the apps or the Widget themselves? The apps are the job of the developer to align and padd things properly. The wdidgets are designed to look as default platforms Widgets, so on Windows you get the buttons and progressbars to look native, in Linux it will use the theme you set. Where GTK apps by default look horrible, they do not use the platform icons and styles or dialog boxes, I assume the reason is that Qt is sold as a cross platform toolkit where GTK is a Red Hat project and RH is focused mainly on GNOME
Hi,
I would love to heard from your experience the easiness/difficulty to theme your Gtk application.
Also, In the analysis I tested Qt with QML, not widgets.
Also, In the analysis I tested Qt with QML, not widgets.
It definitely depends on the platform and how much effort has been put in by the author. It is definitely ugly-by-default. Try Inkscape on Mac for example... that still uses XQuartz, maybe they're still on GTK2? Or try GIMP on Windows.
But there are more attractive apps that use GTK. They just have spent time doing custom themes.
But there are more attractive apps that use GTK. They just have spent time doing custom themes.
Entirely depends on your system. On Linux/BSD with the right theme it can indeed look beautiful. I also quite enjoy the "plastic-y" feel it provides with some themes (like Clearlooks).
Hi, while I agree this criterion is highly subjective, I've based my analysis on the successful Desktop applications, and how it's easy/difficult to customize components.
What about GTK programs on Windows? I am not familiar with their case on Windows platform.
I'm using Textadept and Notecase on Windows. I personally like the Win95 aesthetics, but it's not everyone's cup of tea.
I also like the Win95 aesthetics, though last time i checked Gtk+ does support Windows' theme engine (not 100% perfect but 99.9% is there). At least Gtk+ 2 does, did that change with Gtk+ 3?
Hi, I think we can objectively say that Slack or VS Code (Electron) are beautiful, while fractal or Notecase (Gtk) are not.
I would say that this is not objective at all; I find VS Code well designed but it doesnt fit with the rest of the Gnome desktop (or any desktop) at all, whereas fractal fits well with the rest of the gnome system, and in my opinion looks quite nice.
Highly subjective; I’d say that VS Code looks worse (and is certainly more clunky) than IntelliJ or even Xcode.
I’d say “modern” or “web-like” versus “traditional desktop”.
It’s not quite objective but I agree you’d probably find 90 or 99% of respondents prefer the web look for desktop apps.
The time when desktop apps looked like a consistent toolkit is gone. Now it’s more important for a desktop app to look like its own web version than to look like the next desktop app.
It’s not quite objective but I agree you’d probably find 90 or 99% of respondents prefer the web look for desktop apps.
The time when desktop apps looked like a consistent toolkit is gone. Now it’s more important for a desktop app to look like its own web version than to look like the next desktop app.
A consistent look trains users to expect consistent behavior. For example, a native macOS table supports various modifier key behavior, arrow key navigation, type select, drag and drop, copy and pasting rows, etc. It's worth learning these features (the theory goes) because they translate across apps.
But every web app is a snowflake, so there's no shared expertise to be developed. I don't expect anything beyond point and click. We've given up on empowering users.
But every web app is a snowflake, so there's no shared expertise to be developed. I don't expect anything beyond point and click. We've given up on empowering users.
> We've given up on empowering users.
That's because the mass market doesn't want to be empowered. They want to consume.
That said, phones and tablets are custom built for those people. The only people still using laptops and desktops are people who need to get things done. It's beyond time for desktop OS's and apps to start focusing on the power user again.
That's because the mass market doesn't want to be empowered. They want to consume.
That said, phones and tablets are custom built for those people. The only people still using laptops and desktops are people who need to get things done. It's beyond time for desktop OS's and apps to start focusing on the power user again.
For a long time I have hoped that the market would bifurcate, tablets and browser based devices for consumption and the modern equivalent of Sun SPARCstations for power users.
I for one am happy to see that apps include more and more features; I really did not like that I get 10 apps vs 1 for stuff that could be easily fit into one. My bank for instance keeps adding features all the time which allows me to do everything in the app without having to get the laptop out. I really wish more companies did that. You don't have to use it (and a lot of people would not even be able to find it) but for me it saves a lot of time.
I've not learned Rust yet, but unless it does behave really weird, I can't believe that Electron and Qt have roughly same RAM usage. In my experience Electron has usually 2 to 3 times higher RAM requirements than Qt application of similar scope.
It's because almost all electron apps are written fully in JS.
In the context of the article, the UI is in HTML/JS and the business logic in Rust, thus the RAM is not so high.
On the other hand, Qt QML embed it's own JS engine which is not resources light.
In the context of the article, the UI is in HTML/JS and the business logic in Rust, thus the RAM is not so high.
On the other hand, Qt QML embed it's own JS engine which is not resources light.
Did you come to this conclusion by taking measurements using real apps? Because if this is just your gut feeling, that doesn't make sense. The base memory footprint of something like Electron (just a simple Hello World app) is likely already heavier than a complete Rust-only GUI app.
For a GUI app, business logic is usually not where your RAM budget goes.
For a GUI app, business logic is usually not where your RAM budget goes.
Electron hello world ~40MB of RAM
Qt with QML Hello World ~40MB of RAM
Gtk-rs hello world ~20MB of RAM
Qt with QML Hello World ~40MB of RAM
Gtk-rs hello world ~20MB of RAM
Not sure where you're getting your numbers, but as a quick test I cloned an Electron Hello World app[0], bumped its Electron dependency to the latest version on npm, and ran it. It came in at around 90MB resident on the main process, with a GPU process of about 70MB, a "zygote" process of around 60MB, and a separate nodejs process around 35MB. Even if some memory was shared between those, that's still quite a bit more than 40MB.
[0] https://github.com/greggman/electron-hello-world
[0] https://github.com/greggman/electron-hello-world
The UI, especially since it's in HTML/JS, is almost certainly going to use more RAM than the business logic in most cases.
QT these days is written in a JavaScript-esqe language and runs a modified WebKit to power the UI. It's as bad as it sounds.
> QT these days is written in a JavaScript-esqe language and runs a modified WebKit to power the UI. It's as bad as it sounds.
That's wrong.
QML has two mode: one "interpreted" ( the javascript-esque) and one that can be compiled to native C++ without js.
And WebKit / webview itself is a plugin for Qt, it is absolutely not required.
That's wrong.
QML has two mode: one "interpreted" ( the javascript-esque) and one that can be compiled to native C++ without js.
And WebKit / webview itself is a plugin for Qt, it is absolutely not required.
> QT these days is written in a JavaScript-esqe language and runs a modified WebKit to power the UI.
... that is entirely false. Qt has its own scene graph renderer which has nothing to do with WebKit.
... that is entirely false. Qt has its own scene graph renderer which has nothing to do with WebKit.
I gave up trying to use native libraries for UI on cross-platform desktop programs.
I'm playing with the idea to create a Web UI and launch it automatically from the Rust server by opening a browser and pointing it at localhost. No electron bloat.
Has anyone tried this, any thoughts?
I'm playing with the idea to create a Web UI and launch it automatically from the Rust server by opening a browser and pointing it at localhost. No electron bloat.
Has anyone tried this, any thoughts?
The article seems to consider this hacky and insecure:
> Web broswer communicating with a Rust local server: too much hacky, insecure? (DNS rebinding attacks) and does not support native features like tray icons.
Personally I don't agree it's hacky and while DNS rebinding attacks are feasible, doesn't your application just need to check against a host whitelist to protect itself?
> Web broswer communicating with a Rust local server: too much hacky, insecure? (DNS rebinding attacks) and does not support native features like tray icons.
Personally I don't agree it's hacky and while DNS rebinding attacks are feasible, doesn't your application just need to check against a host whitelist to protect itself?
> The article seems to consider this hacky and insecure
I hadn't considered the security part yet, to be honest. I'm open to suggestions for methods to make sure the application is secure.
I hadn't considered the security part yet, to be honest. I'm open to suggestions for methods to make sure the application is secure.
My suggestion is to avoid cookies completely since they'd be shared with all services on the same IP/hostname because they ignore ports. I'd also add a random "key" as the first thing in the URL path so you'd end up with something like "http ://127.0.0.1 :1234/Lxk8gE7qnClf/actual/path/here" and have everything else tell the user to open the app with your icon or something.
This prevents malware from accessing your app while avoiding leaking authentication cookies to other http services on localhost.
This prevents malware from accessing your app while avoiding leaking authentication cookies to other http services on localhost.
Is there any reason you can’t bind a DNS name to localhost?
Security wise, that is.
Security wise, that is.
You could use entire 127/8 but using such instead of 127.0.0.1 for security reasons (so that people don't guess or connect to a port) makes no sense.
Filtering by the referrer should be a good start.
It at least used to be the case that this could be gotten around with flash, though that may be fixed, and many people won't run strange flash anymore anyway.
Another way, if you're using WebSockets, you can establish that the latency is unrealistically low to be a switched physical network, with pings (with cookies).
It at least used to be the case that this could be gotten around with flash, though that may be fixed, and many people won't run strange flash anymore anyway.
Another way, if you're using WebSockets, you can establish that the latency is unrealistically low to be a switched physical network, with pings (with cookies).
Consider the following task: you have UI widget and you will need to draw something on it. Something that cannot be trivially expressed by CSS means.
What will you do in native application?
You will put custom drawing code (C/C++/Rust/Go) in WM_PAINT/onPaint/onDraw method of the widget. If in Sciter[1] then you can do event_handler::handle_draw(graphics* pgfx) - Sciter's applications are native ones.
This will be fastest and most lightweight way of doing such things.
Now, what will you do on Web platform (browser or Electron)?
Calling server (over TCP - browser, RPC - Electron) for providing a drawing is clearly not an option.
So you will make some <canvas> element where you will draw that thing. <canvas> is a bitmap based thing so you will have that bitmap allocated as in CPU memory as in GPU memory. Plus you will have some nontrivial setup to position that <canvas> where you need it.
Therefore you will have at least memory requirement increased for your app (if to compare with native/sciter app).
Note that modern browser uses separate process for each tab. So you will have at least 3 processes running your application. That's also about memory and CPU consumption needed for RPC between them all.
And what if that thing that you will need to draw is not that trivial - will be heavy for script to handle...
And so you will start to add JIT to your script engine. That will need more memory and CPU (at least for bootstrap). Otherwise some smart people will propose you to use WebAssemble for that, so you will load WebAsm VM into your application...
See where it goes?
To create obstacles for yourself to overcome them heroically, right?
If that is for you personally then you can do whatever you want. But you want to put that burden to your users ... And so as many users as many machines converting that needles payload to heat without doing anything extra of what native applications can do already …
[1] https://sciter.com
What will you do in native application?
You will put custom drawing code (C/C++/Rust/Go) in WM_PAINT/onPaint/onDraw method of the widget. If in Sciter[1] then you can do event_handler::handle_draw(graphics* pgfx) - Sciter's applications are native ones.
This will be fastest and most lightweight way of doing such things.
Now, what will you do on Web platform (browser or Electron)?
Calling server (over TCP - browser, RPC - Electron) for providing a drawing is clearly not an option.
So you will make some <canvas> element where you will draw that thing. <canvas> is a bitmap based thing so you will have that bitmap allocated as in CPU memory as in GPU memory. Plus you will have some nontrivial setup to position that <canvas> where you need it.
Therefore you will have at least memory requirement increased for your app (if to compare with native/sciter app).
Note that modern browser uses separate process for each tab. So you will have at least 3 processes running your application. That's also about memory and CPU consumption needed for RPC between them all.
And what if that thing that you will need to draw is not that trivial - will be heavy for script to handle...
And so you will start to add JIT to your script engine. That will need more memory and CPU (at least for bootstrap). Otherwise some smart people will propose you to use WebAssemble for that, so you will load WebAsm VM into your application...
See where it goes?
To create obstacles for yourself to overcome them heroically, right?
If that is for you personally then you can do whatever you want. But you want to put that burden to your users ... And so as many users as many machines converting that needles payload to heat without doing anything extra of what native applications can do already …
[1] https://sciter.com
> See where it goes?
To a state where users need a (another) datacenter to access/view/use even trivial apps with “reasonable” responsiveness. There are services already being offered to this end [1].
[1] https://mightyapp.com/
To a state where users need a (another) datacenter to access/view/use even trivial apps with “reasonable” responsiveness. There are services already being offered to this end [1].
[1] https://mightyapp.com/
I'd only say to be careful about security -- arbitrary web pages can access localhost too.
Syncthing does it to great effect, https://github.com/syncthing/syncthing
I agree. Add on a system tray icon like SyncTrayzor if you are on Windows and it feels totally native.
Really? I recently started using SyncTrayzor and honestly I hate interacting with it.
Different strokes I suppose.
I enjoy noticing the system tray spin on cue when I boot up a laptop or plug a phone in as it syncs over WLAN. It's quite a cool feeling seeing the automatic file sync through the air as if by magic, no separate Dropbox/Google/Onedrive/Nextcloud service needed.
I can't do that with only Syncthing on Windows.
I enjoy noticing the system tray spin on cue when I boot up a laptop or plug a phone in as it syncs over WLAN. It's quite a cool feeling seeing the automatic file sync through the air as if by magic, no separate Dropbox/Google/Onedrive/Nextcloud service needed.
I can't do that with only Syncthing on Windows.
I think cups is doing this as well: http://localhost:631/
A lot of programs that are typically daemonized use this method. It makes a lot of sense for that use case, imo.
Not in Rust, but that's my approach with .NET Core Desktop Apps: https://docs.servicestack.net/netcore-windows-desktop
It also supports a super bloat-free option where entire Desktop Apps can be run from Gists. All Apps are run and share the same executable (and re-use its dependencies) so the Gists only need to contain their App-specific scripts and dependencies, giving each App tiny footprints:
https://sharpscript.net/docs/gist-desktop-apps
It also supports a super bloat-free option where entire Desktop Apps can be run from Gists. All Apps are run and share the same executable (and re-use its dependencies) so the Gists only need to contain their App-specific scripts and dependencies, giving each App tiny footprints:
https://sharpscript.net/docs/gist-desktop-apps
Yes, this is exactly how GUI should be done today. Remote access is an added benefit.
I have. In my opinion it is actually much more secure than Electron since you rely on the browser directly. (And this is why I did it instead of using Electron.)
You do have to add authentication to prevent against dns rebinding but I solved that by adding a random token in the get parameters when I launch the page. (You then cache this inside a cookie.)
You do have to add authentication to prevent against dns rebinding but I solved that by adding a random token in the get parameters when I launch the page. (You then cache this inside a cookie.)
This is exactly what Jupyter does when running locally - it's a pretty good example of this kind of app.
Isn't the browser more bloated than Electron?
Yes and no - It likely has more extensions and stuff. But actually since electron is essentially chromium + nodejs I would guess electron would be "heavier".
Anyway the reason this would be desirable is because the user's browser is likely already open (and doesn't have to be chrome), and one of the critiques with electron is that each electron app is essentially another instance of chromium running, they don't share any resources.
But a web browser that's already open just has to open a new tab, and you can close it when you don't need it, allowing the otherwise lightweight daemon to run with minimum performance impact.
Anyway the reason this would be desirable is because the user's browser is likely already open (and doesn't have to be chrome), and one of the critiques with electron is that each electron app is essentially another instance of chromium running, they don't share any resources.
But a web browser that's already open just has to open a new tab, and you can close it when you don't need it, allowing the otherwise lightweight daemon to run with minimum performance impact.
I'm thinking of using the user's default browser, not downloading another one for my program. In most cases the default browser is already running - no need to launch another instance like electron.
By using the user's browser, you do have to handle all of the different possible browsers somehow, even if that's only to do annoying browser detection and say "use a different browser". Electron and similar ideas at least limit you to designing / developing / testing a single browser. At least AFAIK; I haven't done any Electron work.
I mean... it's no different than making any website work in multiple browsers. Which really isn't too hard nowadays unless you're using bleeding-edge features or obscure non-standard ones.
Supporting multiple browsers is always somewhat more difficult than just one browser.
You are right that your choice of features plays into it, but I don't believe that's all there is. Even in the best case (all of features you want are available in all the browsers you care to support), you still should be testing in those browsers (ideally on all of the platforms / devices you support).
You also have to make the initial decision about what browsers/platforms/devices you support in the first place, and then choose when to re-evaluate your support. None of that is free.
Please don't get me wrong: I think it's a fine path (and one I have chosen myself), but it's definitely not without downsides.
You are right that your choice of features plays into it, but I don't believe that's all there is. Even in the best case (all of features you want are available in all the browsers you care to support), you still should be testing in those browsers (ideally on all of the platforms / devices you support).
You also have to make the initial decision about what browsers/platforms/devices you support in the first place, and then choose when to re-evaluate your support. None of that is free.
Please don't get me wrong: I think it's a fine path (and one I have chosen myself), but it's definitely not without downsides.
why couldn't you use user browser if it's in the range of your supported versions, else download chromium
I suppose you could, but I think you'd need to write version detection for a browser, the ability to figure out the user's chosen browser, the logic to download a reasonable version of Chromium, install it, get it past virus scanners, etc.
[deleted]
Using the preinstalled vrowser would mean bloating you app with polyfiles to aupport all differents browsers. It's one of the reasons modern apps are bloated. Electron solves this.
When it says gtk is "really really ugly", is it referring to API or UI? I wrote a small app with it and I am happy with the result. https://github.com/cosarara/fucking-weeb
>I then also have to remember what's the last episode I watched
I find it quite funny how many complicated solutions to this problem there are.
I simply stick a bunch of symlinks to whatever shows I am currently watching and remove them one by one. 20 line bash script + 1 minute configuring the file manager integration.
I find it quite funny how many complicated solutions to this problem there are.
I simply stick a bunch of symlinks to whatever shows I am currently watching and remove them one by one. 20 line bash script + 1 minute configuring the file manager integration.
Alternative solution for keeping track of where you stopped watching series : watch them with mpv. If you quit with "Q" instead of "q", it will remember the position. Then, whenever you launch mpv, it checks if one of the files is in its list of positions (using absolute realpaths).
mpv series/*
Q
# continue from where I stopped
mpv series/*Back when i was using iMac as my "watch" computer, i was simply changing the text background color of whatever i was watching to green in Finder.
The feature to tag and color any file is really something that i miss in Explorer (in Explorer you can edit tags if the file format supports it and Explorer knows about it, but this only works for some file formats and even then the UI is cumbersome).
The feature to tag and color any file is really something that i miss in Explorer (in Explorer you can edit tags if the file format supports it and Explorer knows about it, but this only works for some file formats and even then the UI is cumbersome).
The Finder’s color labeling feature has been useful for decades now, having been around since the early 90s iterations of the Mac OS. I don’t know why other file managers never picked it up; it deviates too far away from “Windows Explorer clone” I guess?
I just use a text file for each series. Let's me also take notes about stuff I might forget due to really bad memory. Put a web or video link in there if relevant, too. If wanting less steps, search takes me right to name of the file if I wanted to do that.
Simple, text editors been helping me solve problems since EDIT on MS-DOS. No reason to learn something more complicated. The method is cross-platform, too. :)
Simple, text editors been helping me solve problems since EDIT on MS-DOS. No reason to learn something more complicated. The method is cross-platform, too. :)
>I then also have to remember what's the last episode I watched
... I generally just look in the "recent files" menu of my mediaplayer ? Also, many players are able to remember the last position in a file so if you open a file and are at the end...
... I generally just look in the "recent files" menu of my mediaplayer ? Also, many players are able to remember the last position in a file so if you open a file and are at the end...
I've done similar to replace my todo list - a directory of symlinks with numeric prefixes for ordering.
> When it says gtk is "really really ugly", is it referring to API or UI?
Both? Mostly the former? Largely the latter (depending on plattform)?
Both? Mostly the former? Largely the latter (depending on plattform)?
Aesthetically speaking, GTK is not ugly. Check Ubuntu 18.04 which adopted gnome3, thus has a Gtk+ UI.
With default theming, GTK+2 looks like a bad ripoff of Windows 9x. (It's quite ugly, but not quite as bad as FLTK) GTK+3 has much better default theming.
"(depending on platform)" ... you are naming the one platform Gtk+ properly supports.
GTK still has extreme padding and wasted screen real estate around texts, images, lists and other component. Making a slim version and better designed UIs would probably make a lot of difference.
That's due to the GNOME HIG, which I agree is ugly. But GTK+ itself will render whatever padding you ask for.
It existed before Gnome and I’ve not yet seen any GTK interface that doesn’t seem like a slightly better looking Motif UI.
On you typical laptop 14" FHD display, exactly this padding and sizing looks great (at @1x), while at 14" 1600x900 it still looks very good. Sure, on 1376x768 it looks terrible.
Gtk+ also has a lot of thrid party components. They may not be that discoverable, though. But you can look through a typical deps of a GNOME distribution to find some.
I just don’t watch shows for which I can’t remember where I stopped :)
To the UI, too far from modern applications.
I also heard that the API have some misfit with Rust ownership model: https://news.ycombinator.com/item?id=20368618
I also heard that the API have some misfit with Rust ownership model: https://news.ycombinator.com/item?id=20368618
This is a pretty terrible write up; and I honestly don't know how the author subjectively arrived at the conclusion that only QT, GTK, and Electron are worth testing. I sort of wish context was given for this as the summary, as "get shit done" could hardly be implied from this list.
Just my two cents.
Just my two cents.
Thank you for the "useful" feeeback :)
Maybe you can do your own so you can tell us the GiGa TrUtH about modern GUI frameworks.
Maybe you can do your own so you can tell us the GiGa TrUtH about modern GUI frameworks.
I said it was terrible and explained that your reasoning of "get shit done" lacks any tangible meaning to the rest of the world. Don't be salty because I posted my opinion, I didn't say you were a terrible person for writing it.
If you would've just titled your post "a review of electron, gtk, and qt for making UIs with Rust" I'd have less of an issue. You also stated in another post in this thread, and not in your article, that you feel "Slack" is beautiful and that "beauty" was a necessity. That sounds like your principle deciding factor; not, "get shit done."
There's lots of things you could have done, but the responsibility isn't on me to coddle you through my thoughts. You could've just responded and qualified "get shit done," and started a dialogue but alas... you decided to reply like a child because you're upset. Maybe next time you shouldn't post to HN if you're gonna let comments from random folks get you down.
If you would've just titled your post "a review of electron, gtk, and qt for making UIs with Rust" I'd have less of an issue. You also stated in another post in this thread, and not in your article, that you feel "Slack" is beautiful and that "beauty" was a necessity. That sounds like your principle deciding factor; not, "get shit done."
There's lots of things you could have done, but the responsibility isn't on me to coddle you through my thoughts. You could've just responded and qualified "get shit done," and started a dialogue but alas... you decided to reply like a child because you're upset. Maybe next time you shouldn't post to HN if you're gonna let comments from random folks get you down.
I just prefer actionable feedback rather than grunting.
As product developers we have the responsibility to create great product. One of the criterion of a great product is beauty.
Get the shit done is just a summary of the previously mentioned criteria.
I would looove to be proven wrong that Electron, Qt and Gtk are not the only viable options and would happily investigate further.
But I would also love to stop seeing random grunting from people who never had written (or event tried to write) great Gui desktop applications. (I'm not sayimg that you never have, I'm saying that by telling those are not the only viable options you look like never have).
As product developers we have the responsibility to create great product. One of the criterion of a great product is beauty.
Get the shit done is just a summary of the previously mentioned criteria.
I would looove to be proven wrong that Electron, Qt and Gtk are not the only viable options and would happily investigate further.
But I would also love to stop seeing random grunting from people who never had written (or event tried to write) great Gui desktop applications. (I'm not sayimg that you never have, I'm saying that by telling those are not the only viable options you look like never have).
See also: https://areweguiyet.com/
I don't understand the critic about subjective criteria, people commenting here seem to assume that the list is supposed to be an objective and complete comparison of GUIs. The author evaluated the solutions for their own needs, of course it will be subjective. If they find something too ugly for the UX they want to have, that's a perfectly valid reason to filter something out.
> people commenting here seem to assume that the list is supposed to be an objective and complete comparison of GUIs
well yes, that's what you get for naming your blog like a research paper
well yes, that's what you get for naming your blog like a research paper
How are you going to claim that Gtk doesn't have a 'responsive UI'? It's native, it's very responsive.
Unless you mean 'responsive' like 'works on mobile'. Which seems kind of a moot point considering we're talking about desktop applications.
Unless you mean 'responsive' like 'works on mobile'. Which seems kind of a moot point considering we're talking about desktop applications.
Responsive usually means it responds to changes in screen size by adjusting to a nicer layout at that size (3 columns turning into 1, for example)
IMO that is one of the most annoying misfeatures i've seen... on websites it is practically always used to distinguish between mobile and desktop, which misfires completely if you have a 1366x768 monitor and you aren't running a fullscreen browser, whereas on desktop it is always done because the application is ignoring all the screen real estate it gets by padding everything like balloons, using titanic font sizes (ignoring the system wide settings for fonts and sizes, of course), etc.
In theory it should be applications automatically showing and hiding features based on the available allocated area so that you could have (on desktop at least) multiple applications visible at the same time and have a dynamic view of their content's details just by resizing them. Which is a good idea.
In practice however it ends up as a band-aid for self-inflicted deficiencies.
In theory it should be applications automatically showing and hiding features based on the available allocated area so that you could have (on desktop at least) multiple applications visible at the same time and have a dynamic view of their content's details just by resizing them. Which is a good idea.
In practice however it ends up as a band-aid for self-inflicted deficiencies.
It's not usually used in that context for desktop applications
By responsive I mean which can adapt to screen size.
It's useful because we see more and more 'convergent devices' like the librem 5, pr a raspberry pi with a 10' screen
It's useful because we see more and more 'convergent devices' like the librem 5, pr a raspberry pi with a 10' screen
Hi, author here,
I understand the critics against the subjective criteria like "Look".
Look means: the ability to create a native app which is at least beautiful as modern WebApps.
e.g. Slack or VSCode (Electron) are beautiful, while fractal or NoteCase (Gtk) are not.
I understand the critics against the subjective criteria like "Look".
Look means: the ability to create a native app which is at least beautiful as modern WebApps.
e.g. Slack or VSCode (Electron) are beautiful, while fractal or NoteCase (Gtk) are not.
But that is still entirely subjective, i pretty much prefer Notecase/Fractal to Slack/VSCode.
As i wrote in another reply you probably want to rename this to themability (or customizability, but that can be a bit vague whereas themability is a common feature that one may want from a GUI toolkit) instead of look.
As i wrote in another reply you probably want to rename this to themability (or customizability, but that can be a bit vague whereas themability is a common feature that one may want from a GUI toolkit) instead of look.
Spotify and Telegram are both examples of good looking Qt apps, but I prefer standardization of the menu bar which neither do very well.
It's really sad to see that all the native options like druid got dismissed for being "not mature enough".
Guess I'll stick to WebAssembly and CLI Apps.
It's completely fair though, and I wouldn't want people trying to use druid while really basic functionality like menus is still being worked on. The only way I would recommend druid is if people want to roll up their sleeves and help build the toolkit.
If it's still dismissed in six months to a year, that would be sad.
If it's still dismissed in six months to a year, that would be sad.
The author of druid himself considers it immature at this point though…
And unfortunately, Azul was abandoned by its maintainer a few month ago for family reasons, so it's unlikely to be polished anytime soon.
At this point there is no viable full-Rust GUI toolkit, but druid may be one at some point.
And unfortunately, Azul was abandoned by its maintainer a few month ago for family reasons, so it's unlikely to be polished anytime soon.
At this point there is no viable full-Rust GUI toolkit, but druid may be one at some point.
At least it wasn't dismissed for being "not enought mature."
Sciter/Rust (https://github.com/sciter-sdk/rust-sciter) was not tested: https://gitlab.com/z0mbie42/rust_gui_ecosystem_overview#not-...
but conclusion "The most promising seems to be Flutter" was made already :)
but conclusion "The most promising seems to be Flutter" was made already :)
> The following options exists but were not included because they are not mature enough.
> Web broswer communicating with a Rust local server: too much hacky, insecure? (DNS rebinding attacks) and does not support native features like tray icons.
You should not discount this, Golang solutions like lorca [0] do just fine with this using devtools proto for comm (systray can be a separate lib). DNS rebinding attacks are just a host header check away from mitigated. At the least, check out webview [1] (and its in-dev successor impl [2]) for not requiring Chrome and having more direct control.
Also, you should look at CEF which ships with Chromium bundled (it's not too huge) and has a C-FFI easily consumable from Rust. I have used this approach with success.
0 - https://github.com/zserge/lorca 1 - https://github.com/zserge/webview 2 - https://github.com/zserge/webview/tree/webview-x
> Web broswer communicating with a Rust local server: too much hacky, insecure? (DNS rebinding attacks) and does not support native features like tray icons.
You should not discount this, Golang solutions like lorca [0] do just fine with this using devtools proto for comm (systray can be a separate lib). DNS rebinding attacks are just a host header check away from mitigated. At the least, check out webview [1] (and its in-dev successor impl [2]) for not requiring Chrome and having more direct control.
Also, you should look at CEF which ships with Chromium bundled (it's not too huge) and has a C-FFI easily consumable from Rust. I have used this approach with success.
0 - https://github.com/zserge/lorca 1 - https://github.com/zserge/webview 2 - https://github.com/zserge/webview/tree/webview-x
Isnt the only way to defend against dns rebinding to add authentication to your local server?
For these localhost-only servers, a simple check on Host is fine. E.g. if you're on 127.0.0.1:3000, checking that Host is strictly 127.0.0.1:3000 or localhost:3000 is good enough.
Doesnt dns rebinding trick your browser into thinking this is indeed your host?
DNS rebinding involves changing your host's really-low-TTL A record to 127.0.0.1 (or other internal IP), and then on next request the browser will then assume that's what the host is and make call to that new IP assuming same-origin...but it sets the Host header as what the browser thinks represents that IP. If it's not localhost or 127.0.0.1 (for this use case) then we know someone tricked into thinking it was theirs that was our local IP. So check the Host to make sure it isn't someone else's host "re-bound" to your IP.
An important aspect to compare is docking. Any application that can span on multiple monitors, soon or later requires proper docking (window in window, etc.). Even if it's a single window, it's still a challenge.
Qt is almost there, but not as good as say Visual Studio (whatever docking framework they are using).
To be more blunt, any content creation tool (3D model/animation/etc editor) needs to support it. Take any Autodesk product for example (most of them use Qt).
Dear IMGUI in this respect added recently pretty good docking system, and it's not in this list - someone else also mentioned that https://news.ycombinator.com/item?id=20776848
Thanks!
Qt is almost there, but not as good as say Visual Studio (whatever docking framework they are using).
To be more blunt, any content creation tool (3D model/animation/etc editor) needs to support it. Take any Autodesk product for example (most of them use Qt).
Dear IMGUI in this respect added recently pretty good docking system, and it's not in this list - someone else also mentioned that https://news.ycombinator.com/item?id=20776848
Thanks!
There is a nice improved docking system being developed for Qt by KDAB (disclaimer: I work there) : https://github.com/KDAB/KDDockWidgets
It closes the gap a fair bit with the VS docking system
It closes the gap a fair bit with the VS docking system
Lately I’ve been experimenting with the idea of fully native cross platform desktop apps. Latest iteration is to write the majority of the app in Go and communicate with a native frontend over TCP. So far I’m finding that building a really simple UI and communicating over TCP to be pretty simple. At the same time I keep the majority of the business logic in the go server. It probably doesn’t work for all app types but it is fun to play with.
With Rust I imagine taking advantage of LLVM you could just import the business logic into whatever app environment you need to and work it that way. Has anyone here tried that? I would love to hear how it went.
With Rust I imagine taking advantage of LLVM you could just import the business logic into whatever app environment you need to and work it that way. Has anyone here tried that? I would love to hear how it went.
> Latest iteration is to write the majority of the app in Go and …
Check Sciter/Go : https://github.com/sciter-sdk/go-sciter
It is used precisely that way: backend - Go, UI - Sciter.
Check Sciter/Go : https://github.com/sciter-sdk/go-sciter
It is used precisely that way: backend - Go, UI - Sciter.
> Latest iteration is to write the majority of the app in Go and communicate with a native frontend over TCP
You need a protocol over TCP. Something standard and easy to use, hopefully one that people already know and has wide support from libraries. HTTP?
Native UIs are nice, but the cool kids like to stylize their UIs. Things like gradients, shadows, highlights, animations, etc. And wouldn't it be cooler if you go to all that trouble to stylize your UI to have it look the same on all platforms? What if you add another layer on top of the underlying UI framework? Something that lets you compose UI elements from basic shapes, maybe a way to separate the layout from the style? HTML + CSS.
Oh wait, we reinvented electron again.
You need a protocol over TCP. Something standard and easy to use, hopefully one that people already know and has wide support from libraries. HTTP?
Native UIs are nice, but the cool kids like to stylize their UIs. Things like gradients, shadows, highlights, animations, etc. And wouldn't it be cooler if you go to all that trouble to stylize your UI to have it look the same on all platforms? What if you add another layer on top of the underlying UI framework? Something that lets you compose UI elements from basic shapes, maybe a way to separate the layout from the style? HTML + CSS.
Oh wait, we reinvented electron again.
[deleted]
No mention of imgui?
I've mentioned imgui too, and posted link to your comment. It needs to be evaluated here too. Coming from the game development world, there is a big appeal to the framework. It's author is responsive, the size is small, and the features are really what a game tool, or in-game debug screen may want. Easy to integrate, with various gfx backends (opengl, direct3d, etc.), and supports things that are not even done well by some of the other frameworks - like docking (which I've mentioned in my post).
It has quirks, biggest one (to me), being how to deal when you have lots of widgets and their state (e.g. the hidden state labeling), then with my personal experiments I've found cases where the UI would lock, when flowing text, but overall seems to work well.
On the other end, I'm really happy (myself) with Flutter, but then it misses the stuff that I just mentioned, though for a mobile app - you may (and most likely not) need these requirements.
So two important, and recently new frameworks not included, I think they should... Flutter is direct competitor to Electron (now available on the desktop), and IMGUI to Qt/GTK.
It has quirks, biggest one (to me), being how to deal when you have lots of widgets and their state (e.g. the hidden state labeling), then with my personal experiments I've found cases where the UI would lock, when flowing text, but overall seems to work well.
On the other end, I'm really happy (myself) with Flutter, but then it misses the stuff that I just mentioned, though for a mobile app - you may (and most likely not) need these requirements.
So two important, and recently new frameworks not included, I think they should... Flutter is direct competitor to Electron (now available on the desktop), and IMGUI to Qt/GTK.
> being how to deal when you have lots of widgets and their state (e.g. the hidden state labeling)
Not sure exactly what you are referring you precisely? Happy to hear about it. Once you get the hang of what the ID Stack is for, normally you would push on the id stack for everyloop.
> I've found cases where the UI would lock, when flowing text
Never seen that sort of stuff happening.. if you do encounter issues of this kind please try to report them with some details!
Not sure exactly what you are referring you precisely? Happy to hear about it. Once you get the hang of what the ID Stack is for, normally you would push on the id stack for everyloop.
> I've found cases where the UI would lock, when flowing text
Never seen that sort of stuff happening.. if you do encounter issues of this kind please try to report them with some details!
Do you mean Dear ImGui? Isn't it a C++ GUI?
https://github.com/ocornut/imgui
https://github.com/ocornut/imgui
There are rust bindings for Dear Imgui
https://github.com/Gekkio/imgui-rs
And nuklear (another imgui library)
https://github.com/snuk182/nuklear-rust
https://github.com/Gekkio/imgui-rs
And nuklear (another imgui library)
https://github.com/snuk182/nuklear-rust
[deleted]
It's almost if the GUI ecosystem is mostly independent of the language used. That's because GUI frameworks are a lot of work, so it makes more sense to have bindings to existing ones.
An Electron flame war seems inevitable. It's fine for quick cross platform support but it absolutely screws over the user. QT is far from perfect but at least it's native.
Is what sense is Qt "native"?
In the sense that the executable is the machine code, not the Javascript interpreter running through js files. In the sense that Electron is actually native code (Chromium) running HTML UI and QT running its own custom-drawn UI, both different from whatever platform-blessed UI toolkit is, no, QT is not "native"
> QT running its own custom-drawn UI, both different from whatever platform-blessed UI toolkit is, no, QT is not "native"
Most Qt Apps are still using the widget layout in pure C++ ( from the stats of the Qt company itself ) and do not contains a single line of JS or interpreted language.
Then yes Qt is native and Electron is not.
Most Qt Apps are still using the widget layout in pure C++ ( from the stats of the Qt company itself ) and do not contains a single line of JS or interpreted language.
Then yes Qt is native and Electron is not.
What exactly does "security" mean in this?
Difficulty of reverse engineering?
Difficulty of reverse engineering?
Security means the global security of the framework.
Using electron exposes to some future chrome/Node CVEs and the past ones.
Qt on the other hand is used a lot in emdedd devices/automotive so we can expect security being a top priority of the developers.
Using electron exposes to some future chrome/Node CVEs and the past ones.
Qt on the other hand is used a lot in emdedd devices/automotive so we can expect security being a top priority of the developers.
The reason why browsers have so many CVEs is that they routinely run untrusted code; hence browser developers invest a lot of resources into sandboxing the untrusted code and finding and fixing security holes in the sandbox and all of the native code that is callable from within the sandbox.
For an Electron app, most of these CVEs are probably irrelevant, because the code isn't untrusted in this case as it is bundled with the app already so sandbox escape isn't an issue. (Similar arguments apply to Java with browser plugins vs. "real" applications)
Native toolkits are never used directly from untrusted code; obviously this means they won't have a CVE for sandbox escaping because there isn't a sandbox.
But it also means they have a much smaller incentive to look for security holes in their code. CVEs are security bugs that were found and fixed, and number-of-CVEs is not an indication of how many unfixed security bugs remain. While the attack surface is smaller if you don't run untrusted code, it typically isn't zero, depending on what untrusted inputs a particular application reads. I'd bet that some security relevant UB in a Qt image decoder would take a lot longer to find than a similar bug in a browser's image decoder, simply because of the incentives.
Example, try googling "browser security bounty", then try again with "qt security bounty".
For an Electron app, most of these CVEs are probably irrelevant, because the code isn't untrusted in this case as it is bundled with the app already so sandbox escape isn't an issue. (Similar arguments apply to Java with browser plugins vs. "real" applications)
Native toolkits are never used directly from untrusted code; obviously this means they won't have a CVE for sandbox escaping because there isn't a sandbox.
But it also means they have a much smaller incentive to look for security holes in their code. CVEs are security bugs that were found and fixed, and number-of-CVEs is not an indication of how many unfixed security bugs remain. While the attack surface is smaller if you don't run untrusted code, it typically isn't zero, depending on what untrusted inputs a particular application reads. I'd bet that some security relevant UB in a Qt image decoder would take a lot longer to find than a similar bug in a browser's image decoder, simply because of the incentives.
Example, try googling "browser security bounty", then try again with "qt security bounty".
Electron have CVEs which are not directly related to the browser: https://wickr.com/electron-vulnerability-the-quest-for-cool
I for long searched for a way to use GTK from nodejs. There are some proof of concept level bindings, but none exposing any much decent amount of the underlying functionality.
Same for Qt I think
Same for Qt I think
Why would you want to do that? Isn't the point of Node that you get a powerful GUI system but the tradeoff is that you have to use Javascript (or Typescript) instead of a nicer language?
Some people like working in javascript, or it's just what they know. I would agree, though, that it's hard to make an argument for JS in that context on its technical merit. Even with the power and universality of a browser rendering engine, I think JS on the desktop is a disappointingly hacky way to avoid investment in purpose built cross platform UI toolkits. (Either building better ones or hiring people who know how to use existing ones.)
Tangential: does Chromium have a native widget abstraction? Are there any projects that extract this layer and expose it?
It does, called "Views". There's some documentation on it in the Chromium codebase. https://chromium.googlesource.com/chromium/src/+/master/docs...
I've used CEF to embed Chromium in Qt without too much difficulty. I made a C++ poc [0] and toyed with a Rust one a while back [1].
0 - https://github.com/cretz/qt_cef_poc 1 - https://github.com/cretz/rust-qt_cef_poc
0 - https://github.com/cretz/qt_cef_poc 1 - https://github.com/cretz/rust-qt_cef_poc
I can't remember if it's the same with chrome, but firefox actually uses its rendering engine to render the window chrome as well.
Where is imgui bindings in this list?
Finally, one big point that is not mentioned is accessibility. If most browser handle accessibility very nicely with the basic HTML components, if you start to do anything remotely advanced you gonna have to be careful and correctly implement ARIA norm, which most don't. Native UI framework are not perfect either, but can behave better in a lot of cases (it's not a clear cut though).
Electron or local-server + webapp is really nice. Having done front end development as well has "native" application (with Qt), I can really appreciate how easier it is do to custom components using web technology, but I think we tend to dismiss their disadvantages too quickly.