4 ms·

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 t

by eco 4y ago

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.

antihero 4y ago
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.
- zarzavat 4y ago
  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.
  - rob74 4y ago
    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".
  - exDM69 4y ago
    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.
    - zozbot234 4y ago
      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.
      - dataflow 4y ago
        > 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.)
      - Wuzado 4y ago
- friendzis 4y ago
  Qt has solved this problem in a pretty neat way
bruce343434 4y ago
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
- alkonaut 4y ago
  Any combo box with custom draw functionality will provide that.
chrismanning 4y ago
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 https://crates.io/crates/qmetaobject
b20000 4y ago
TLDR use a robust c++ toolkit like QT and spend more time on what matters.

by eco 4y ago

antihero 4y ago

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.

zarzavat 4y ago
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.
- rob74 4y ago
  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".
- exDM69 4y ago
  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.
  - zozbot234 4y ago
    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.
    - dataflow 4y ago
      > 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.)
    - Wuzado 4y ago
friendzis 4y ago
Qt has solved this problem in a pretty neat way

bruce343434 4y ago

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

alkonaut 4y ago
Any combo box with custom draw functionality will provide that.

chrismanning 4y ago

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 https://crates.io/crates/qmetaobject

b20000 4y ago

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