Comment by eco | Hacker News Reader

Comment by eco | Hacker News Reader

Great article. Answered a lot of questions I've had as I toy with the idea of making part of a C++ project in Rust.

Regarding Slint and all the other new GUI toolkits, one thing I don't understand is why they all seem to completely ignore any controls more complicated than the basics (buttons, checkboxes, drop downs, spin controls, sliders, radio buttons, and a basic list control).

A To-Do app is a proof of concept, not an endgame.

Beyond those basics I need combo boxes, date time pickers, color pickers, font pickers (fonts are hard, I get it, but my users expect access to system fonts), dockable windows, splits, tabs, modal dialogs, tooltips, masked text input, auto completion text input, context menus, calendar controls, file and directory pickers.

Some of the new toolkits offer an assortment of these, including Slint but they rarely get all of them but the biggest thing missing from pretty much all of them are sophisticated data grids (both list and tree varieties). They need support for custom cell rendering, custom cell edit controls, and variable row heights. They also need to be fast even with tens of thousands of rows.

Oh, and think about your printing story. You don't print a UI obviously but if I'm rendering diagrams and stuff using your rendering facilities I at least need a way to hook them up to the platform's system without just duplicating all of the drawing to a completely different rendering API to make printing work.

This isn't a dig on Slint. I'm eagerly watching it, along with egui, as I desperately look for a cross platform alternative to all the legacy stuff I'm neck deep in. I just can't consider anything that has no good support for data dense applications.

It may be worth looking at qmetaobject[0] which lets you use Qt/QML from Rust. Whatever you can do in QML you can do with qmetaobject, and writing new Qt stuff can be done with some annotated Rust code. I'm using it in a personal project and quite enjoying it, the lack of C++ tooling is a joy not to be understated. I believe it's from the same author as Slint.

[0]: https://crates.io/crates/qmetaobject

I think one of the issues with going beyond the basics is that once you start to tackle more advanced controls you not only have to be more opinionated, as there’s many ways to achieve these things, but also they become for more specific use cases and thus creating a general solution has exponential complexity.

What people want from a UI library is to be able to use system components. For example, there should be a way to open the system color picker, to display a system data grid, system date picker, etc. It doesn’t need to be more than that.

There are definitely people who want more than that. Some controls I am always looking for in a UI library before I even think about using it is a more advanced list control (or table view) which supports columns, sorting etc., and a "tree view". Of course, as the GP wrote, it's hard to implement these without getting more opinionated. Plus, I might add, it's also hard to do these while staying "mobile-friendly".

These blessed "system components" do not exist any more. Windows has two or three different ways of doing widgets and so does MacOS while the Unix land never had one.

You can still use the old ones, but they will look old and may not behave like you would expect (hidpi displays, touch screen, etc).

wxWidgets and its bindings to many languages exists if that is what you want.

Writing an uniform interface to GUI widgets on many platforms is very much a non-trivial undertaking, there are plenty of failed attempts over the years.

The look & feel of system components on Windows has actively regressed starting from Win 8 and subsequent releases. No idea about the situation on Mac OS. But AIUI, both Qt and GTK+ will give you a good enough UI in practice. Perhaps someone will even split out the SerenityOS widgets (which are truly best-in-class, meshing the advantages of "classic" and "modern" UX) as a multi-platform framework, much like has been done wrt. the browser engine.

> AIUI, both Qt and GTK+ will give you a good enough UI in practice

Not GTK+, it sticks out like a sore thumb. Qt gets much closer, though in both cases you can tell something feels off.

(e.g., click an active tab in a tab control in Qt and you won't see the dotted selection line like you would in Win32. That normally indicates you can switch between tabs on the keyboard.)

SerenityOS is such an amazing project. "Oh, this thing would take a large team several years to build? Let's build it anyway!" The backstory behind the project is extremely admirable, too.

> Perhaps someone will even split out the SerenityOS widgets as a multi-platform framework

That would look out of place on MacOS or Windows. Serenity has a Win 2000 look.

MacOS still has standard components at least. For Windows you can pick the best of several options and stick with that.

For what it's worth, wxWidgets does have hidpi support (at least on Windows).

Don't forget about Microsoft COM components. That technology was specifically created as a system to produce "reusable components" with. What happened to that?

Qt has solved this problem in a pretty neat way

If you have combo boxes then you already have a font picker. Do you mean you want a built in way to enumerate installed fonts?

edit: I realized that you want the menu entries to be rendered in the fonts themselves

Any combo box with custom draw functionality will provide that.

TLDR use a robust c++ toolkit like QT and spend more time on what matters.

Reply on news.ycombinator.com