6 ms·

Yes, I think we all feel it. Every UI lib has something wrong: C++ sucks and is hard to iface w/ other langs (Qt, wxWidgets), not enough widgets (IUP, libui), n

Yes, I think we all feel it. Every UI lib has something wrong: C++ sucks and is hard to iface w/ other langs (Qt, wxWidgets), not enough widgets (IUP, libui), not native enough in my OS (GTK), carries a full browser (Electron, nw.js), carries a full JVM (JavaFX, Swing), etc, etc. And then every subreddit and community always has people asking what's the best UI lib for language X. We all travel back to awesome-lang-X lists' GUI section every so often hoping someone will finally fix it. Qt or wxWidgets, make a supported C iface (I am aware of some work on both fronts, e.g. wxc that was used by wxHaskell I think?). IUP and libui, thicken your libs (libui guy just got permission from his new company to get back working on the lib, yay). World, don't hate non-native-OS-widgeted apps. Browser vendors, stop being so tunnel-visioned into your my-OS-only, non-embeddable, or must-be-multiprocess shit. And let us trim some fat off at compile time please (waiting on you Servo, but please stay lean and single-process for embeddability). JVM AOT...we're waiting, we know it's coming. And no, I would rather not have an interpreted (or dynamic) language if I can help it. Edit: To clarify before a ton of responses pick apart my specific criticisms, I'm making these points to show there is a void. I could poke a ton more holes in these libs and more (I have used most), but it's hardly worth arguing the nuances here.

zerr 9y ago
Both Qt and wxWidgets have bindings for a bunch of languages. Also, in case AOT compiler comes to Java, JavaFX and Swing might become viable options as well.
- oblio 9y ago
  In many times bindings are: * incomplete * immature * not up to date and definitely out-of-tree, aka not maintained by the folks that make the original toolkit. Would you bet your company on those bindings?
  - akerro 9y ago
    Agreed, Qt binding are only officially supported for C++ and Python is a major player here as well, Golang has quite good bindings but a few minor methods per class as still missing, it's good enough to write a major desktop app tho.
  - zerr 9y ago
    Yes, but some of them are of very high quality, such as wxPython or PyQt. And to be honest, modern C++11/14/17 is quite a different language, more friendly to beginners compared to 90s C++ people remember. Writing C++ with wxWidgets or Qt really feels like Java or C# with their batteries.
  - lmm 9y ago
    There are bindings and there are bindings. I'd bet my company on PyQt - if anything I'd say bugs get fixed there quicker than in Electron. But part of the reason for that is that PyQt is a commercial (dual license) project with a dedicated company behind it.
- akerro 9y ago
  >Also, in case AOT compiler comes to Java What? AOT is available in Java even on Debian, the next step is Java-on-Java stack. HotSpot is about to be deprecated in 4 weeks once Graal becomes default for all platforms in Java10. > java --list-modules | grep aot > jdk.aot@9-Debian
  - zerr 9y ago
    I'm not in Java world, but I remember there were talks about future AOT awhile ago - is this a thing now? i.e. you don't have to ship the whole JVM, and no more bytecode, just a native executable? If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong).
    - pjmlp 9y ago
      Because of the crowd that doesn't want to pay for AOT compilers. The majority of commercial JDKs always supported AOT to native code, only Sun did not, as they were religiously against AOT. Oracle thankfully thinks otherwise, has kept sponsoring MaximeVM research, which became Graal and SubstrateVM, and now they are in the process of even re-writing the C++ parts into Java (Project Metropolis).
    - akerro 9y ago
      >I remember there were talks about future AOT awhile ago - is this a thing now? Yes, AoT is now supported in Java out of box. Java after Jigsaw projects is modularized and you can build an executable file, like .exe or .bin which contains minimal JVM in it with JVM modules and your own modules and it's dependencies. You can read more about it here https://steveperkins.com/using-java-9-modularization-to-ship-zero-dependency-native-apps/ https://steveperkins.com/using-java-9-modularization-to-ship... >If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong). Probably because a lot of developers still think Java is slow, many peoples opinion on Java is from 10 years ago. AoT was officially released in OpenJDK a few weeks ago, so as you can see, a lot of people don't know about it yet.
barrongineer 9y ago
With Java 9 jigsaw and jlink you can now build fairly light JavaFX apps. The entire jre no longer has to be bundled. Only the pieces you're using.
- hugi 9y ago
  I recently started experimenting with JavaFX. I was pleasantly surprised how nice it is, and how easy it is to package application bundles.
