1. 37

I want to make a GUI. What’s the least sucky way to accomplish that? Open to any language, but has to work cross-platform and be free. JavaFX? Qt? Something arcane?

  1.  

  2. 31

    One thing that is not specified is the language choice. E.g. if the language is Java, you are probably limited to JavaFX, SWT, AWT, or Swing.

    But generally speaking: Qt. Has matured over 2.5 decades. Has a reasonable look & feel on macOS and Windows, is native to Linux (at least KDE). Has a large set of traditional widgets. Has a GUI builder (Qt Designer) where you can just drag and drop widgets. You can generate a class from the Qt Designer .ui files. The Qt with C++ learning curve is quite steep if you don’t know C++, but there are two awesome Python bindings (PyQt and PySide). The Python bindings also have the benefit that they integrate with things like matplotlib (which has a Qt backend). In contrast to all web solutions, Qt applications can be lean.

    Background: I have used both Gtk+ and Qt for applications. I prefer Qt by a large margin, it’s better in almost every aspect: better widgets, better documentation, more logical, better look & feel in Windows and macOS. The big thing that Gtk+ has going for it is that it has bindings for more languages (since Gtk+ is written in C, it is easier to bind). So, for Rust applications I use Gtk+.

    I absolutely hate Electron/web apps. But you should probably consider it, given the amount of documentation and the size of the communities.

    1. 3

      Totally agree about Qt. Qt also comes with networking and core library with regexp, etc. support.

      1. 1

        One thing that is not specified is the language choice. E.g. if the language is Java, you are probably limited to JavaFX, SWT, AWT, or Swing

        Like I said in the title, I don’t care that much about language, I just want the best gui creation experience.

        1. 1

          Isn’t the licensing around Qt super complex though? It might work if OP is making a FOSS desktop app, but for any other situation I’d be extremely worried about licensing stuff.

          1. 2

            Complex and constantly shifting, as they keep trying new (often shady-seeming) ways to monetise.

            1. 1

              If you’re doing it for money you might be in a position to pay for a licence (and get the less-buggy edition to boot).

            2. 0

              what about cairo?

              1. 4

                Isn’t that more of a graphics primitive library (can draw shapes, curves, etc.) than a gui library?

                1. 1

                  Yes, it’s just an immediate-mode API to draw things on a surface. It is an excellent base on which to build a gui library, but there’s a lot of work between those two places.

            3. 13
              1. 15

                Tk doesn’t implement accessibility APIs on any platform, which means it’s unusable for blind people with screen readers, and probably people with some other disabilities as well.

                1. 3

                  Most of the solutions here don’t support accessiblity APIs aside from Qt and GTK. Personally, I’ve looked into writing code for libatk and it looks like a literal nightmare.

              2. 8

                libui is a small C library in this space. Can be used from any language that can interface with C and supports the major platforms.

                1. 8

                  Hi, libui-rs developer here. libui is currently quite stagnant, and while myself and several other devs have been communicating with the main developer over there, andlabs, he doesn’t have a ton of time to work on it at the moment. It’s not near feature-complete, and has some design issues that basically require memory leaks to occur in a lot of programs. Obviously this will be fixed, but I think people should generally hold off on using libui or any of its bindings (my library, ui for Go, etc) for a while.

                2. 6

                  Fox Toolkit, FLTK: those look a little bit dated, but fill your criteria.

                  You can also try Sciter, if you’re open to HTML and don’t like Electron’s bloat.

                  There are projects like ImGui or CEGUI, but are mostly for games.

                  You can also find this interesting, however it locks down the list to C++: https://philippegroarke.com/posts/2018/c++_ui_solutions/

                  There’s also very early version of Flutter desktop – https://flutter.dev/desktop – I suspect this will be interesting in a few years ;)

                  1. 6

                    I have to admit against myself, but one of the most stable GUI API is provided by MS Windows. It is still possible to run today applications written 25+ years ago. It’s definitely not the best GUI library in the world :)

                    1. 5

                      If you’re looking for something a little different and a lot of fun, might I recommend GNUstep?

                      It might also be interesting to play with one of the less mainstream paradigms, like immediate mode GUIs.

                      1. 3

                        imgui is not suitable for people who require accessibility features.

                        1. 4

                          True. A11y and, to a lesser extent, i10n are often completely ignored in the smaller or lesser-known toolkits. Electron and things built on it seem to be an a11y nightmare from what I can tell.

                          My comment was more a “here’s some fun things you can mess around with that you may not have considered.”

                        2. 2

                          I did think about imgui a bit. I think that for my purposes it will require me to keep a lot of extra state, though. Also, re-render every frame is a bit expensive. I will take a look at gnustep.

                          1. 2

                            The “re-render every step” semantics aren’t meant to imply that that’s the implementation. That’s just the mental model for working with it, and libraries like Conrod work to only re-render the things that have changed.

                            1. 1

                              I mean like, you have to rebuild the tree every frame.

                              Remember that imgui was created by a game developer; games tend not to have super complex UIs, and have to re-render every frame anyway.

                              1. 2

                                imgui was created really for game development tools, not even real game UIs. It’s meant to be quick and easy debug UIs, asset editors, etc. The kinds of things you get loads and loads of in game development. I think almost all commercial games just do their UIs from scratch.

                                1. 2

                                  AAA game dev here. We used Coherent UI for our most recent project which is WebKit based. It’s just easier to find people who write HTML/CSS. Previous project was ScaleForm but no one would recommend that anymore as it’s Flash based.

                          2. 1

                            might I recommend GNUstep

                            Is objective-c still a thing? IIRC GCC’s support for it has diminished, which is rather ironic for a project that includes ‘GNU’ in the name.

                            1. 1

                              Afaik, clang still has good support.

                          3. 5

                            What kind of gui? What controls you need? Where will it run?

                            1. 4

                              Notebook/REPL/IDE-type thing. Desktop platforms (linux primarily, but should work with all three).

                              1. 5

                                If you don’t mind non-native widgets, I’d suggest looking at ReveryUI. Check out OniVim for an example application built with it.

                                1. 2

                                  I thought (without having any experience with Revery) that a large part of the appeal was that it compiled to native code? Or by “non-native widgets”, do you mean something else?

                                  I’ve been looking at Revery for a project I’ve been sketching out; it seems like a very nice option. If you have any experience building things with it, I’d be interested to hear what you think - one small downside to adopting the framework now is that it seems not much other than Oni2 has been built with it yet (and so there’s more concern about documentation, stability, etc.)

                                  1. 2

                                    I thought (without having any experience with Revery) that a large part of the appeal was that it compiled to native code? Or by “non-native widgets”, do you mean something else?

                                    You’re right that it does compile to native code and that’s one of it’s great benefits.

                                    Some people prefer their apps to have a “native” feel, by which I mean, buttons, input, windows, and other UI elements have the Operating System’s design. This is not what you get with Revery, each app will mostly look the same on each platform.

                                    I’ve been looking at Revery for a project I’ve been sketching out; it seems like a very nice option. If you have any experience building things with it, I’d be interested to hear what you think.

                                    At the moment I’ve been mostly playing around with tiny projects while I learn ReasonML. I do really like it, but I have not got the experience with a large project, releasing, or long term maintenance to give all the disadvantages.

                                    One negative I can give is that I feel I’ve had to learn React to learn ReactReason and Revery. As someone who mostly used Vue before rather than React this has added an extra hurdle.

                                  2. 1

                                    ReasonML is an absolute pain to setup on a new machine. I wish you luck if you follow that path.

                                    1. 3

                                      What setup are you using? It seems to be as easy as doing:

                                      sudo apk add reason

                                      on alpine

                                      1. 3

                                        I didn’t come across any issues when I did it a few months ago. Granted, I’m on MacOS so I couldn’t say if this experience is different on Linux.

                                        1. 2

                                          Maybe I should try again. Last time I tried to install anything with ML on the bottom, it left junk all over my computer.

                                        2. 1

                                          Can you say more? I’ve been playing around with ReasonML and haven’t had any trouble getting going (at least, on Linux - I can’t speak to other OSes).

                                  3. 14

                                    There is a reason for the proliferation of Electron apps. There is a huge ecosystem, and the time to ship is fairly low. There are tonnes of FOSS IDEs in electron that you could take inspiration from as well. Don’t worry about the size of binary - the intersection of people interested in IDEs/notebooks and people interested in minimal memory footprint is tiny.

                                    1. 36

                                      No, just.. no. The whole idea of making individual applications that each depend on their own copy of a fully featured web browser that, get this, will almost never be updated to patch future security issues is an extremely flawed and dangerous practice. You do not need an entire copy of chromium to edit text.

                                      1. 11

                                        you’re right that you don’t need it, but that analysis is only considering the user’s perspective, and is only considering it from a narrow frame of reference.

                                        For one thing: most Electron apps in most situations are being deployed to users who will run just a few applications at a time; less than ten. I agree that you don’t need to run a web browser to edit text. The reality is that the vast majority of users will only run one instance of VS Code (or Atom). The question is not whether or not you need it, it’s whether or not you can get away with it.

                                        For the majority of orgs, staffing is significantly simplified with Electron, because it has significant overlap with the web as a platform. You can’t seriously consider the merits of Electron without acknowledging how much Electron lowers the barrier to entry.

                                        With that said: I absolutely despise building Electron apps personally, and I loathe using them. It is, in my opinion, a terrible platform. It does, however, solve real problems that are not solved by the alternatives.

                                        My hope is that the proliferation of Electron will give Microsoft pause, and will encourage innovation in the desktop application development space. (I don’t think this is likely, but that’s a topic for another day.) It’s an absolute embarrassment that Slack takes about 3x as much memory to run as Blender, when the former is just a glorified IRC client and the latter is literally a world-building tool. But at the end of the day, Slack is taking 350mb of memory in an age where entry-level machines have 4 or 8gb of memory. For most users in most situations, the bloat just doesn’t actually matter. The irony is that the people most affected by this bloat are software people, who are the exact people that have the power to stop it.

                                        1. 14

                                          The irony is that the people most affected by this bloat are software people, who are the exact people that have the power to stop it.

                                          This is a pretty shallow analysis. The people most affected by this bloat are the people with the least capable hardware, which is not usually people in software engineering positions, and certainly not the people choosing to write Electron apps in the first place.

                                          1. 3

                                            I think that’s broadly true but I left it off because I’m having a very hard time imagining a user persona that describes this problem in a way where it really is a problem, and where there are realistic alternatives.

                                            A big sector of the low-end PC market now is Chromebooks (you can get a Chromebook with 4gb of memory for under a hundred dollars), but that’s a circular issue since Chromebooks can’t run Electron apps directly anyway, they have to run Chrome Apps, which are … themselves Chromium contexts. That user persona only increases the utility of Electron, inasmuch as that entire market is only capable of running the execution context that Electron is already using: the web. By targeting that execution context, you’re lowering the barrier to entry for serving that market since much of what you write for Electron will be portable to a Chrome App. The existence of Electron is probably a net positive for that market, even if, yes, as I said before, it’s a very wasteful foundation on which to build your software.

                                            The Raspberry Pi userbase is particularly notable here. Electron is probably a net harm to RPi 3 and Pi Zero users. Electron is a problem for the RPi userbase, but that’s a highly specialized market to begin with, and newer models of the RPi are fast enough that Electron’s bloat stops being as punitive. (when I say specialized here I don’t mean unimportant or rare, I mean that it’s notably different from other desktop environments both in terms of technical constraints and user needs.)

                                            It’s easy to say “Electron is bloated, therefore harmful to people with slow computers”, but as a decision-making tool, that conclusion is too blunt to be useful. Which users, on which hardware, in which situations, attempting to access which software?

                                            And besides, it’s not like Electron has cornered the market on writing bloated software. Adobe Photoshop is written in C++ and uses a cool 1gb of memory without a single document open. The reality is that Electron empowers beginner developers to create cross-platform desktop apps in a way that is absolutely dominating the space because it focuses on solving problems that actually exist, instead of problems that are only believed to exist. The path to getting people away from Electron is not to say “don’t use Electron because it’s bloated”, it’s for other tools to figure out what needs Electron is satisfying that are not satisfied by the alternatives.

                                            1. 4

                                              And besides, it’s not like Electron has cornered the market on writing bloated software. Adobe Photoshop is written in C++ and uses a cool 1gb of memory without a single document open. The reality is that Electron empowers beginner developers to create cross-platform desktop apps in a way that is absolutely dominating the space because it focuses on solving problems that actually exist, instead of problems that are only believed to exist. The path to getting people away from Electron is not to say “don’t use Electron because it’s bloated”, it’s for other tools to figure out what needs Electron is satisfying that are not satisfied by the alternatives.

                                              That’s not a fair comparison given how many plugins and features out of the box Photoshop has.

                                              1. 1

                                                The path to getting people away from Electron is not to say “don’t use Electron because it’s bloated”, it’s for other tools to figure out what needs Electron is satisfying that are not satisfied by the alternatives

                                                We need basically the Flash Player, without the legacy timeline or embedded VM. A cross-platform, high-performance scene graph with a small but complete API surface that developers can mate to the language of their choice, be it a VM like JS or Lua, or Python, or with D / Rust or C++ code.

                                                1. 2

                                                  the timeline and the AS3 VM are … kinda the core of Flash, so I’m not really sure what would be left. Without that stuff isn’t it basically just Cairo?

                                                  anyway, you know about Scaleform, right? Not clear by your answer if it’s already on your radar, but it was a licensed implementation of Flash, significantly more performant that Adobe’s implementation, that supported C++ interoperability, that was in its later years owned and run by AutoDesk. Using Scaleform to build the 2D UI for 3D games was a dominant trend in the games industry for over 15 years. Some people still use it today but it was cancelled years ago. https://en.wikipedia.org/wiki/Scaleform_GFx

                                                  1. 1

                                                    Not at all. Most (complex) software written in Flash over the last few years of its meaningful existence completely ignored the timeline, and consisted of only 2 frames, once being the preloader and the other being the application. The reason I think it should separate out the VM and provide only an API is to share the load / interest across people coming from different language communities who all want to show something on-screen without Electron.

                                                    Flash 2d was a lot more than Cairo, which is comparable to the flash.display.Graphics API used to draw each individual item on the stage. It’s a proper retained-mode scene graph with events and a pretty good text API built in. And Flex, which was built entirely in AS3 on top of the basic scene graph was and still is the most well-thought-out, well-documented, and easy-to-use (both for beginners and advanced cases) UI framework I’ve ever had the pleasure of working with, and I’ve messed about with bunch of them over the years. Adobe Corporate (and Jobs’ pique) screwed over a great team of talented people who built and maintained Flex, robbed us hackers of an excellent cross-platform… platform, and created billions of dollars of waste heat running multiple redundant entire copies of Chromium on desktops everywhere for years.

                                            2. 3

                                              My hope is that the proliferation of Electron will give Microsoft pause, and will encourage innovation in the desktop application development space. (I don’t think this is likely, but that’s a topic for another day.)

                                              Nope, they’re huge users of it.

                                              1. 1

                                                I mean, my first example was VS Code and I said I thought this result was highly unlikely so … I feel like I’ve already demonstrated an awareness of that fact and I’m not sure what you’re getting at.

                                                1. 2

                                                  Eep, I read it but didn’t catch that line. Sorry.

                                          2. 3

                                            the intersection of people interested in IDEs/notebooks and people interested in minimal memory footprint is tiny.

                                            In my experience the more someone crafts code, the more they care about memory footprint- even if it’s in the sense of “I’ll have less memory for testing my application”.

                                            1. 1

                                              In my experience the more someone crafts code, the more they care about memory footprint- even if it’s in the sense of “I’ll have less memory for testing my application”.

                                              I am with you to some degree - but we are talking about Notebook/repl-style applications here. These aren’t traditional applications in the sense that they are never daemonized, are always foreground applications, and are tested by manually tweaking and observing (or at least that is how I use notebooks). Also, I probably should clarify - if the application actually ships and people feel it is slow, then the effort involved in porting over to Qt or something might be justified. Most of the times, in crowded spaces, getting things to ship is more important than quibbling about memory use.

                                          3. 7

                                            Please don’t use JavaFX, Swing, Tk, FLTK — anything without Wayland support. Just don’t.

                                            I would prefer GTK 3 (or even the very exciting WIP 4.x branch of GTK, which brings GPU rendering to all the classic widgets we know and love, unlike Qt which created a whole new world (QML) for this) but here’s some more options:

                                            wxWidgets, libui, Eto are there for abstracting over native toolkits. (btw, since you mentioned IDE-like things, this Eto project uses various native code editor components)

                                            If you go with the web route, there are better ways to do it than Electron. web-view uses GTK/Cocoa native WebKit and EdgeHTML on Windows — tiny executables without dragging a whole Chromium copy around, automatic Wayland support (due to GTK), etc. Tauri is a higher-level thingy around web-view.

                                            1. 8

                                              Please don’t use […] anything without Wayland support. Just don’t.

                                              I have no interest in supporting wayland. And for people who want to use it, xwayland is good-enough.

                                              Someone else mentioned libui is not feature-complete yet. Eto is interesting, I will take a look at it.

                                              1. 1

                                                xwayland is good-enough

                                                No. Most importantly it does not support HiDPI. It’s legacy cruft, I usually keep it off. I’d like to eventually get rid of all X11 libraries on my system completely.

                                                1. 2

                                                  You’re free to do that, of course. But X11 is not ‘legacy’. It’s a standard across a wide range of Unix-like systems. It’s not going anywhere any time soon. Wayland still doesn’t have a standardised way to do basic desktop things like take screenshots.

                                                  1. 2
                                                    1. -1

                                                      That’s very nice for Android phones but they have nothing to do with desktop systems.

                                                      1. 3

                                                        I think you will find plenty of folk use or will use an ARM SBC for a desktop system.

                                                    2. 2

                                                      I don’t think the question of “Is X11 legacy cruft?” is interesting; it is what it is, and it’ll stay with us for a while. However, the problems with XWayland are very real. It doesn’t support HiDPI, input is sometimes wonky, features which expect there to be one X server used by all clients don’t work, etc.

                                                      Wayland desktops have protocols for most things, they’re mostly at feature parity with X11. You’re right that many of those protocols aren’t standard though, which sucks. There’s a lot of protocols which aren’t standard but still implemented by every serious Wayland desktop - except for Gnome.

                                                      Gnome usually just implement their own completely different protocols, and Gnome is one of the biggest obstacles to Wayland adoption imo. Lots of Wayland software either works only on Gnome, or on everything other than Gnome.

                                              2. 4
                                                • HTML is the most universal if you have a solution for the backend
                                                • Qt if licensing is acceptable and up for a huge learning curve
                                                • WxWidgets
                                                1. 8

                                                  Re. html, the overhead of a browser engine is pretty high. This would only really make a sense to run as a standalone desktop app, with some native glue for talking to the OS, so the universality isn’t much of an asset.

                                                  How much of a learning curve are we talking with Qt? Is the python API (or any of the others) meaningfully different from the c++ API in context of that?

                                                  1. 6

                                                    How much of a learning curve are we talking with Qt? Is the python API (or any of the others) meaningfully different from the c++ API in context of that?

                                                    Qt is much more than just a “GUI library”, it’s more of an “application framework”. Whether that’s a good or bad thing depends on your tastes and what you want to do.

                                                    I always used the C++ docs when writing Qt in Python, the API is pretty similar and AFAIK there are no good docs for just Python. It works but you do need to make a mental translation.

                                                    Personally I liked working with Python/Qt (more than e.g. GTK), but I found it does have a bit of a learning curve.

                                                    1. 1

                                                      What is the Python’s added value then? Is it only a binding (i.e. if I already have Python code, I can easily add GUI using the same language)? I used Qt only directly from C++ and it was relatively comfortable (including the memory management).

                                                      1. 4

                                                        For many people programming in Python instead of C++ is a huge added value. I’m not interested in starting a “C++ vs. Python”-debate, but a lot of people simply prefer Python over C++ for all sorts of reasons (whereas others prefer C++, so YMMV).

                                                        1. 1

                                                          Then I understand is just as a binding. Which is perfectly OK. My intention was not to start another useless flamewar. I just wanted to know, whether the Qt+Python combination can offer something more than Qt itself when the developer is not much interested in Python nor C++ and both languages are for him just the way to create a Qt GUI layer of an application.

                                                          1. 1

                                                            Yah, I know you didn’t want to start a flamewar, just wanted to make it explicit :-)

                                                            And yeah, PyQt doesn’t really offer anything over C++ Qt other than the Python environment. So if you’re happy with that, then there’s little reason to switch (other than, perhaps, making external contributions a bit easier).

                                                            1. 1

                                                              Yep, that’s about what I was interested in knowing too. They said there’s a high learning curve, and I wanted to know if that only applied to the c++ api.

                                                      2. 1

                                                        For how much, read one of the tutorials and see. People’s opinions differ. There’s much more, for example including a HTML displayer with the properties and javascript integration you want is orthogonal, but reading that will give you a feeling for the learning curve.

                                                        In my opinion, the other APIs are different but not meaningfully so.

                                                    2. 4

                                                      So, there are a lot of options.

                                                      If you need a desktop application with lots of forms, I would recommend Qt even though it’s a steep learning curve. I was able to figure it out within a few weeks and build a small but functional UI for a personal project. Also, if you know python, there are easier ways to use Qt.

                                                      1. 3

                                                        If you’re ok with the JVM startup time, I highly recommend looking at cjfx. It provides a way to declaratively build a UI using React style components. And you can develop your app interactively using the REPL, so you can see changes immediately as you make them.

                                                        I’ve had good experience with using Electron with ClojureScript as well. The advantage there is mainly with having better startup time, and you have access to all kinds of Js libraries for all kinds of UI and visualization components.

                                                        1. 3

                                                          Check out Delphi: https://www.embarcadero.com/products/delphi . It has a long history of shipping a GUI framework with rapid development capabilities: https://edn.embarcadero.com/article/33352

                                                          As for the price, it has a free community edition: https://www.embarcadero.com/products/delphi/starter

                                                          Licensed for use until your individual revenue from Delphi applications or company revenue reaches $5,000 US or your development team expands to more than 5 developers

                                                          1. 2

                                                            Lazuarus IDE with Free Pascal is a free alternative they can try.

                                                            1. 2

                                                              Indeed, I am actually taking it for a spin right now and pleasantly surprised by how feature-complete it is: full-fledged IDE with VB6-like RAD and debugging features; super-fast compiler, wide-ranging cross-platform support, and pretty complete documentation.

                                                              I honestly didn’t imagine it was this feature-complete. I can see why people swear by how productive it makes them.

                                                              1. 2

                                                                That’s a heck of a review. I might check it out again at some point.

                                                          2. 3

                                                            For pure C, I would say https://www.tecgraf.puc-rio.br/iup/, for C++ I would say wxwidgets, just because both use native controls and have been around for ages.

                                                            1. 1

                                                              How did you find IUP? Looks promising.

                                                              1. 1

                                                                I didn’t use it in depth, and it was a bit hard to compile, but I watched some youtube talks about it, and it seemed to have some promise, in that it has been used for real things, unlike libui it seems.

                                                                I mostly found out about it while researching for a cross platform C ui library.

                                                            2. 3

                                                              Depending on how complex it has to be you can get pretty far with Racket’s racket/gui. It starts becoming kind of a pain when you need non-standard controls (DrRacket probably already has what you need but you’ll have to search for it), but especially for distributing it’s great, because it’s all in the standard library so you just need to install DrRacket to be able to use it, and you can easily generate a self-contained executable. And it works cross-platform!

                                                              1. 2

                                                                How is the performance? I have heard racket is slow, but that may be out of date.

                                                                1. 3

                                                                  It’s probably out of date; Racket has been doing JIT compiling in their VM for a while now. They’re in the middle of porting to the Chez Scheme runtime which can have significant performance improvements: https://docs.racket-lang.org/guide/performance.html#%28part._virtual-machines%29

                                                                  As far as the API goes, Racket is by far the most pleasant way to code a conventional desktop GUI that I’ve ever seen.

                                                                  1. 3

                                                                    Is it compatible with accessibility tools?

                                                              2. 3

                                                                Who are the users? In which toolkits are written their applications? What are your priorities?

                                                                • Best integration with their desktops and native look and feel?
                                                                • Best integration with rest of your application (backend, libraries) or your knowledge (languages you already know)?
                                                                • Best UX (regardless the desktop and rest of your application) or some unique GUI features/widgets?

                                                                How much time do you have? Could you afford learning a new technology? Is there a boss or customer requesting the finished product before deadline?

                                                                For most/mainstream applications, I would recommend Qt. But if your users have desktops based on GTK, then GTK(mm) would be probably a better option (however Qt also does not look bad in Gnome). For some people Qt is too heavy, has too much legacy and „we can write a better GUI toolkit without reusing 20+ years old code“ – there are use cases where something lighter than Qt would be better. Such frameworks exist (however their GUI usually look worse or sometimes ugly or outdated… but it is light and sometimes the best option).

                                                                It is also possible write the application in multiple languages, separate the backend and frontend, connect them through D-Bus, SOAP or other protocol over STDIO or socket, C function API or something else. You can even write multiple frontends e.g. Qt and GTK to fit most desktops…

                                                                But if you are asking for a solution that brings the least amount of work, then just take the language you are most familiar with and look for its best practices for GUI (nothing bleeding-edge, rather mature solution that is battle-tested and also seems to be supported in future). It would not give you the coolest-looking GUI or extremely low complexity (library/toolkit lines of code) but it will allow you to get the job done and finish the project before deadline.

                                                                1. 2

                                                                  Who are the users?

                                                                  Primarily me.

                                                                  What are your priorities?

                                                                  Development experience and application UX. I don’t really care about look and feel/integration.

                                                                  Time is unlimited; it’s a hobby project.

                                                                  Network protocol is a good idea; I will look into it. That could be the most flexible solution, so I can build the presentation logic separate from the actual GUI display.

                                                                2. 4

                                                                  It doesn’t satisfy your requirements but Cocoa is incredible.

                                                                  1. 1

                                                                    There’s gnustep…

                                                                    1. 1

                                                                      Yeah that’s true. I tried it briefly on Linux and it seems to work well except for 2 issues:

                                                                      • I couldn’t figure out how to get it into the GNOME taskbar (probably an easy fix)
                                                                      • No APIs past Mac OS X 10.4 (not a dealbreaker)

                                                                      I don’t understand why GNUstep isn’t more popular. Do people dislike Objective-C that much? Or maybe the build environment is too intimidating?

                                                                  2. 2

                                                                    As you’ve alluded to, there will always be some suck. For instance, I’ve found that Qt is not very good on mobile (but many of these frameworks struggle on mobile a lot). I would pick Qt for desktop but if you need to use it for mobile, try to use native or your app will feel very off. No matter how much work you put in, it’s very difficult to capture the feeling of a native app. Even I can not describe it too well, but the animations, swiping, and movement needs to feel much more natural or people won’t like it. If you’re not trying to make a killer app, this may not be a huge deal.

                                                                    1. 2

                                                                      I’m also looking for one right now for a small GUI app I want to run on Windows, Linux and Mac OS - and honestly I don’t see a way around Qt. I’ve used it in the past in the form of bindings (Python) and since I work with non-GUI-Qt for a little over 2 years now I don’t see any huge problems, so I’m warming up more to the thought of using it here as well. Only did a small C++ Qt app once, so not a huge ton of experience.

                                                                      Nothing in Java-land has ever excited me, it always just felt adequate. Also it’s not really native, you need to deliver a Java runtime if you want it to be truly standalone.

                                                                      I simply refuse to use Electron for an app so small as I need it.

                                                                      1. 2

                                                                        https://developer.apple.com/xcode/swiftui/ with the caveat that’s it’s cross-platform (and free) only in a rather shallow sense ;)

                                                                        1. 1

                                                                          Recently found WDL[1] made by Justin Frankel (of Winamp fame). It’s used by Reaper, a popular music editing tool.

                                                                          [1] https://www.cockos.com/wdl/

                                                                          1. 1

                                                                            I am not a GUI programmer, but when I have to build one, I usually reach for either TCL/Tk or Python/TkInter, which many others have already mentioned. In particular, TCL/Tk’s canvas widget is really nice for building interactive visualizations. If you just want a one-off prototype, a visualization, or a simple internal tool, Tk is really quick to develop in. That said, it’s been around the block a few times and definitely creaks in a few places. It probably won’t scale as well as others will.

                                                                            If I need more performance, or I have to interface with a lot of C code, I like libAgar. I don’t see it mentioned much on the ‘net, so I wanted to drop it in this thread. It has a pretty nice API (as far as C APIs go), and I’ve found it easy to delve into the source code to fix bugs or add features as needed. It’s also really portable, so it might be useful if you want something that will run on embedded or otherwise “weird” systems. The default theme is not as flashy as others, but it can be styled via a system similar to CSS. Come say hello on #libAgar on FreeNode!

                                                                            1. 1

                                                                              “Least sucky” is loaded.

                                                                              By “Free” I interpret this to mean Free/Libre Software, not cost. Otherwise my answers may vary slightly.

                                                                              Least sucky for development depends on your own personal strengths and weaknesses. I happen to think that Electron and Gtk are the most sucky, but many others would disagree with me.

                                                                              Least sucky for users is slightly more concrete: you want a mature library with stability, accessibility, and translation as first class citizens to give users the best possible experience, so now you’re looking at Qt or WinForms (via Mono) as top contenders. I’m actually surprised at how few people mentioned WinForms; Mono’s implementation uses Gtk so you get the benefits of that platform without having to actually write Gtk code.

                                                                              I personally will fan-girl Qt until the day they die, but the concern there is that they might sooner than later with the decisions they’ve been making lately. It’s still, however, the best and least-sucky toolkit in my opinion.

                                                                              1. 1

                                                                                I think it depends on what your going to be most productive with. If it’s Java, then do JavaFX, if web languages then electron, etc.

                                                                                There are a lot of people who love to hate on tools they don’t like (particularly electron), but at the end of the day you should spend your time focusing on building your tool with the languages you know best.

                                                                                Perfect example is Minecraft. It has gotten tons of hate over the years because it’s written in Java. But at the end of the day, it got built and sold and used.

                                                                                1. 1

                                                                                  I am not particularly biased towards any language. I don’t especially like javascript or java, but there is typescript and other jvm languages with good interop, so it doesn’t really matter.

                                                                                2. 1

                                                                                  I recently built a video player front end in PyQT5. I would highly recommend it:

                                                                                  https://gitlab.com/djsumdog/mpvbuddy

                                                                                  1. 1

                                                                                    I recently use https://fyne.io/

                                                                                    I come from a background of never do GUI before to a working app in one week. Which I’m very sastify.

                                                                                    The best: it works on win/linux/mac/ios/android. I havent tried Android/Win yet. But my simple app were able to run on mac/linux/ios just fine.

                                                                                    All dependencies are automaticlly download/ I don’t have to install extra thing outside(like QT etc)

                                                                                    1. 1

                                                                                      IUP is a good option: https://www.tecgraf.puc-rio.br/iup/ It wraps over Gtk+/Qt/Cocoa, it has bindings to many languages (core in C), it has a small API which makes it easy to learn (message-passing-like instead of lots of methods), it has a lot of widgets (but I missed one: a tree table with columns), it has ongoing work for iOs and WebAssembly.