6 ms·

Sorry if off-topic but I've seen many attempts at Qt bindings from Go and Rust. It seems all GUI libraries are more than 15 years old - except flutter, which is

Sorry if off-topic but I've seen many attempts at Qt bindings from Go and Rust. It seems all GUI libraries are more than 15 years old - except flutter, which is currently alpha quality on desktop. As someone who has never implemented a native GUI library, what makes them so difficult to implement that we see so almost no language-native ones? Is it a matter of it not being monetizable, or something else?

ahartmetz 5y ago
There is a lot of stuff there. When I think of Qt, and omitting things like QString and QIODevice / QNetwork: Text rendering, list / grid / tree views, painting primitives and not-so-primitives (e.g. dashed lines), input including multitouch, custom styling, accessibility, many miscellaneous widgets, timers and events, integration with native environment, printing - and a ton of customization points for everything.
wuschelhase 5y ago
It is an enormous effort (read investment) to get to a point of detail, where such a library becomes usable to a wide audience. Consider a simple text input: In some languages (e.g. 'syllable based' korean Hangul) you have to compose multiple keystrokes to get to a complex letter. While you type, the last and as well as the second-to-last complex-characters might still 'trade' consonants and vowels among each other. Now layer in more Dimensions, such as validating that input or line-wrapping, elision and many more. To my mind, only few libraries got to this level of detail without breaking apart on complexity. It requires high maintainer stamina or massive investments.
- sho_hn 5y ago
  Most of your input example is nowadays typically handled by code outside the GUI toolkits themselves (such as the IME, the text shaping and the font stack), although the general "the GUI devil is in the details" thrust is right.
deleted 5y ago
[deleted]
jcelerier 5y ago
Qt5's qtbase module is over 2 million LOC, and doesn't even cover QML, QtQuick, etc. Just having proper abstractions over each platform[1]'s: - windowing - KB/mouse/tablet/touch input - raster painting - 3D APIs (Vk, D3D, GL, Metal...) - text layout and rendering - support for accessibility APIs + things such as generic data models for tables and trees, etc... is already an immense amount of work, and you haven't even started drawing a single button yet. * https://github.com/qt/qtbase/tree/dev/src/plugins/platforms https://github.com/qt/qtbase/tree/dev/src/plugins/platforms
- badsectoracula 5y ago
  You do not need to replicate all features of Qt to make a GUI toolkit, especially since Qt tends to have a ton of stuff outside GUIs and actually has two "widgets" approaches (classic widgets and QML). For example the 3D API stuff are pointless beyond context creation, unless you use only that 3D API (instead of underlying window system functionality) to put stuff on screen. Qt also recreates a ton of features found in C++ and if we're considering a new language, chances are the language itself has features that make Qt's unnecessary.
  - jcelerier 5y ago
    Which features are you talking about ? Even in c++23 there isn't yet a way to replicate moc, rcc, uic with the same ergonomy for the end user and the same efficiency.
    - badsectoracula 5y ago
      I mean things like containers though in the context of a new language chances are the language itself may provide functionality that makes moc unnecessary. Also you certainly do not need something like moc to make a GUI library, which comes back to what i originally wrote in that you do not need to replicate Qt to have a GUI library.
      - ogoffart 5y ago
IshKebab 5y ago
They're just really enormous libraries with a ton of tiny details you have to get right. Same reason there are so few good FOSS CAD programs or word processors. Tons of work.
jonathanstrange 5y ago
The hardest is to make multiline text input and rich text support. None of the smaller, home-brown GUIs gets this right. You basically have to write a complete editor that supports all languages, including Japanese, Chinese, Arabic, etc. Even native operating system text input widgets have been plagued with problems. Generally, there are tons of edge cases and special input considerations to consider in a GUI, e.g. DPI scaling, accessibility, right-to-left languages and unusual unicode glyph handling (composed glyphs), scrolling behavior & mouse handling, platform-dependent layout issues (HI guidelines), escape characters in file paths and unusual file systems, and so on and so forth. It's quite possible to make a good GUI, just lots of mundane small issues to deal with, and it's overall a massive undertaking. It requires at least an extremely good knowledge of how different languages deal with text and input it.
- sharikous 5y ago
  Can't you just link HarfBuzz for that?
  - jcelerier 5y ago
    Harfbuzz partly comes from Qt's codebase IIRC
  - mwcampbell 5y ago
    harfbuzz is for text rendering, not editing. Of course, the former is a prerequisite for the latter, but text editing has plenty of its own complexity.
