GUI frameworks are big because they do a lot. These minimalist things usually only work until you reach the limits of what they can do and then you have to rewrite in something like Qt anyway, or sacrifice what your users want in a GUI for your own code aesthetics.
It doesn’t even take much to reach the limits of tiny GUI toolkits. Very common things like native file/directory selection dialog (preferably with format/suffix filtering) rule out a whole slew of “tiny GUI toolkits”. You can use a puny GUI and find out halfway that widgets you need just aren’t there or require tremendous customization efforts, or you can use Qt and have the widest selection while conforming to accessibility standards and at the same time not look like crap. The choice is obvious to me (after hard-earned lessons).
> Very common things like native file/directory selection dialog (preferably with format/suffix filtering) rule out a whole slew of “tiny GUI toolkits”
I've found nativefiledialog to be quite good for that use case
Is Qt so bad by modern standards? Admittedly I don't have hard numbers, but I believe it's far less bloaty than Electron, even when using its web-like features (QML and JavaScript).
Let's not forget just how low the bar has been set by Electron. Microsoft Teams manages to use 600MB of RAM.
The opposite is true, people move away from Qt because even if it's more complete it's also heavy. Of course, it has internationalization and accessibility. The smaller API, higher performance, faster development of Dear Imgui is more important for me.
Some reported that moving from Qt to Dear Imgui resulted in a codebase three-time smaller.
It’s be helpful to have some concrete examples of where one might run into limits with the minimalist frameworks and why a larger framework is required to overcome those limits.
file open/save dialogs, i18n, drag and drop, image formats, web views, any sort of accessibility, themability that actually fits into native platforms, sometimes the ability to open new windows, many common controls that we just take for granted now that you have to implement yourself, sometimes limited amount of events you can reasonably handle based on the design of the api (IM gui's for instance).
I wouldn't say never use an minimalist framework. It can be handy for embedded debugging tools or for toy projects. But I wouldn't use one of these things for an application that I thought might have a few thousand users and some sort of life span.
Thanks for the list. I'll keep these in mind for my next GUI project. I've used Qt a few times for hobby projects, but was thinking about trying something else for my next GUI project.
I disagree with the author, it's really easy to test the examples of Nuklear.
I made applications with Nuklear that runs on Android, iOS, macOS, Windows and share the same main C code. For me, it's a dream come true if you create a cross-platform application that needs a simple GUI.
Dear ImGui is also fantastic and more complete than Nuklear.
What I like a lot with Nukear and Dear Imgui is that you have a GUI that is GPU accelerated and so can be updated at 60 FPS without burning resources.
I hope the applications you made with Nuklear and Dear ImGui were only for fun, and not important for someone's job, education, or other essential tasks, because those toolkits have zero accessibility, e.g. for blind people with screen readers, as well as people with other disabilities (e.g. those who require voice or other alternative input methods).
Ah, cool. I would be more concerned if you were developing an application that was actually used by the musicians. I find it ironic that "blind musician" is such a stereotype, but many applications and plugins targeted at musicians are inaccessible.
They are perfectly suitable for regular app.
You don't need to update them at 60fps, you have the entire control of the rendering state, so you could decide to update the gui whenever it is needed and not at a constant fps.
The common solution is to only update rendering when input happens, and otherwise sleep. That's fairly common for ImGui applications outside games (in games it doesn't make sense of course, since those usually render each frame anyway).
The Android NDK is a toolset that lets you implement parts of your app in native code, using languages such as C and C++. For certain types of apps, this can help you reuse code libraries written in those languages.
Interesting. I was under the impression that all apps on Android would run inside a Java sandbox, but apparently this is not the case. However, now I'm wondering how safe it is to run apps that might contain native code.
"The solution (hint: there wasn't one until now)..." That's quite the bold statement. I actually thought of IUP/Lua when I saw this line, and it turns out you precisely used IUP for the UI portion of your framework! Except you didn't use the Lua binding, instead you created a Janet binding.
Using something like luastatic[1], with whatever Lua libraries you want (including IUP), you can get something pretty similar to this system, except of course you'd be using Lua instead of Janet. Janet is really interesting and that alone justifies this framework very well.
Yea, sometimes when I get to rambling I can be a little bit overly opinionated/bold in some statements. Python tktinkter is also in a similar vein - what I am putting out is more of an aggregation of other's hard work (cross platform packaging?) more so than anything I've directly innovated.
However, even in the python sample, I couldn't find anything that was just "Download, Unzip, Modify" to start creating (all seem to have cumbersome install steps or hoops to jump through - I basically wanted something that was 0 configuration/installation, for fast iteration and development).
Speaking of aggregation, what motivated the license choice? It appears that only one dependency (Mongooos is GPL), and the choice of GPL will seriously inhibit any adoption of a toolkit like this.
This sounds close to the GUI setup I've been looking for: something like Love2d except using Lua to create a WinForms program instead. Which led me to finding http://underpop.free.fr/l/lua/luainterface/ which might just be it.
> The new crop of immediate mode cross platform GUI libraries are more interesting (such as nuklear and Dear Imgui).
They're also completely inaccessible to blind people (using screen readers) and probably some people with other disabilities as well. IUP is at least partially based on platform controls. I'll take usable over interesting.
Some platforms do have APIs like that. For example, on Windows, UI Automation is not tied to any particular UI framework; the UIA tree just needs to be associated with an HWND (Win32 window handle). But implementing these APIs is a lot of work. And I imagine it would be especially challenging for an immediate-mode toolkit, because an API like UI Automation is based on a retained tree of objects that the screen reader or other assistive technology can query on demand. So I figure applications are more likely to be accessible if I warn developers away from such toolkits altogether.
For anyone needing a simple and fast cross-platform toolkit for C++, FLTK is really good. It is easy to build and statically link only the parts you need, and the API/widget selection is pretty good. It looks a little old school/non/native, but it has been useful for me.
FLTK is just very spartan compared to e.g. Qt; from my point of view it is only useful for very simple GUIs; I hardly have any applications anymore that do not need item views or rich text.
Well, there is also Tcl/Tk and some others, but they are all at most half as powerful as Qt. An interesting alternative could be Flutter; however, you have to write (at least) the GUI in Dart, which is not everyone's cup of tea.
Tk is just a shared library accessible by any compiled language; there are many C/C++ cross-platform applications using it; it was actually also the first GUI toolkit used by Python; it's true that it includes Tcl which is a scripting language, but that doesn't matter much. It's nearly as lightweight as FLTK and Fox toolkit.
Applications AOT compiled with the Flutter SKD are surprisingly lean (i.e. compared to Node/Electron) and not much larger than Qt applications.
That definition of cross-platform is a bit too narrow for my taste. I think a more reasonable definition of "cross-platform" would be "covers 2 or more roughly equal platforms". I mean no-one expects an app developed for a windows workstation to run (and be usable) on an andriod phone, even if it used a cross platform framework. But most would expect to be able to run it on linux or mac.
With opengl, libuv, and libcurl, and Dear Imgui, I can write a C program resulting in a binary that's about 400kB unstripped, to put 5MB in perspective. And for a simple program like what you wrote, I don't even bother trying to free the memory myself sometimes, I just let the OS free it when I exit. With that design choice in mind, the end code is like <1000 lines, and a decent bit is reused snippets.
In the end, this feels like a an appraisal of IUP and Janet more than a demo of anything new. If that's the case, then familiarity with your stack is more important for this kind of productivity than anything else, so trying something new is less appealing to me.
But I was curious about Janet, so seeing some examples was nice.
Dear imgui looks very cool (I had missed that one), and like nuklear, a strong candidate for very customized look and feel - but I think it glosses over things much like nuklear does, by showing what seems to be small/simple samples, and prefixing it with a statement such as "after it's set up" (and it doesn't bother to show the other 1000 lines said setup required).
But you are spot-on that this is more showcasing the joining of various other things out there, rather than anything innovative (although I do plan to add more and extend the existing convenience wrappers, such as wrapping the IUP calls in a hiccup-like DSL using Janet macros).
Those "1000 lines of boilerplate" is why imgui and nuklear are so popular. If you're on a commonly used platform, say SDL and OpenGl, you can just copy all or most of it. But the magic here is that imgui and nuklear will integrate into any engine or rendering api you can imagine.
To simplify a little, you pass these libraries the events from the windowing system and it gives you a list of triangles back. Then you feed the triangles to the GPU and you're done. All the logic (and nothing but the logic) is done by the GUI library.
This is why dear imgui is perhaps the most popular GUI library in the world. It's used in a lot of game development tools, etc.
If anyone is interested in the topic, I am writing a lightweight flexbox-based retained mode GUI layout rendering library that integrates like imgui/nuklear. Give me a shout if you want to know more.
I haven't shared the code in public but if you give your GitHub username, I can share it to you (and others who are interested) and you can reach out via email (address in commit log).
I got inspired by Raph Levien's talk on Rust and GUI layout [0] and realized that a simple flexbox layout algorithm can be implemented really efficiently.
So I started making a prototype in C (also a small proto in Rust), using a densely packed array to implement a DOM-like tree. The tree nodes have short strings, boxes (with border, padding, etc), images (texture coordinates in an atlas), layout constraints, containers, etc. Flexbox layout is applied to the tree in linear time (and constant memory!) and then the tree is traversed to output an ordered list of axis aligned rectangles.
The output list can be fed to the GPU, where a special (but simple) shader draws clipped triangles that get applied with textures, msdf font, etc. The whole GUI gets rendered with a single draw call.
This all can be done with very fast performance (sub-millisecond for layout and rendering, excluding GPU latency). There are other implementation details that make it efficient for cache (sizeof(node) == cache line), no recursion, no memory allocation, no unbounded loops, no system calls, etc.
I'm fairly convinced that this approach should be enough to cover 80% of modern GUI paradigms. However I don't have the time or the interest to build a complete widget set GUI library.
Right now I'm sporadically working on the project with a goal to make a game UI with clickable, scrollable and scalable text and images with a modern layout. Right now all I have to show is some ugly text and rectangles (but with a very nice layout), but it's a start for a project with potential.
Interesting pitch for Janet. Here [1] is a quick rewrite in Red language, which lives up to the author's requirements: 10 LOC, native support for all 3 major platforms, can be shipped as a single binary, and all that's required is a 1MB toolchain.
However, the elephant in the room (which I also like to ignore as a Clojure enthusiast) is that the start up time of a Java based GUI app is too slow (this is exacerbated even moreso when Clojure is involved)
I'm expecting a GraalVM rejoinder from someone. For anyone who's used GraalVM (particularly with Clojure) - what are the downsides and limitations?
A JavaFX hello world app starts in around 1 second on a modern computer. Here's a small demo of a self-updating JavaFX app where you can see it being started, then built again, then re-launched with the new version: https://github.com/renatoathaydes/keepup/blob/master/docs/im...
If the author's app takes 10 seconds to boot, I am afraid they need to blame either Clojure or their own code for that.
That is a common trend on JVM guest languages, to blame Java or the JVM for their impedance mismatch with the host platform.
Granted, this usually only comes from those that don't bother much to learn about the underlying platform and are sometimes even agressive against what actually made their favourite guest language possible to exist.
> what actually made their favourite guest language possible to exist.
maybe i'm arguing semantics, but i don't think it's fair to say that the JVM "made Clojure possible" -- that's like saying "C made Python possible because CPython is written in C".
iirc the JVM was chosen as a backend because that's what Clojure's creator had to work/interop with. and i think that's generally the case with "guest" languages -- there's an environment you want to write code for (JVM/ browser), but you don't want to use its "official" language (Java/JS), so you create a new language and adapt it to run there.
and sure, reusing the Java stdlib and other existing code can help bootstrap a language, no doubt about that, but it's a stretch to say it makes it "possible"
Clojure's success lies in being a Lisp that takes advantage of the JVM libraries and JVM monitoring tools, without them it would be just yet another Lisp clone like so many others since the early 60's.
i guess i was being a bit pedantic... as you say, if you look at Clojure's whole programming environment (tooling, stdlib) and not just the language itself, putting it like GP did makes sense.
I'm building a TornadoFX app with Kotlin now and it also starts in about a second. Also there is FXLauncher ( https://github.com/edvin/fxlauncher ) which provides a native package and an auto updater for macOS, Windows and Linux.
This is a really cool usage of it: https://github.com/borkdude/babashka, but last I had checked, it didn't have any GUI integration, and installing the GraalVM to begin with is a very heavyweight install.
Yes I've installed babashka. It really is a cool project.
Must look into GraalVM at some point, but, as someone new to Clojure, I'm wary of spending too much time on tooling yet. I've found in the past I can tinker so much with such things that it interferes with getting fluent with more fundamental stuff.
I'd be interested to see if either now or in the future Clojure + JavaFX in GraalVM would be feasible.
Edit: I don't quite get the install size issue - I thought native image was an entirely standalone executable?
What about macOS? So far Racket seems like the easiest solution for a lisp with easy cross-platform GUI support (Linux, Mac, Windows). It would be nice to have more easy choices, but also nice if all 3 major platforms were supported.
Racket is so nice, but try to create a GUI with it and see how heavy the resulting app is... I wrote a simple one just to play around with it, but was really disappointed by how slow and heavy it was.. it took over 250MB of RAM to show a shape on the screen.
I've been using racket/gui for a while now. It only comes with a small handful of widgets; if you want to use racket/gui for anything beyond the bare basics, you'll be implementing a lot of your own widgets. Want a text-field% with autocompletion? You'll have to write that yourself.
Sure. But having even basic crossplatform GUI support baked in is a pretty major thing. I haven't tried to work with McCLIM before (and it's not crossplatform anyway) and the other Common Lisp option is Qtools, which seems rather more complicated than the integrated GUI stuff in Racket.
In reality, if you want to actually make a serious, usable and comfortable GUI, there is no cross-platform solution. There are many attempts, but none will let you create a GUI that actually fulfils all those requirements.
If you are making something serious, you will have to implement at least the GUI layer separately for all platforms.
> In reality, if you want to actually make a serious, usable and comfortable GUI, there is no cross-platform solution
Qt? Tk? I've used both cross-platform and both work great for desktop operating systems (and unlike in the olden days, Tk's themed widgets actually look reasonably native now). Qt's only downside is the licensing and the sheer size of it, and Tk's only downside (for my use cases) is the lack of an embeddable browser widget; in both cases these are issues regardless of platform.
The actual cross-platform issues, from what I've seen, are more to do with the non-GUI pieces. For example, Windows and macOS/Linux printing are wildly different from one another, and all three operating systems have wildly different strategies for packaging and distributing applications (especially when writing the program in a scripting language like Python or Ruby or what have you instead of something precompiled like C++ or Rust; with Linux this is trivial, and with macOS this is less trivial but manageable, but with Windows this is a royal pain in the ass).
On another note, I'm currently looking into Avalonia and .NET Core as another potential option in this space; from preliminary testing, .NET Core looks like it mostly addresses the issues I've encountered (it certainly makes it easy to cross-compile for Windows/Mac/Linux, and I'm hoping it'll eventually subsume Xamarin or portions thereof to enable easy Android and iOS builds, too), so whether or not this becomes my go-to hinges on whether or not Avalonia itself is ready for primetime (and while simple examples seem to be promising, as are more complex examples like the Avalonia version of ILSpy, I'm still actively investigating).
If looking reasonably native is indeed "miles away from the goal", then I'd argue the goal betrays excessive and needless attention to pixel perfection instead of more important things like, you know, the actual functionality of the app. No user would even notice these differences (let alone complain about them) unless they were both really savvy and really nitpicky.
Comparing Qt v. Tk v. native on Windows and macOS (and Linux, but there is no "native" toolkit so there wasn't anything to compare), not once did I notice any actual significant difference. macOS is the only one that required the slightest bit of adjustment (for the stuff I wrote; no idea about the Qt or Tk programs others wrote), and that's only to make sure it uses the system menu bar instead of shoving one into the top of the window as is normal for Windows and (usually) Linux.
It is not "pixel perfection". It is many things besides, such as behaviours, generally agreed-upon layouts, spacings and margins, accessibility, the list goes on and on and on.
I have not seen a Qt app on macOS that did not stand out like a sore thumb on the very first glance.
I'd say "spacings and margins" fall into the "pixel perfection" category for pretty obvious reasons.
Divergence in "behaviours" and "generally agreed-upon layouts" is possible even with native toolkits, so I fail to see how Qt or Tk are a relevant factor here (both of them give the programmer the necessary tools to match the native behavioral and layout conventions, just like the native toolkits do).
Tk definitely has a disadvantage in the "accessibility" category, but Qt literally uses and abstracts the native accessibility interfaces¹, so in Qt's case this should be a non-issue (beyond the typical considerations for software accessibility that apply even for native toolkits, like, you know, actually leveraging and testing those features).
> I have not seen a Qt app on macOS that did not stand out like a sore thumb on the very first glance.
Okay, but by virtue of knowing what Qt even is, I'd wager that you ain't an ordinary user. The vast majority of end users will neither notice nor care (especially given that there's an abundance of commonly-used software that deviates from the typical macOS UX even without Qt, e.g. Office and Chrome, or pretty much every single app using Electron or CEF or some other browser-as-UI approach). The only thing that truly matters is whether or not the software works and is usable, and Qt doesn't really pose any obstacle there (and Tk only does if accessibility is a concern - which I'd argue it should be, but it's at least no worse than the status quo).
Why do I keep seeing people say this? People have been doing this for 30 years.
Fltk will let you do it in 700KB with no dependencies. (100KB if you're crafty). Juce, Qt, pyQt, opengl+imgui, opengl+nanogui all work well. There is also gtk, Tk, wxWindows ...
The idea isn't that you can't have some windows with text and buttons displayed with the same code on all platforms but that these windows, text and buttons wont look and behave like they are supposed to and expected by the users of each platform.
Now, outside of macOS this might not be much of a problem since Windows users were beaten into submission to accept any arbitrary look and behavior and Linux users never had a choice anyway.
"People complaining about buttons looking different" is a problem.
But it isn't just "buttons looking different", it is also "buttons behaving different". As an example (that i often find annoying in programs with long lists), under Windows Qt scrollbars do not behave like native Windows scrollbars: shift click in Windows should cause the scrollbar to scroll at the point you clicked (like middle click on most X toolkits) but Qt ignores that.
Also it is "buttons not integrating properly". On macOS it is very common for example to have system-wide addons (services i think they are called) that add additional functionality to text fields, like "search with google", "text to speech", "show definition", etc. This doesn't work when a toolkit does its own text field controls. You can also see a similar thing on Windows: GTK+ applications (e.g. GIMP) ignore the emoji panel in their text fields that appear with Windows+; but native text fields work fine with it.
Now note that i'm not saying this is something that matters for all sorts of applications or is always a deal breaker (especially nowadays that, as i wrote above, most users outside of macOS have been conditioned to accept these), but it isn't something that you can handwave away as "having a different shade" either.
> Now note that i'm not saying this is something that matters for all sorts of applications or is always a deal breaker
The more serious issue that nobody here has yet mentioned is lack of accessibility, e.g. for blind users with screen readers, in many toolkits. I say that is a deal-breaker if you're developing any kind of application that someone is going to use in their job, education, or other important tasks, unless the task is already inherently visual in nature. Qt has passable accessibility on Windows, Mac,and desktop Linux. GTK is accessible as part of GNOME. Electron, for all its faults, is as accessible as Chrome (pretty good these days). FLTK, FOX, Nuklear, TK, and a thousand other toolkits have zero accessibility. I've grown weary of bringing this up, and some of you may be tired of seeing it, but I feel compelled to do everything I can to make sure nobody overlooks this point, lest someone develops an inaccessible application that prevents someone else from doing a job, taking a course, etc.
Edit: I realize that was a rant. What rubbed me the wrong way about your comment was the suggestion that the problems with cross-platform toolkits are mainly cosmetic things or extra functionality that only spoiled Mac users care about.
Uh, i think you need to read again what i wrote as i explicitly write that there are more issues than just cosmetic things and accessibility is one of these - i just brought simple examples that anyone can test by themselves right now.
But also yes, not every program has to care about these, including accessibility. An image editor or a level editor for some game or some internal and/or throwaway tool that has a very explicit "audience" has no reason to bother about these.
Nah I agree accessibility is super important, and exactly the thing you'd want a UI framework to encapsulate. I don't necessarily think it's essential--people should be able to determine their target userbase themselves--but if you want to be a mainstream UI framework that competes with Electron, it's table stakes.
I've really enjoyed J so far. Pointless has been fun. Brat was an interesting one to work with. Pony and Nim are both pleasant. Hy was a fun way to do Numpy lisp.
I'm digging in to Chaos and then Janet after that.
You have eight error conditions to discuss. Use 'Talk about errors' to decide how to handle them. Right now, the answer is 'ignore first, or just explode'.
>Push
Pushing transcript to GitLab.... Building App.... Pushing Build to GitLab.
