The outlined problem in the article has all of the requirements of a full GUI toolkit, yet the only GUI toolkit looked at is discarded as being too much. The proposed alternative is to recreate XUL in JSON. I weep for our industry.
Yes, I too read the article, and it came across to me as dismissing many GUI development options for one single reason or another, maybe without checking to see if there were any solutions or workarounds to the issues of each of them. Might be a perfectionist point of view.
Not an OCaml dev- it looks like wxwidgets has bindings, which is what I'd use for 'minimal'. But a text editor with the type of features he wants is not minimal.
> I wanted something reasonably fast, with a simple way of producing graphics.
Use the text widget in tcl/tk. It can display graphics and is powerful enough to build an old HTML 4.01 editor.
> I wanted to draw a horizontal line between the name of the file and its contents.
Use the text widget in tcl/tk. You can hard-code a base64 encoded gif/jpeg of a horizontal line, store it in memory, and display it wherever you need a horizontal line.
> I wanted to be able to open new instances/windows of this text editor quickly to fit into my workflow.
Use the text widget in tcl/tk. Tk's design is the old-school multiple-toplevel-window paradigm which is perfect for this use case.
> And I wanted low-level control of how the text was rendered (fonts, syntax highlighting, and the ability to add vim keybindings.)
Use the text widget in tcl/tk. It allows you to tag particular parts of the text which you can later manipulate. But it is way more lightweight than the DOM.
Everyone complaining about the state of UI development should give Dear Imgui (and similar immediate mode UIs) a whirl. It may not yet be the right solution for all types of UIs, but it makes creating UIs fun again and the productivity is astonishing.
Unfortunately usual system-wide settings and accessibility features seem to suffer (be ignored) if those are used, just as with cairo (or SDL). The other methods mentioned in the article seem to be better in those aspects, unless they are explicitly made to be less so.
It's silly to discard GTK as overcomplicated because it is designed for more than "a few buttons and some text". Surely the author's JSON idea would end up in the same place. After all, it's a GUI toolkit that is going to be serving the needs of many different applications; just in the flavour of the month, instead of a shared library. (And as far as GUI toolkits are concerned, GTK generally strikes me as quite modest. It has a lot of widgets, but they aren't terribly redundant, and it doesn't have stuff like an analog clock widget for that one developer who wanted an analog clock. And the odd ones that are there, like the different kinds of buttons, are pretty transparent quality-of-life helpers where it's clear how to make your own if you want).
With that said, nobody cares about GObject Introspection in OCaml. So unless you want to maintain that, you're stuck with an ancient wrapper library for GTK2, which is pretty sad. I definitely would avoid it.
If we're going to discard GTK for a reason that isn't "I probably picked the wrong language", I'd add that it's challenging to target non-"Linux" platforms with it, but then your best option for that is Qt, and if you pick Qt you probably aren't using OCaml…
So I can see where he's coming from, at least for OCaml, but, uh, JSON?
It's not obvious to me: why wouldn't someone using OCaml use QT? I see some bindings; is there something that makes QT less appropriate than GTK, e.g. C++ vs. C?
Actually, looking back at it: I've been living under a rock and oblivious to how successful Qt Quick has been :b Before I lost the plot, Qt relied on a lot of C++ particulars (and they used to recommend their own precompiler for some features), so it was trickier to work with it from other languages. Some of that has been improved over the years, and it has a simpler surface nowadays with Qt Quick, so, yes, use Qt!
> I see some bindings; is there something that makes QT less appropriate than GTK
Qt has a long history of bindings coming and going to the point where I wouldn't trust any of them to last unless they come from the qt team themselves. Couple this with c++ making binary compatibility much harder (https://community.kde.org/Policies/Binary_Compatibility_Issu...) and you've got a recipe for frustration.
I got excited about the headline, because I whole-heartedly agree with the statement, but then the author’s answer was to reinvent HTML with doodads.
I was hoping this would be a call for a higher order of expression which could be interpreted by lower order frameworks, but alas. I think the author is confusing the technology with the tools. The tools for building interfaces haven’t changed a whole lot in the last decade.
Why are you open to all manners of options except language option? I don't think you can call GUI development broken when you set your own broken parameters. Consider broadening your options. Now having said that, GUI development is broken, but that Qt isn't even mentioned makes this blog post broken. At least prepend "Cross-Language" or append "in My Language" to the title.
>This afternoon I sat down to write a mini text editor.
i understand reinventing wheels is both fun and educational and grants a deeper understanding of wheels in general, but the way that statement reads is... over confident. the idea that any nontrival standard tool for software developers can be written in an afternoon, presumably from sratch, starting cold, not even done with preliminary researche (as evidenced by the rest of the article), is just silly.
>I wanted this to be easy.
has the author ever programmed anything at all these things are never "easy" just "easier than once thought", which is rare, and "inexplicably more difficult and obtuse, and motivation enough that time is better spent on other projects" or somewhere in between.
Was there ever a more productive GUI programming experience than Delphi? It's been more than twelve years since I used it (or developed on Windows for that matter), but it was so powerful and fast.
You're not misremembering. There was an enormous setback in the usability of GUI programming when the web was invented. The first reason is that the whole platform is built on the jagged rubble of the 90s/2000s platform war. But the second is just that, with so many different languages and systems in play, tool and library support just can't keep up. What made Delphi great was that there was one integrated framework that knew about everything from your visual design to your databases - you could integrate them all, get autocomplete, etc.
These days, we write Python that generates SQL in order to generate HTML, then write Javascript to talk HTTP to the Python and then generate HTML that gets interpreted into the screen by CSS...and there is no way a tool can present the result of that in a coherent manner (let alone autocomplete it!).
(I get an up-close view of this because I cofounded Anvil - https://anvil.works - which does the complete opposite of this at every level. All in Python, one framework, all autocompleted - basically a modern Delphi for the web.)
I thought Delphi was mostly dead. I saw a job listing recently and thought it would be kind of cool to go back to it. But when I checked the Tiobe index it's still quite popular at number 11, notably it's above Swift and Objective-C, so apparently it's far from dead.
It isn't dead, but it should be: I sometimes support legacy Delphi code.
We use the XE7 version of the IDE, which is excruciatingly slow on a laptop with an i7 7700HQ processor, fast nVME SSD, and 32GB RAM. Oh, the IDE is 32 bit so it runs out of memory. The IDE also crashes a lot (I have never heard of a stable release of any version of Delphi). Our codebase still compiles on Delphi 7 (from 2002) because it is a better developer experience than thier modern versions...
Trying to find good components was easy in 2002, but it can be impossible now. All the good component developers moved on to more profitable targets. You can't find good open source components because no developer can afford the annual costs to get new versions of the compiler and compile components.
Yes, Delphi was great. I'm talking about earlier versions, but current versions are good too. [Disclaimer: Only used them lightly.] The two cons I see are:
1) the trend towards greater and greater complexity and more features as time goes by and as version numbers increase.
2) the cost, of course.
Edit: Also, as others point out in this thread, some versions of it were reportedly moderately to quite buggy.
And as someone else said in this thread, Lazarus is an option.
My first response to the article was Ctrl+F Delphi in the comments.
Because everything the author was complaining about was solved in Delphi in mid-nineties.
Heck, if he were to write for Windows, he could still use Delphi and get what they want!
For that matter, VS.NET platform would be a pretty good tool for that job too (no surprise given that the head of the project was heading the development of Delphi before jumping ship to MS).
I do not understand the article at all. We created our own GUI development using Dear IMGUI. It is probably the simplest GUI in the world. For text we use our own rasterizer library.
But it comes at a price: It just continuously draws the screen, 60 times per second, which makes the battery of laptops last very little.
Now our software uses a fork of Dear Imgui that does not update the screen but just when necessary.
Before Dear Imgui, we tried Qt, GTK, Web, Win32. Making your own widgets with hardware accelerated fonts that you control is extremely complicated in those GUIs.
pipio21: could you clarify "our software uses a fork of Dear Imgui that does not update the screen but just when necessary.", why and how did you have to fork the library? Could you share your work? Normally this decision is left to the application, as it is trivial to decide to not call any of the dear imgui function and stay idle, this is what desktop-ey applications using dear imgui that do not animate would normally do.
VSCode isn’t clunky. So is Atom clunky because webkit or because implementation?
I think you missed the target on dismissing the first option... i.e there’s a reason html/css/js is the most popular - as in popularity is a good objective median.
To get to the point, use electron with jsonSchema and a form builder of choice (I suggest Vue) but React and Angular could suffice depending on how much functionality your text editor needs.
Point is, your “answer” is pretty much reinventing jsonSchema in Python.
OP appears to be a polyglot with a foundation lower in the stack (e.g frameBuffer, X, etc) ... thus (as has been admitted) React et al are too abstracted from what is considered “familiar” web dev.
Vue gives you the binding, flow and components - whilst maintaining a closer relevance to what can be considered “familiar”... and subsequently a good introduction for someone who rejects web at first, yet introduces how a Text Editor can actually he built in a day using the principles shared by all modern web frameworks.
The browser is complicated, because its an abstraction that runs in almost every modern environment. Once WASM gets document bindings, writing web code will become language agnostics.
Also how are you going to bind interactions with the UI? I see a global event listener, but that would become unmanageable.
Sounds like QML, which even looks slightly like JSON if you squint at it right. Bonus (depending on your views) points: you can even use javascript in it.
Every QML application I've tried was comparable to Electron in my eyes so far: slow and full of little usability bugs.
This started to be really noticeable for me in the linux world, where QT is already common, but more and more UIs are converted to QML from QtWidgets.
The difference is staggering for me. QML GUIs are also often styled by the authors, which very often break or replace the system theme, something I hate.
I'll admit to completely ignoring the system theme, but that's absolutely standard practice among photo editing software like RawTherapee, darktable, and proprietary ones like Lightroom and Capture One.
As far as slow, no way. Instant startup, instant everything, no memory leaks. I've left my editor running for multiple weeks straight with no issues.
Usability bugs? Yes, there's basically one: scrolling. I've hacked together my own momentum scrolling system but I'm not happy with it. At least it's better than scrolling in KDE Plasma native applications, though.
RawTherapee has the option to use the system theme, and I'm quite grateful for that.
darktable on the other hand has basically one dark theme only which also shows stupid UI mistakes as black-overscroll-on-black-background in all lists and fixed font size. If there is ONE setting you have to keep, is the FONT SIZE in the system theme!
You're excluding many more issues from here. Click on a scollbar and drag outside: very often the scrollbar doesn't release when the mouse button is depressed, though styling and custom events play a role. QML is not immune to a lot of quirks in highdpi, most of which are completely absent in QtWidgets. In detail, font rendering (hinting) in QML in GL contextes is basically broken.
The whole UI is perceptibly laggier as a whole. I'm a programmer myself. As a programmer I feel ambivalent, but as an user, I hate it.
It seems like any consensus on ignoring/utilizing system themes is transient. I know I'm glad when they are mostly ignored on mac, while glad when they are utilized on linux.
I remember dabbling with Visual Basic 5.0 as a teenager. It was pure godsend and bliss compared to turbo basic (executables !). I never found glade, xul and other tech stack as easy to use and get into (flash mx 2004 was cool as well but not as much because the web).
do while .t.
@ 22, 1 clear to 22, 78
@ 22, 26 say 'Ready to Print ? <Y/N> ' get cPType pict '!' ;
valid ( cPType = 'Y' .or. cPType = 'N' .or. cPType= 'H')
read
if cPType = 'N'
exit
elseif cPType = 'H'
jAlert( ';Help on Print Formats - Press : ;;' + ;
' Y for normal bill without leaving no blank lines;' + ;
' N for aborting bill print ;' + ;
';' + ;
' L for Large bill covering an A4 size paper'
)
loop
endif
invoice_print( cPType )
exit
enddo
This piece of code executes linearly, there are no events to listen for and so no callbacks. There are only keyboard events that occur at specific times in the program's execution. No mouse events that'd have generated events that you'll need an asynchronous model of the program to deal with. And this screen is fixed size - 24 lines and 80 columns; it has 16 colors: red, green, blue, yellow, and the rest. The window doesn't resize nor the screen size ever change.
Modern GUI however has events and has to work on devices with all sorts of resolutions, and they support mouse and asynchronous execution. The program model is vastly more complex, and although the good old days were really really nice, they would probably never be back.
It's not a lot to look at and I'm deliberately working on it slowly, but if anyone finds my goals compelling and wants to jump in my email is in my profile:
It amuses me that, for all its "brokenness," OP lists 5 workable solutions and proposes 1 non-solution. The comments here propose at least one other workable solution (Dear ImGui) that's new to me and looks very nice!
I am more enthusiastic about the future of GUI development than ever before. ;-)
I mean, sure, if all you want is a couple UI elements and zero control over how they look or their layout, most existing GUI toolkits are incredibly over-complicated.
But you only want those basics for, like, a minute or two. Or to show a couple buttons and nothing else. Then you realize how incredibly restricting that is, and how impossible it is to make something nice and not just functional, and you discover the problem is bigger than you thought it was.
Shoes gets pretty close perhaps? http://shoesrb.com/ But even a tiny glance will show it's vastly more complicated than the proposed API here, because the proposed API is so inadequate you can't even say "put X near Y".
Python isn't first-class in any GUI framework IIRC (although Qt for Python may change this). JavaScript and C#, with regards to GUI, are single-platform languages (I've never seen a UI built with Node and no browser, and I don't see a good way to build a Linux GUI in C# that is actively maintained). That leaves Java, which I will concede, even though Java isn't first-class on any platform except Android.
Yeah, this is just simple naivete. I do agree with the author's premise that "GUI development is broken" but certainly not because I can't rip out a "text editor" in a couple hours. Things that seem simple tend to have the worst problems.
> What, I’ve just got to link to C libraries and write the bindings myself? This seems a bit ridiculous.
I think it's a good scenario: it seems that in most cases available libraries don't expose a C API at all.
I had thoughts similar to the article's conclusion, and even a prototype of a similar GUI (stdin/stdout, s-expressions), but then decided that a subset of HTML (or XUL, as mentioned in another comment, though not sure how reusable libxul is, and it seems pretty close to a full web browser with its scripts and events) would be fine, though didn't get to trying it out. Currently GTK seems usable to me, even if imperfect.
Now you know what I mean when I said Tcl/Tk was "the fastest" way to get a GUI up. Especially when you consider that wish also functions as a REPL at which you can test your ideas right away with no compile step.
Imagine how good Tcl/Tk would be now if people had put as much effort into improving it as they did in trying to kill it and come up with alternatives.
> By far the most widely used graphics toolkit in history is HTML and CSS. ... And it’s definitely the easiest option. It’s the first thing I learned as a programmer
And this is where we are. A huge number of today developers, maybe even majority, are so accustomed to web programming that it's the first thing that comes to their minds.
Because there aren't any alternatives that are as easy to use and understand. QML could be if it was available for any language other than C++. Ditto with Lazarus and Pascal. I hear XAML WPF isn't bad, but it strikes me as having the same limitations Adobe Flex had (performance). People here love to suggest GTK, but I've never used a GTK app that didn't look like a Java swing app straight out of the 90s.
Nuklear looks promising if you don't care about "native look and feel". In this age of "web swallowing the world", I don't think I care about native look and feel. Then again, maybe the native look and feel on windows and linux just sucks. All of the gorgeous, yet still fast apps are for the Mac and iOS ecosystems and it isn't because their tooling or native GUI APIs are so much better than everybody else's.
I love when people try to reinvent stuff like html, but with JSON! Like html somehow would be better with JSON? If he didn't want to use GTK, nor HTML, then he could have just gone with Qt Quick. Qt Quick offers a declarative GUI, it even looks almost like JSON. What a waste of an article.
If you remove the OCaml requirement, everything described can be done with Lazarus [1] which even comes with a very powerful code editing control/widget. In fact i made a simple IDE [2] for my LIL scripting language [3] using Lazarus in a couple of days (which also supported remote execution for LIL code so i can run and update code while my game engine is running, inspired by an article about how Naughty Dog used Lisp for Jax and Daxter - except i use LIL, which is closer to Tcl, instead of Lisp).
Lazarus doesn't have a simple small framework, if anything it is much bigger than Gtk, but it is very simple to start with and you can ignore most of it. If you want to see how it is to use it, recently i recorded a video making a simple game with it under Linux [4] (there are a few comments in a text editor in the first 6-7 minutes but after that i do not have any sort of comments). If you want something with more GUI controls (the game really uses just a painting control), i also have an older video making a tilemap editor [5].
Now to make a disclaimer: IMO both Lazarus and Free Pascal (the language used by Lazarus) are a bit messy and i'm not presenting them as examples of the perfect development environment. However Lazarus is both very powerful and very simple to use, to the point that i consider it by far the best and easiest way to create GUI desktop applications (the only closest alternative is old versions of Delphi before it became a bloated mess - but even if the new versions weren't bloated, i'd still not recommend them because of their ridiculous price, the fact that VCL only supports Windows and above all the DRM they have - i remember reading complaints from users that they had to use cracks so that they can use their highly expensive software in their own laptop, which is absurd IMO). It has warts but they are well worth it.
My biggest issue with Lazarus is that it seems that the Gtk3 backend is going to become the default one on Linux in the future and as a user i dislike everything about Gtk3 (and Qt5 but to a lesser extent).