beowulfey 5y ago
Rust has a number of burgeoning GUI libraries. Some of them are further developed than others. I think the difficulty is just the complexity of the work. It takes a lot of effort to make a complete, functional library, and many of these are largely the work of one to a few people (probably in their spare time)! https://www.areweguiyet.com/ https://www.areweguiyet.com/ The secret, I suspect, is probably "money".
badsectoracula 5y ago
Beyond the "this is too hard" responses (which from personal experience working on GUIs and toolkits for decades i think are overblown), it is also that a GUI toolkit -or any other library really- written in a niche language will only be usable for that niche language's audience but a GUI toolkit -or any other library- written in a language that can be used by other languages with almost zero friction, is way more likely to be used. And people tend to use what they see other people using, thus repeating the cycle. So you see these 15 year old libraries being used because other people are using these 15 year old libraries because they are written in languages that can be (relatively) easily be wrapped (both C and C++ wrapping can be done automatically and there are many tools for that - largely because this is something a ton of people want to do, so again, it feeds back to the cycle of things being popular because they are popular). But there are lots of new toolkits being made, you can even find a submission for a new one in Hacker News almost every month (though the responses are pretty much the same in all of them :-P).
- mwcampbell 5y ago
  > from personal experience working on GUIs and toolkits for decades i think are overblown) Accessibility and internationalization are really hard though, right? I'm finally doing something about the accessibility issue: https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit Still have a long way to go though.
  - badsectoracula 5y ago
    They can be among the harder parts of a toolkit (though it also depends on the toolkit's scope - can't really compare something like Qt that has a very large scope going even outside GUIs with something like imgui, which only provides the most barebones GUI functionality) yes, but i think the "hardness" exists not in how hard they are to have that functionality but in most people not even thinking about these things.
- nu11ptr 5y ago
  Assuming you are talking about Qt/wxWidgets, and I don't think they are easy to create bindings for due to being written in C++. I think they have been used because they represent the largest, most complete crossplatform codebases representing the traditional desktop GUI using either native widgets, or in Qt's case "simulated" native looking widgets. In contrast, GTK is written in C AFAIK, and anytime a new language springs up the very first thing you generally see is a GTK wrapper. I have always suspected this is because C is far easier to wrap since most languages have a well defined C FFI, but typically lack a C++ one (due to lack of std ABI) thus Qt/wxWidgets bindings typically lag GTK.
fulafel 5y ago
There's a lot of requirements creep, the bar is high, since the estabilished stacks have had decades to build up their feature sets. Complexity multipliers include accessibility, cross-platform, gpu acceleration, complexities of text in the modern world (unicode, fancy rendering like subpixel aa, fonts, bidi...), programming language bindings, memory/lifetime management in presence of different mutually incompatible PL memory management models, native code hostile mobile platforms, etc. Leave any of those out and you start halving your potential users for each feature. (For more specialised, niche gui toolkits the answer is that they're out there, but you've never heard of them because they don't enjoy the network effects that a wider user base gets the big toolkits)
api 5y ago
A high quality desktop GUI library is close to a game engine in terms of difficulty. You have to support a vast array of languages, accessibility, input paradigms, flexible layout, different screen resolutions and DPIs, styling, and so on. It's a massive undertaking.
- badsectoracula 5y ago
  Considering that some game engines tend to have their own GUI toolkits (e.g. UE4's Slate for example), you can say that it is more difficult to make a game engine than a GUI toolkit :-P.
  - sho_hn 5y ago
    I'd say making a comprehensive 2D GUI toolkit is actually more complex and difficult than making a 3D game engine - even one that includes a rudimentary 2D GUI toolkit. There's an enormous long tail to 2D. My current work is exactly at the place where those tech universes overlap and integrate.
    - mwcampbell 5y ago
      Is the long tail you're talking about more in 2D rendering itself, or in accommodating the great diversity of the humans using the UI, e.g. accessibility and internationalization?
      - sho_hn 5y ago
        Rendering does have a lot of interesting 2D-specific problems too that 3D engines don't optimize for (Raph Levien's blog has great stuff on this), but what the 3D engines lack is often more related to UI layout, input (e.g. sophisticated focus handling), advanced text (editing, layout, shaping). Unity's probably been investing the most into a more complete 2D toolkit (which is their third or fourth generation of 2D UI toolkit bundled with the engine) lately. Among the FOSS game engine projects Bevy has made strong 2D suitable for UI an explicit goal. But that one true converged contender is still not even on the horizon yet, IMHO.
bluGill 5y ago
Legacy code. I've been doing QT for 10 years, I only heard of rust about 3 years ago, but the hype (particularly memory safety) has got me very interested. If I can take some existing C++ that is due for major surgery for other reasons and write it in rust I'm interested. We know from experience that rewriting our entire system from scratch will take 5 years and cost $150million: I won't even attempt to convince management of that. Our current C++ should be good for 25 years as just C++. if we maintain it well (the major surgery mentioned above) it can last indefinitely. However replacing the current QT GUI is not on the table, it already has our themes. Maybe someday in the future it will be on the table if there is better one and it can work well (look at feel) with out current QT GUI, but for today we don't complain about QT.

