1. 56

  2. 20

    The author doesn’t mention the popular GUI library that’s the best fit for his use case – TK. (I can’t blame him – TK has poor PR, since it’s marginally less consistent than larger and more unweildy toolkits like GTK and QT, while having many of the drawbacks of a plain X implementation.)

    That said, the fact that TK is the easiest way to go from zero to a simple GUI is frankly pretty embarassing. There’s no technical reason GUI toolkits can’t be structured better – only social reasons (like “nobody who knows how to do it cares enough”).

    1. 13

      The problem is that TK still has terrible looking widgets. Just because UI fashion has moved away from consistent native look and feel doesn’t mean TK is passable.

      1. 12

        TTK mostly takes care of this, by creating a Look and Feel that matches up with the platform in question.

        1. 3

          TK ships with TTK, which provides native widget styles for every major platform. It has shipped that way for nine years.

          1. 1

            I was not aware of TTK, thank you! I tried out TK a few times and seeing how awful it looked made me leave it really quickly for other technologies.

            1. 4

              TTK has been around for a long time, and built into TK for a long time too. It’s a mystery to me why they don’t enable it by default. I discovered it six years after it got bundled!

              1. 1

                I tried to look into it a little bit today but it looks like there is pretty much only one getting started guide for it, written in python. Do you know any guides for it in other languages?

                1. 2

                  Not really. It provides native-styled clones of existing widgets, so if it’s wrapped by your target language, all you should need to do is import it and either overwrite the definitions of your base widget-set or reference the ttk version instead (ex., by running ‘s/tk./ttk./g’ on your codebase).

        2. 5

          When he put out the JSON protocol, Tcl/Tk came right to mind. This is exactly how people do UI with Python and tkinter.

          1. 3

            Interesting — I have almost no experience with TK. I will look into it, thanks!

            1. 3

              TK is used by Mozart/Oz for the GUI, with a higher level library QTk on top of it. It works well and is easy to program with.

          2. 26

            I think there’s a lack of requirements here. Framebuffer is rejected because alt-tab doesn’t work, then X11 is rejected because fonts are hard, but how were you planning to draw fonts on the framebuffer? The requirements seem to evolve with every option, but that’s a poor way to make a decision. You waste time evaluating clear non fits, and frequently up with decision paralysis by failing to establish any sort of order or scoring metric.

            1. 5

              True, fonts on a framebuffer wouldn’t work either. I think people who didn’t know that was an option might enjoy hearing about it.

              1. 4

                If you understand little about the domain, it might be hard to formulate a specific concrete list of requirements. You might retort that one should spend more time learning the domain, but one reasonable approach to that is to go out and try something. Thus, requirements can naturally evolve as you learn more.

                1. 7

                  OK, but then I think we should at least clarify what our evolved requirements are. Terminal apps are rejected because st is 2000 lines of code and that’s too much, but I’m to believe graphical json python will be less than that? If we have evolved past that requirement, shouldn’t we revisit early options?

              2. 11

                Have you seen Shoes - http://shoesrb.com/ or Toga? https://pybee.org/project/projects/libraries/toga/

                What’s sad is that you see these fits and starts, but very few of them actually make it to maturity.

                I blame the web. Desktop GUis are so 5 minutes ago, do it in ReactTypeAspectVueBackboneScript! It’ll be GREAT!

                1. 2

                  I love shoes! Haven’t used in a few years but yeah I remember it being only half usable.

                  1. 2

                    Yeah. Why’s brilliance lead him to buck every convention. The upside is that maintaining his code could be… A challenge :)

                    There are some incredible ideas in there though.

                2. 10

                  This is true in any language, unfortunately. Choice quote that resonates with anybody who’s worked with GTK: “if you just want a few buttons and some text, using GTK is like mowing a lawn with a helicopter.” (GTK is usable at all thanks entirely to glade.)

                  1. 13

                    Absolutely doesn’t resonate with me. Came here to complain about this quote actually.

                    I don’t understand this reasoning. Having one toolkit that scales from a few buttons to GIMP/Inkscape is the point of any reasonable toolkit. And it’s not like GTK always requires a complicated setup or whatever. Creating a window is really simple. Adding a button looks like, well, adding a button.

                    By the way, the problem with OCaml is that no one made a working gobject-introspection library, and it’s stuck with GTK2 :(

                    1. 2

                      I get some stuff - some simple use cases are fine, but other ones are complex - for example, if you want a simple list or tree view, you have to essentially implement a bunch of MVC boilerplate to do so.

                    2. 5

                      Unlike GTK (at least I think) some GUI are built as a separate rendering program that communicate through a stream, so it is possible to change that program for another. But does it solve the problem?

                      The web grew way too complex to permit a trivial implementation.

                      Ncurses somehow feels bloated too. Though it can be bypassed: ANSI escape sequences seems to be supported by most (if not all) emulators.


                      1. 2

                        The only exception I can think of is with Racket; writing cross-platform code that uses GTK is quite pleasant with that tool set. https://gitlab.com/technomancy/world-color/blob/master/world-color.rkt

                      2. 10

                        “A procedural drawing language that you send commands to and it draws things on the screen.”

                        Sounds like Display PostScript, or even better, NeWS.

                        Honestly, though, what the author wants is a lightweight SVG runtime with some extra input bits.

                        1. 8

                          Imagine, if you will, a procedural json interface to the screen.

                          I think this solution conflates the API problem with the (C)FFI problem. You could wrap the X11 protocol but the same example wouldn’t be obvious at all.

                          A lot of the problems stated about baked in assumption (like X11’s bitmap fonts or terminals communicating using escape characters) would remain even with the improved JSON FFI.

                          (Also, anything client-server like that probably needs to be asynchronous and the simplest example may not be as nice.)

                          That said, I fully agree with the problems identified and also wish for more language agnostic tools, whether it solves the original problem or not (anyone remembers D-Bus?). I’ve hit every one of those problems at one point or another.

                          Now for the API problem, I think we could have much better but the subproblems are not as easy, especially for what the author wants to do (make a graphical text editor). (Modern) GUI has a lot of meaning packed into it (try describing windows, buttons, scrollbars and text fields in terms of lines, polygons and keyboard and mouse events) and everyone wants to do something that is just slightly different enough to make making a toolkit for you particular purpose easy but making a toolkit for everyone’s use hard.

                          X11’s choice of bitmap font is a good example of this (where such a choice seems very reasonable, especially at a time).

                          We might be better off improving GUI toolkit reconstruction speed (see my GUI toolkit toolkit).

                          1. 2

                            We might be better off improving GUI toolkit reconstruction speed (see my GUI toolkit toolkit).

                            I read your submission recently, I did not connect what you were doing toward this problem until this quote. A noble effort, indeed!

                            1. 2

                              Thank you! This is encouraging. It also makes me think I should write something explaining guitktk with this perspective since the connection may not be obvious at all.

                              Also potentially relevant to this discussion is uielem which is a more declarative wrapper for Tk (that look more like S-expressions and maybe better suited for OCaml). Its small and the idea should be simple enough to port. I use this thing pretty much everywhere.

                            2. 1

                              Yeah I hope that a solution like that would target both problems: creating a better api, and then exposing it through json.

                              Yeah I think you state the complexity of designing a gui api really well — hope it can be done well anyways! I think one key thing is offering various levels of abstraction all together - lines and triangles along with buttons and scrollbars.

                            3. 6

                              For my general take on this problem, and noted bias, see: https://www.quora.com/Why-is-using-a-GUI-in-most-of-all-programming-languages-such-a-hassle-given-that-Rebol-and-Red-have-such-elegant-solutions/answer/Gregg-Irwin

                              While the headline is attention grabbing, the article itself poorly frames the problem, based on vague and perhaps unrealistic expectations, and a non-solution with imagined advantages. Maybe I’m just in a bad mood, or maybe it was “I don’t care about the particulars.” that particularly set me off.

                              1. 5

                                I think some requirements are missing here - mainly which/how many GUI platforms you intend to support, which changes things a lot. I’ve done a decent amount of GUI development on Windows, and have a decent understanding of the options there - you have:

                                • Win32 - Super-basic and low-level, designed for C, probably has bindings in most languages, even the rare and weird ones
                                • .NET - Can use any .NET language, has the WinForms (wrapper over Win32) and WPF (tons of funky new stuff with lots of XAML)
                                • UWP - Not honestly sure, think it supports C, .NET, and Javascript. Sounds like it has enough binding to support most things, but is probably new/immature enough to not have good libraries for more oddball languages

                                Of course, MacOS and Linux have completely different APIs/libs for native GUI development, which is why so many developers reach for Electron or Swing or something. And kind of confirms the OP’s point.

                                1. 4

                                  Designers are moving away from “native look and feel”, which is an exciting trend because each application can have a (carefully thought out, but) unique rendering method. Java Swing was a no-go in 200x because it didn’t feel like windows, but writing a mini-toolkit in your language of choice makes a lot more sense in 2018+ because the platform no longer matters (the 4+ target platforms look nothing alike anyway!). Google is doing this with Dart, but it could be done in Ocaml, etc.

                                  1. 4

                                    The author could check Red language, it has a GUI toolkit quite similar to that in its feel.

                                    1. 4

                                      Why do you want a specifically procedural language, particularly as an OCaml user? Why specifically JSON?

                                      If you’re willing to relax those requirements then e.g. Qt with QML sounds like exactly what you’re asking for: a proper first-class GUI widget library, but with a simple, high-level, language-agnostic interface available for the simple cases, and good integration between the high-level interface and custom widgets when you need that.

                                      1. 3

                                        There are even actively maintained OCaml QML bindings, lablqml.

                                      2. 6

                                        I think he’s over generalizing his experience with Ocaml.

                                        Common Lisp, for example, has a number of GUI options of varying complexity and quality. The best, IMO, is QTools, which makes developing Qt apps in CL easier than using PyQT, and much easier than doing it C++. I think it can even use the layouts created with Qt’s drag-and-drop interface designer. I’d guess he could make his simple text editor app in something like 30 lines of code.

                                        There’s also others, like McClim and LTK which aren’t as good (IMO), but are easier to learn without knowing Qt and C++.

                                        1. 3

                                          I agree that how we write GUIs could be improved. An alternative approach to writing GUI is CLIM. The gist of the CLIM is that interactions with application are structured around a command loop. They are recorded in an output record (which is a/like a stream). Some similarities with redux can be drawn. This article gives a short overview of how is CLIM is different: http://random-state.net/files/how-is-clim-different.html

                                          1. 3

                                            I know this post is *nix-centric, but FWIW, WPF and XAML are not horrible tools for building UIs.

                                            1. 4

                                              … I just spent a minute searching the web for a GUI toolkit named “FWIW”… For what it is worth, I now presume that there is not one.

                                              1. 1

                                                Haha, sorry for inadvertently sending you on that wild goose chase :|

                                            2. 4

                                              GUI development is broken, but JSON isn’t the solution: it’s another broken thing, just broken along a different axis.

                                              An S-expression–based interface would be better, because then there’d be a seamless way to embed behaviour along with the GUI …

                                              1. 4

                                                Web GUI technology has completely surpassed the desktop GUI technology.

                                                Back in the day web stuff was so basic that a desktop GUI was nicer and an upgrade, now that has reversed.

                                                1. 10

                                                  I agree to some extent, except that Electron apps (and some web apps) are all but unusable on low-end/older hardware. Many (but not all) are severely lacking in keyboard control and other things that one might expect, too. Every Electron app seems to be oblivious to multilingual users and underlines every word, despite me switching input methods.

                                                  1. 2

                                                    I’d like a HTML-based GUI that doesn’t embed a full renderer like Electron does – something that maps HTML onto native controls (including accessibility stuff) could be really neat.

                                                    1. 1

                                                      Isn’t that what React Native is? Maybe that’ll be the hot new thing instead of Electron; would prolly be an upgrade.

                                                      Edit: whoops, it’s iOS and Android only.

                                                      1. 1

                                                        React Native is just running your app as JS and communicating to a native set of widgets and layout, which need to be implemented per platform. If desktop support were something FB had as a priority it’d be a good option for a lot of people, but… it’s not.

                                                  2. 9

                                                    Couldn’t disagree more, and the reason is accessibility. it’s super trivial for desktop app developers to add keyboard shortcuts and other accessibility aids to their apps. Web developers, despite the fact that these standards like ARIA exist, seem unwilling to adopt them in any sizable number.

                                                    We can have this conversation again when the Hello World app produced by your average Java framework is Aria accessible, has keyboard shortcuts for everything, and works properly with screen readers.

                                                    1. 4

                                                      If the developer doesn’t care it doesn’t matter if it’s a desktop app or a web app. They wont do it either way.

                                                      The difficulty of adding keyboard shortcuts or adding accessibility tags is not dramatically different and quite easy for web apps too.

                                                    2. 3

                                                      As bad as GUI toolkits are, web tech is a lot more awkward to make GUIs with than any major cross-platform toolkit, simply because it’s a hack to draw anything with the DOM. (You’re literally live-editing the AST of a rich text document. It’s amazing that it works at all.)

                                                      1. 1

                                                        Your sole argument about DOM being a hack and akward is it being live-editing an AST? If anything, this might be a pro of the DOM API… I don’t see how a technology widely used, having API clearly defined for those use cases and supported by modern and old browsers can be called a hack and akwards. Meanwhile you have your average GUI toolkit that still ask you to design your AST in the code, put the styling right beside the event handling and often introduce first how to put a button a X,Y because using container and layout is akward and complicated.

                                                        1. 1

                                                          A regular GUI toolkit doesn’t involve manipulating the AST of a markup language. It involves manipulating containers that map conceptually to layout, using already-implemented widgets. There’s an event handling system designed to efficiently handle widget-specific mappings, focus changes, and other common situations, as well as having sane defaults (versus having an event system that needed to be tacked on ten years after the other features were written).

                                                          The act of spawning a widget in a web app is an ugly hack, simply because document markup structurally conflicts with GUI layout in ways that the web developer must bodge.

                                                          If any GUI toolkit requires you to jump through hoops to draw a dot on the screen, it’s broken. (By this standard, most popular GUI toolkits are also broken, but HTML is the most broken of all.)

                                                          1. 1

                                                            Yeah, regular GUI toolkit doesn’t involve AST and markup language, such as HTML, XAML, Android, QML, etc. In my opinion, working on a human readable and understandable AST might be the key of the web plateform GUI? Drawing anything is as simple as adding a node or subtree to my current tree. It’s as simple to do by hand than programmaticaly. If anything go wrong I have well made developpers tool to see and live edit this tree. Call it a hack all you want, I call it a successful low-level reprensentation to share the GUI state to the renderer, much better and powerfull than what you can do with Tcl or xlib (Although, much more heavy).

                                                            If any GUI toolkit requires you to jump through hoops to draw a dot on the screen, it’s broken. (By this standard, most popular GUI toolkits are also broken, but HTML is the most broken of all.)

                                                            There you go: <html><head></head><body>.</body></html>. By this test we can now assert that HTML is not broken (Or at least just as much as the others).

                                                            1. 2

                                                              You haven’t drawn a dot. You’ve typeset a period, and spent 40 characters doing it. And, typesetting text is what HTML is for, so it’s what it’s best at. If you actually want to ensure the period resembles a dot, set its x,y position, and set its color, you’ll need hundreds more characters.

                                                              In BASIC, you can just do pset(x, y, color)

                                                              In TK: canvas .c ; .c create point x y color ; pack .c

                                                              An AST only makes sense if you are actually parsing or generating a structured language. The structure of an HTML document doesn’t coincide with the structure of a PARC GUI (i.e., every major GUI app since 1977), and is an even worse match for the scope of all possible useful GUIs (most of which resemble neither paper nor forms). The reason is that HTML was only ever intended to display minimally-formatted rich text.

                                                              “Drawing something” is usually easier than manipulating the DOM. “Drawing something” is only trivial on the DOM when what you’re drawing is structured like a text document.

                                                    3. 2

                                                      I’m afraid that a good UI library/framework is simply a complicated matter, and this post reads a lot like “GUI frameworks are hard! I know, I’ll write a new JSON-based protocol to do GUI. JSON is easy!”.

                                                      However, once you start doing more than drawing text and simple lines and want buttons and events and windows, your JSON-based protocol will quickly degenerate into the kind of complicated mess you were trying to escape from.

                                                      1. 1

                                                        Isn’t the conclusion basically Immediate Mode GUI?

                                                        1. 1

                                                          You may want change

                                                          • \[033\[3;9H] into \033[3;9H and

                                                          • /x1b[31m into \033[31m.

                                                          \033 (octal 33) is the same as \x1b (hexadecimal 1b).

                                                          1. 1

                                                            I’ve had a lot of fun with Haskell’s brick library, which makes terminal user interface development nice and easy.