Ask HN: I'd like to practice coding GUI from scratch. Any recommendations?

But seriously from scratch in this case is a canvas plus possibly some primitives for marking the canvas. Cairo provides these things.

I used to have an old 2MB DOS notebook that I would fire up now and then to play with my ideas in this space. I could get mouse input through an INT op code of some sort, and there was the keyboard and getting access to video RAM.

I have tried to play with the Linux kernel drivers underlying things like wayland and X but I lack the determination to see that through.

Another post here someone listed the object model paradigms and that’s probably closer to what OP is interested in.

    QObject::connect(&button, &QPushButton::clicked,
                     &mainWindowController, &MainWindowController::onButtonClicked);

Something that's special with Qt is that signals and slots are declared in the class using custom syntax, e.g.

    slots:
        void onValueChanged(int value);
    signals:
        void valueChanged(int newValue);

Qt makes use of a tool called MOC – the Meta Object Compiler – to generate code for signals and slots. It's not a pre-processor but a code generator, which has to run before you can actually compile the code. I think you could probably implement a similar system of event subscriptions without this additional code generation step.

See this page for details: https://woboq.com/blog/how-qt-signals-slots-work.html

- Data update are the best part -- there's no synchronization needed with an IMGUI approach because the "model" and "view" are the same thing.

- adjust the event loop so it only redraws on changes (e.g. mousemovement) rather than every frame (unless you're drawing every frame anyways for a game)

- IMGUIs can have trouble with very large lists -- imagine you have a tree view with 20k objects, you're going to process each one of them each time through the gui, even though most of them are outside the visible list. But it's hard to only draw the "visible" ones since you don't know the future (e.g. imagine iterating a list where some items are hidden). Usually this isn't a big deal to work around, just keep it in mind.

- Biggest problem i've run into with IMGUI style is layout. Since you are processing widgets as you go, you can't adjust to future things. For simple layouts like stacked property sheets this is fine, but once you get beyond that it can be complicated. I'm playing with some ideas now where I use a constraint based layout to come up with "reference boxes" up front that then the IMGUI can use to layout but it's still a pretty open problem.

Installing a screen reader like NVDA and observing how it interacts with the screen might be interesting to learn about the scope/depth of the accessibility APIs in general. (And then there's observing how screen readers handle different websites...)

Imgui and similar generally have zero accessibility support whatsoever, although it's certainly not impossible to add - just a bunch of messages back and forth to the accessibility layers in the OS - but the support would wind up being a module, and a bolted-on one at that that would have very little uptake because everyone who didn't need it (for themselves) would just compile it out. Whereas with Qt and Electron it's kind of like rabbithoooooookaybackawayfromtheinternals and everyone just leaves all the bits in :P and the support just comes along for free. (An interesting study in the tradeoffs between minimalism, modularity, and the commoditization of support of niche use cases...)

Also, regarding practice of UI architecture and optimization, I actually sometimes think about the idea of drive-by contributing to open source projects - they have pre-existing contexts and conventions that must be adjusted to (an important skill that is tricky to develop alone), and it's possible to approach them with an objective impartiality that is sometimes tricky to square with emotional investment in personal projects. This may be one approach to independently evolving mechanical abilities (structure, domain-specific mental modeling and problem-solving, best practices) separately from fundamental personal development, which may (seems to?) go a little slower.

True. But there are several entirely adequate cross-platform toolkits. Pick a toolkit, not a platform.

(GTK+ (via gtkmm) user for 23 years, on 3+ platforms)

Most applications just pick Windows win32 API or MacOSX and forgets about everything else and are never released for Linux or other Unices, unless the application uses electron, Qt with C++, Qt with Python or Java SWING like JetBrains IDEA IDE family. The main problem of Linux desktop is the lack of a high level graphics library toolkit with a stable API, ABI and a C interface that does not introduce breaking changes on every release. Unlike Gtk, Qt is more stable, but it lacks a C API and C++ has a fragile ABI not friendly to foreign-function interface or cross-language linking.

I personally have learned the most from Cocoa, but systems like React and Dear ImGui have definitely shown me new ways to think recently.

In terms of contrasting what's strong vs weak, look at how Cocoa changed from AppKit to UIKit. They kept a lot of the same ideas: such as runloops, target/action, view hierarchy, and the responder chain, but did away with some things that were redundant (NSCell) or poorly suited to producing fluid UIs (timer based animations). Put another way, they improved composability (everything is a view as opposed to some things being views, others cells, and others still windows), and they introduced a new low level system in CoreAnimation that provided compositing and animation and made it a fundamental building block.

---

An unpopular opinion I hold is that a good API design is more important than source code. Like, pick any method on UIView: strong Cocoa programmers could write a workable implementation given just the method signature and the documentation if they had to. The design of the API and how it all fits together is the real magic. Once you get that, the implementation follows. ... on the other hand, Microsoft actually tried to do that once, and their implementation was bad: https://github.com/microsoft/WinObjC/tree/develop/Frameworks...

Best shade thrown on HN all week! Bravo.

Rust for instance has no overhead of garbage collection, while Erlang does garbage collection at the end of every function.