- TJSomething 9y ago
  Looks like that's about 45 MB [1]. For comparison, Electron is about 80 MB. Qt starts at 50 MB depending on what you need, but a few years ago I got it down to 16 MB with UPX and a customized ICU. Gtk starts at ~20 MB and compresses to about half that with UPX. You could probably get those a bit smaller if your license permits static linking, but then you have to write C++. [1] https://steveperkins.com/using-java-9-modularization-to-ship-zero-dependency-native-apps/ https://steveperkins.com/using-java-9-modularization-to-ship...
- floatboth 9y ago
  Unfortunately JavaFX still does not support Wayland, just like most Java GUI things (except for SWT which seems to have some support https://bugs.eclipse.org/bugs/show_bug.cgi?id=516841 https://bugs.eclipse.org/bugs/show_bug.cgi?id=516841)
  - pjmlp 9y ago
    Given the progress of Wayland's adoption, I don't see it as a major issue.
Vinnl 9y ago
It's interesting that you mention that GTK is not native enough, but do not mention that for Electron. It looks like (and I feel this way) GTK hits the uncanny valley, whereas Electron is different enough (and applications written in it are used to spending effort on looks) to not run into that problem.
- jhanschoo 9y ago
  otoh, I think that with Electron, people are sufficiently acclimatized to web apps for them to feel at home with it. GTK feels like a java app.
  - oblio 9y ago
    Yup. The default interface for almost every normal users these days is a web interface. Yes, there are mobile apps, but even on mobiles, users will need to use websites, despite the best efforts of vendors at lock-in into their walled app gardens. Heck, even on desktops, sometimes the UIs feel quaint and antiquated: no back button/undo by default, many times scrolling failures at different resolutions (the settings screen doesn't fit at a certain resolution and the button is out-of-screen somewhere), text can't be selected and copy-paste by default...
- kodablah 9y ago
  I find this inconsistency interesting as well. It's like if you used a "flat" GTK theme and avoided traditional UI elements like MDIs, menus, and toolbars, you'd be divorced enough from native to leave that criticism behind (granted there are others). I think this is what makes QML, JavaFX, and HTML+CSS more popular recently...desktop-like expectations are out the window (per se) before you start.
pjmlp 9y ago
> JVM AOT...we're waiting, we know it's coming. https://www.excelsiorjet.com/ https://www.excelsiorjet.com/
- oblio 9y ago
  It might as well not exist in this day and age: https://www.excelsiorjet.com/#pricing https://www.excelsiorjet.com/#pricing Yes, you can argue: "that's not fair", "for a professional programmer that's worth only a few weeks of work's for massive productivity improvements", etc., but things don't work that way. Most developers have been conditioned to not use commercial products, if they can. With an extra downside for the commercial product being closed source.
  - pjmlp 9y ago
    That was only one example, and I explicitly mentioned Excelsior instead of other alternatives, because it is free for open source projects.
  - kodablah 9y ago
    Fun aside, I once wrote a JVM AOT [0]. Instead of compiling to low level code and building my own GC and runtime, I just transpiled to Go. And it worked, but the Go compiler couldn't handle it well[1] so I started trimming identifier names and shortcutting JRE libs to use Go versions. It became tedious so I gave up. I should revisit that project one day, heh. 0 - https://github.com/cretz/goahead https://github.com/cretz/goahead 1 - https://github.com/golang/go/issues/18602 https://github.com/golang/go/issues/18602
oblio 9y ago
There is a void because OS vendors are actively hostile to top-notch cross platform UI toolkits. They learned their lesson from software companies of the 80's and 90's: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ Making a super high quality cross platform UI toolkit is very hard, both in regards to core implementation and maintenance. Open Source did its best, but it apparently wasn't enough. Commercial vendors can't really get adoption cause everyone expects free and even Open Source solutions. I feel that there's a catch-22 somewhere here :)
- concerned_user 9y ago
  But isn't web browser currently is a de-facto cross platform UI toolkit for displaying web pages it is just that we managed to make web pages look and behave more like apps. So it is definitely possible to make a framework/toolkit although if you look at development history of browsers how many years it took them to get where they are and Opera throwing in the towel and switching to Blink. Only question is, if they do such a toolkit what is there remaining for OS vendors to do? Kernels? Users will just choose faster one.
  - oblio 9y ago
    The browser is a cross platform UI, yes. But is it on-par with native offerings? Where are the standardized components? How many years did it take to get a simple grid layout present in Tk back in 1991? Where's the fool-proof GUI editor? How long did it take for it to have a date input? The web had to fight its way to where it is now. And that's why it has so many scars (besides the self-inflicted DOM and Javascript before strict mode and ECMAScript 5). Regarding the OS vendors, well, yes, kernels, tools, basic apps. Also not all applications are graphical.
    - concerned_user 9y ago
      Native offerings kinda suck too I don't know any standardized one. Swing, QT, GTK all look different depending on the OS. Before web stack there was Flash it had hardware access but it was insecure, now web tech going the same way with web assembly and webgl.
snarfy 9y ago
I think part of the UI problem is more fundamental than UI. The only common ABI among all programming languages is C. For a UI lib to work with all languages, we end up with wrappers for C libraries. If not we end up with language specific libs like Swing. We need a common ABI that's better than C.

zerr 9y ago

Both Qt and wxWidgets have bindings for a bunch of languages. Also, in case AOT compiler comes to Java, JavaFX and Swing might become viable options as well.

oblio 9y ago
In many times bindings are: * incomplete * immature * not up to date and definitely out-of-tree, aka not maintained by the folks that make the original toolkit. Would you bet your company on those bindings?
- akerro 9y ago
  Agreed, Qt binding are only officially supported for C++ and Python is a major player here as well, Golang has quite good bindings but a few minor methods per class as still missing, it's good enough to write a major desktop app tho.
- zerr 9y ago
  Yes, but some of them are of very high quality, such as wxPython or PyQt. And to be honest, modern C++11/14/17 is quite a different language, more friendly to beginners compared to 90s C++ people remember. Writing C++ with wxWidgets or Qt really feels like Java or C# with their batteries.
- lmm 9y ago
  There are bindings and there are bindings. I'd bet my company on PyQt - if anything I'd say bugs get fixed there quicker than in Electron. But part of the reason for that is that PyQt is a commercial (dual license) project with a dedicated company behind it.
akerro 9y ago
>Also, in case AOT compiler comes to Java What? AOT is available in Java even on Debian, the next step is Java-on-Java stack. HotSpot is about to be deprecated in 4 weeks once Graal becomes default for all platforms in Java10. > java --list-modules | grep aot > jdk.aot@9-Debian
- zerr 9y ago
  I'm not in Java world, but I remember there were talks about future AOT awhile ago - is this a thing now? i.e. you don't have to ship the whole JVM, and no more bytecode, just a native executable? If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong).
  - pjmlp 9y ago
    Because of the crowd that doesn't want to pay for AOT compilers. The majority of commercial JDKs always supported AOT to native code, only Sun did not, as they were religiously against AOT. Oracle thankfully thinks otherwise, has kept sponsoring MaximeVM research, which became Graal and SubstrateVM, and now they are in the process of even re-writing the C++ parts into Java (Project Metropolis).
  - akerro 9y ago
    >I remember there were talks about future AOT awhile ago - is this a thing now? Yes, AoT is now supported in Java out of box. Java after Jigsaw projects is modularized and you can build an executable file, like .exe or .bin which contains minimal JVM in it with JVM modules and your own modules and it's dependencies. You can read more about it here https://steveperkins.com/using-java-9-modularization-to-ship-zero-dependency-native-apps/ https://steveperkins.com/using-java-9-modularization-to-ship... >If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong). Probably because a lot of developers still think Java is slow, many peoples opinion on Java is from 10 years ago. AoT was officially released in OpenJDK a few weeks ago, so as you can see, a lot of people don't know about it yet.

barrongineer 9y ago

With Java 9 jigsaw and jlink you can now build fairly light JavaFX apps. The entire jre no longer has to be bundled. Only the pieces you're using.

hugi 9y ago
I recently started experimenting with JavaFX. I was pleasantly surprised how nice it is, and how easy it is to package application bundles.
TJSomething 9y ago
Looks like that's about 45 MB [1]. For comparison, Electron is about 80 MB. Qt starts at 50 MB depending on what you need, but a few years ago I got it down to 16 MB with UPX and a customized ICU. Gtk starts at ~20 MB and compresses to about half that with UPX. You could probably get those a bit smaller if your license permits static linking, but then you have to write C++. [1] https://steveperkins.com/using-java-9-modularization-to-ship-zero-dependency-native-apps/ https://steveperkins.com/using-java-9-modularization-to-ship...
floatboth 9y ago
Unfortunately JavaFX still does not support Wayland, just like most Java GUI things (except for SWT which seems to have some support https://bugs.eclipse.org/bugs/show_bug.cgi?id=516841 https://bugs.eclipse.org/bugs/show_bug.cgi?id=516841)
- pjmlp 9y ago
  Given the progress of Wayland's adoption, I don't see it as a major issue.

Vinnl 9y ago

It's interesting that you mention that GTK is not native enough, but do not mention that for Electron. It looks like (and I feel this way) GTK hits the uncanny valley, whereas Electron is different enough (and applications written in it are used to spending effort on looks) to not run into that problem.

jhanschoo 9y ago
otoh, I think that with Electron, people are sufficiently acclimatized to web apps for them to feel at home with it. GTK feels like a java app.
- oblio 9y ago
  Yup. The default interface for almost every normal users these days is a web interface. Yes, there are mobile apps, but even on mobiles, users will need to use websites, despite the best efforts of vendors at lock-in into their walled app gardens. Heck, even on desktops, sometimes the UIs feel quaint and antiquated: no back button/undo by default, many times scrolling failures at different resolutions (the settings screen doesn't fit at a certain resolution and the button is out-of-screen somewhere), text can't be selected and copy-paste by default...
kodablah 9y ago
I find this inconsistency interesting as well. It's like if you used a "flat" GTK theme and avoided traditional UI elements like MDIs, menus, and toolbars, you'd be divorced enough from native to leave that criticism behind (granted there are others). I think this is what makes QML, JavaFX, and HTML+CSS more popular recently...desktop-like expectations are out the window (per se) before you start.

pjmlp 9y ago

> JVM AOT...we're waiting, we know it's coming. https://www.excelsiorjet.com/ https://www.excelsiorjet.com/

oblio 9y ago
It might as well not exist in this day and age: https://www.excelsiorjet.com/#pricing https://www.excelsiorjet.com/#pricing Yes, you can argue: "that's not fair", "for a professional programmer that's worth only a few weeks of work's for massive productivity improvements", etc., but things don't work that way. Most developers have been conditioned to not use commercial products, if they can. With an extra downside for the commercial product being closed source.
- pjmlp 9y ago
  That was only one example, and I explicitly mentioned Excelsior instead of other alternatives, because it is free for open source projects.
- kodablah 9y ago
  Fun aside, I once wrote a JVM AOT [0]. Instead of compiling to low level code and building my own GC and runtime, I just transpiled to Go. And it worked, but the Go compiler couldn't handle it well[1] so I started trimming identifier names and shortcutting JRE libs to use Go versions. It became tedious so I gave up. I should revisit that project one day, heh. 0 - https://github.com/cretz/goahead https://github.com/cretz/goahead 1 - https://github.com/golang/go/issues/18602 https://github.com/golang/go/issues/18602

oblio 9y ago

There is a void because OS vendors are actively hostile to top-notch cross platform UI toolkits. They learned their lesson from software companies of the 80's and 90's: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ Making a super high quality cross platform UI toolkit is very hard, both in regards to core implementation and maintenance. Open Source did its best, but it apparently wasn't enough. Commercial vendors can't really get adoption cause everyone expects free and even Open Source solutions. I feel that there's a catch-22 somewhere here :)

concerned_user 9y ago
But isn't web browser currently is a de-facto cross platform UI toolkit for displaying web pages it is just that we managed to make web pages look and behave more like apps. So it is definitely possible to make a framework/toolkit although if you look at development history of browsers how many years it took them to get where they are and Opera throwing in the towel and switching to Blink. Only question is, if they do such a toolkit what is there remaining for OS vendors to do? Kernels? Users will just choose faster one.
- oblio 9y ago
  The browser is a cross platform UI, yes. But is it on-par with native offerings? Where are the standardized components? How many years did it take to get a simple grid layout present in Tk back in 1991? Where's the fool-proof GUI editor? How long did it take for it to have a date input? The web had to fight its way to where it is now. And that's why it has so many scars (besides the self-inflicted DOM and Javascript before strict mode and ECMAScript 5). Regarding the OS vendors, well, yes, kernels, tools, basic apps. Also not all applications are graphical.
  - concerned_user 9y ago
    Native offerings kinda suck too I don't know any standardized one. Swing, QT, GTK all look different depending on the OS. Before web stack there was Flash it had hardware access but it was insecure, now web tech going the same way with web assembly and webgl.

snarfy 9y ago

I think part of the UI problem is more fundamental than UI. The only common ABI among all programming languages is C. For a UI lib to work with all languages, we end up with wrappers for C libraries. If not we end up with language specific libs like Swing. We need a common ABI that's better than C.