ahartmetz 5y ago

There is a lot of stuff there. When I think of Qt, and omitting things like QString and QIODevice / QNetwork: Text rendering, list / grid / tree views, painting primitives and not-so-primitives (e.g. dashed lines), input including multitouch, custom styling, accessibility, many miscellaneous widgets, timers and events, integration with native environment, printing - and a ton of customization points for everything.

wuschelhase 5y ago

It is an enormous effort (read investment) to get to a point of detail, where such a library becomes usable to a wide audience. Consider a simple text input: In some languages (e.g. 'syllable based' korean Hangul) you have to compose multiple keystrokes to get to a complex letter. While you type, the last and as well as the second-to-last complex-characters might still 'trade' consonants and vowels among each other. Now layer in more Dimensions, such as validating that input or line-wrapping, elision and many more. To my mind, only few libraries got to this level of detail without breaking apart on complexity. It requires high maintainer stamina or massive investments.

sho_hn 5y ago
Most of your input example is nowadays typically handled by code outside the GUI toolkits themselves (such as the IME, the text shaping and the font stack), although the general "the GUI devil is in the details" thrust is right.

deleted 5y ago

[deleted]

jcelerier 5y ago

Qt5's qtbase module is over 2 million LOC, and doesn't even cover QML, QtQuick, etc. Just having proper abstractions over each platform[1]'s: - windowing - KB/mouse/tablet/touch input - raster painting - 3D APIs (Vk, D3D, GL, Metal...) - text layout and rendering - support for accessibility APIs + things such as generic data models for tables and trees, etc... is already an immense amount of work, and you haven't even started drawing a single button yet. * https://github.com/qt/qtbase/tree/dev/src/plugins/platforms https://github.com/qt/qtbase/tree/dev/src/plugins/platforms

badsectoracula 5y ago
You do not need to replicate all features of Qt to make a GUI toolkit, especially since Qt tends to have a ton of stuff outside GUIs and actually has two "widgets" approaches (classic widgets and QML). For example the 3D API stuff are pointless beyond context creation, unless you use only that 3D API (instead of underlying window system functionality) to put stuff on screen. Qt also recreates a ton of features found in C++ and if we're considering a new language, chances are the language itself has features that make Qt's unnecessary.
- jcelerier 5y ago
  Which features are you talking about ? Even in c++23 there isn't yet a way to replicate moc, rcc, uic with the same ergonomy for the end user and the same efficiency.
  - badsectoracula 5y ago
    I mean things like containers though in the context of a new language chances are the language itself may provide functionality that makes moc unnecessary. Also you certainly do not need something like moc to make a GUI library, which comes back to what i originally wrote in that you do not need to replicate Qt to have a GUI library.
    - ogoffart 5y ago

IshKebab 5y ago

They're just really enormous libraries with a ton of tiny details you have to get right. Same reason there are so few good FOSS CAD programs or word processors. Tons of work.

jonathanstrange 5y ago

The hardest is to make multiline text input and rich text support. None of the smaller, home-brown GUIs gets this right. You basically have to write a complete editor that supports all languages, including Japanese, Chinese, Arabic, etc. Even native operating system text input widgets have been plagued with problems. Generally, there are tons of edge cases and special input considerations to consider in a GUI, e.g. DPI scaling, accessibility, right-to-left languages and unusual unicode glyph handling (composed glyphs), scrolling behavior & mouse handling, platform-dependent layout issues (HI guidelines), escape characters in file paths and unusual file systems, and so on and so forth. It's quite possible to make a good GUI, just lots of mundane small issues to deal with, and it's overall a massive undertaking. It requires at least an extremely good knowledge of how different languages deal with text and input it.

sharikous 5y ago
Can't you just link HarfBuzz for that?
- jcelerier 5y ago
  Harfbuzz partly comes from Qt's codebase IIRC
- mwcampbell 5y ago
  harfbuzz is for text rendering, not editing. Of course, the former is a prerequisite for the latter, but text editing has plenty of its own complexity.

beowulfey 5y ago

Rust has a number of burgeoning GUI libraries. Some of them are further developed than others. I think the difficulty is just the complexity of the work. It takes a lot of effort to make a complete, functional library, and many of these are largely the work of one to a few people (probably in their spare time)! https://www.areweguiyet.com/ https://www.areweguiyet.com/ The secret, I suspect, is probably "money".

badsectoracula 5y ago

Beyond the "this is too hard" responses (which from personal experience working on GUIs and toolkits for decades i think are overblown), it is also that a GUI toolkit -or any other library really- written in a niche language will only be usable for that niche language's audience but a GUI toolkit -or any other library- written in a language that can be used by other languages with almost zero friction, is way more likely to be used. And people tend to use what they see other people using, thus repeating the cycle. So you see these 15 year old libraries being used because other people are using these 15 year old libraries because they are written in languages that can be (relatively) easily be wrapped (both C and C++ wrapping can be done automatically and there are many tools for that - largely because this is something a ton of people want to do, so again, it feeds back to the cycle of things being popular because they are popular). But there are lots of new toolkits being made, you can even find a submission for a new one in Hacker News almost every month (though the responses are pretty much the same in all of them :-P).

mwcampbell 5y ago
> from personal experience working on GUIs and toolkits for decades i think are overblown) Accessibility and internationalization are really hard though, right? I'm finally doing something about the accessibility issue: https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit Still have a long way to go though.
- badsectoracula 5y ago
  They can be among the harder parts of a toolkit (though it also depends on the toolkit's scope - can't really compare something like Qt that has a very large scope going even outside GUIs with something like imgui, which only provides the most barebones GUI functionality) yes, but i think the "hardness" exists not in how hard they are to have that functionality but in most people not even thinking about these things.
nu11ptr 5y ago
Assuming you are talking about Qt/wxWidgets, and I don't think they are easy to create bindings for due to being written in C++. I think they have been used because they represent the largest, most complete crossplatform codebases representing the traditional desktop GUI using either native widgets, or in Qt's case "simulated" native looking widgets. In contrast, GTK is written in C AFAIK, and anytime a new language springs up the very first thing you generally see is a GTK wrapper. I have always suspected this is because C is far easier to wrap since most languages have a well defined C FFI, but typically lack a C++ one (due to lack of std ABI) thus Qt/wxWidgets bindings typically lag GTK.

fulafel 5y ago

There's a lot of requirements creep, the bar is high, since the estabilished stacks have had decades to build up their feature sets. Complexity multipliers include accessibility, cross-platform, gpu acceleration, complexities of text in the modern world (unicode, fancy rendering like subpixel aa, fonts, bidi...), programming language bindings, memory/lifetime management in presence of different mutually incompatible PL memory management models, native code hostile mobile platforms, etc. Leave any of those out and you start halving your potential users for each feature. (For more specialised, niche gui toolkits the answer is that they're out there, but you've never heard of them because they don't enjoy the network effects that a wider user base gets the big toolkits)

api 5y ago

A high quality desktop GUI library is close to a game engine in terms of difficulty. You have to support a vast array of languages, accessibility, input paradigms, flexible layout, different screen resolutions and DPIs, styling, and so on. It's a massive undertaking.

badsectoracula 5y ago
Considering that some game engines tend to have their own GUI toolkits (e.g. UE4's Slate for example), you can say that it is more difficult to make a game engine than a GUI toolkit :-P.
- sho_hn 5y ago
  I'd say making a comprehensive 2D GUI toolkit is actually more complex and difficult than making a 3D game engine - even one that includes a rudimentary 2D GUI toolkit. There's an enormous long tail to 2D. My current work is exactly at the place where those tech universes overlap and integrate.
  - mwcampbell 5y ago
    Is the long tail you're talking about more in 2D rendering itself, or in accommodating the great diversity of the humans using the UI, e.g. accessibility and internationalization?
    - sho_hn 5y ago
      Rendering does have a lot of interesting 2D-specific problems too that 3D engines don't optimize for (Raph Levien's blog has great stuff on this), but what the 3D engines lack is often more related to UI layout, input (e.g. sophisticated focus handling), advanced text (editing, layout, shaping). Unity's probably been investing the most into a more complete 2D toolkit (which is their third or fourth generation of 2D UI toolkit bundled with the engine) lately. Among the FOSS game engine projects Bevy has made strong 2D suitable for UI an explicit goal. But that one true converged contender is still not even on the horizon yet, IMHO.

bluGill 5y ago

Legacy code. I've been doing QT for 10 years, I only heard of rust about 3 years ago, but the hype (particularly memory safety) has got me very interested. If I can take some existing C++ that is due for major surgery for other reasons and write it in rust I'm interested. We know from experience that rewriting our entire system from scratch will take 5 years and cost $150million: I won't even attempt to convince management of that. Our current C++ should be good for 25 years as just C++. if we maintain it well (the major surgery mentioned above) it can last indefinitely. However replacing the current QT GUI is not on the table, it already has our themes. Maybe someday in the future it will be on the table if there is better one and it can work well (look at feel) with out current QT GUI, but for today we don't complain about QT.