I think the 3 absolute demons that will eventually seek to destroy you in any homebrewn GUI framework will eventually be:
- Rendering and dealing with text in all of its extreme permutation. Styling. Localization. Character sets. Etc.
- Modern accessibility standards. There are countless annoying yet de facto UX patterns that are just nightmarish to check off the list from scratch. Inputs/forms/etc. Even worse than accessibility, because you can decide to forgo that completely if you really wanted. The sheer volume of UX use cases and edge cases involved in even seemingly basic input components is also an exercise in rote dread. You've got input validation, error states, just so many ergonomics to deal with.
- Fluid layouts and scaffolding. This is where modern HTML/CSS finally starts to shine because making flexible layouts is actually quite painless. But it's a motherfucker to roll your own approach.
I had no idea how deep the text rabbit hole goes until a couple of years ago when I got the bright idea to make my own UI rendering engine. Quickly realized that I was waaaay out of my depth, and I now have a profound appreciation for all the existing stuff we take for granted.
With a background in linguistics and a descent understanding of Unicode, I thought I had something of a grip on the complexities of text. But then I read Text rendering hates you[0] and realized I had no idea how hard rendering text really is. The most striking example for me is the Arabic example where allh (Allah) is styled with different colours on each of the four characters, because this particular character sequence is a mandatory ligature if memory serves, and how do you figure out the colour changes when you're layout out a single glyph from the font?
For me, the top of these is accessibility. Obviously people can write code they like for fun and free, but governments are increasingly, and in my opinion rightly, saying that if you want to sell a product it must be accessible if that is reasonable.
People like Apple, Microsoft and browsers put lots of effort into this if you use their existing frameworks right.
It's been bugging me for years, but I don't really enjoy modern HTML/CSS for fluid layouts when it comes to forms.
To do really nice form layouts in a desktop application, alignment and sizing of labels across the entire form becomes really important to me. Products like Developer Express that have a dedicated form layout work so well for this. And some of the swing layout managers I've used (I can't recall the name, too long ago) make complicated form layouts much more sane than grid, flex and other css layouts.
I will say this about HTML+CSS: it's not the best layout system I've ever used, but it's certainly the best one I've used that runs on all the platforms I care about.
That might change with .NET MAUI, though. I'm not too deep into it yet, and it is significantly different enough from HTML+CSS to be a challenge to learn, but what I havelearned so far keeps making me question "why did the CSS version of this have to be so hard?"
The compositor. Dealing with ancient Win32 API, with his semi intelligent windows where seemingly every window feature is in weird undocumented ways coupled. Also, the race condition when rendering, just resize any window and see it jiggle. We seem to have collectively given up on fixing it.
Text Input. While not terrible difficult, so many features. From drag and drop, copy / paste, page up / down, CTRL up down left right, Home / End, wrapping. Text is by far the most complex GUI.
It's not the whole story but part of what makes accessibility hard is toolkits not being designed with it in mind from the beginning. That's how you end up with things like accessibility "modes" that are really just skin deep themes instead of proper modes.
Good accessibility capabilities requires flexibility to be at the core of the UI toolkit. You basically can't make assumptions anywhere.
But you can't forgo accessibility. Anyone who would make software with your framework would be in violation of several laws.
EDIT: I see that there are people down voting several comments in this thread in support of accessibility. I wonder what disagreement that you have? Surely it can't be "not a large enough market". There are more legally blind people in the world than Firefox users, yet web developers will happily test compatibility with that dying browser and eschew screen reader testing.
15+ years ago, I worked for an Australian university. We had a project to migrate to a new student email system – we were going from Novell NIMS (hosted on NetWare) to Sun/iPlanet/JES Messaging (on Solaris).
We asked our disability services office to review the webmail's accessibility. The manager of that office was a blind woman, who was both a staff member and a student, so she had her own personal student account. She told us she couldn't use Sun's webmail, it wouldn't work at all with her screen reader. We complained to Sun, their response was "we know, wait for the next major version".
What did we do? We offered her a shell account on a Solaris box with Pine, and told her that we'd offer the same to any vision-impaired students or staff members who requested it. And she was happy with that solution.
IANAL a lawyer, but from my understanding of disability discrimination law (which is different in different countries anyway), you are legally obliged to offer "reasonable accomodations" – which doesn't have to necessarily be by making the application accessible, it could be offering access to an alternative application instead.
Also, you are only obliged to provide accessibility if a disabled user asks for it, which assumes you have a user with a relevant disability – if your application is sufficiently niche, that might never happen. Suppose you build an internal GUI for SREs to use. Do you need to make that accessible for the vision impaired? Well, are any of your SREs vision impaired? If the answer is "no", then legally you don't. Maybe one day you'll employ a vision impaired SRE – at which point, then you will be obliged to make it work for them. But, maybe you never will, in which case you'll never have that legal obligation.
Not a lawyer, but if this was true, wouldn't a bunch of developers and companies be facing fines? Especially smaller open-source stuff. And larger companies as well (for instance, Reddit's mobile app is infamously inaccessible).
> I see that there are people down voting several comments in this thread in support of accessibility. I wonder what disagreement that you have?
Didn't downvote but I want to share a couple thoughts I've had about accessibility:
- I assume that browser/electron accessibility is not really optimal for users. It's sort-of free if you're building web/browser stuff, which is nice because it's available by default, but I can imagine most applications could be tailored for accessibility and be much more productive and enjoyable for end-users. For instance a "blind mode" for a text editor would probably be a lot different than what you get out of the box from a screen reader + VS Code. (I would love to get feedback on this from someone using a screen reader or accessibility features.)
- I worry you're providing a bit of a moat if you regulate/require accessible software, since for most applications that equates to using a native GUI toolkit or browser-based solution.
AIUI that law only apply to businesses who make their employees use the software without accommodating their disablities, and customers that are required to use inaccessible platforms (e.g. only permitting refunds through a website and not in person/by mail, but the website isn't accessible). It doesn't actually require all programmers to exclusively ship their apps with frameworks with accessibility features.
> UI toolkit is equivalent to a game engine like Unity
Funny that you mention Unity because they first had an immediate mode UI that was very difficult to work with, then they got a more flexible UI but decided to go the HTML way of having separate documents for elements and styles, making the whole design process way more complex.
For me it was the text issues that dulled my desire to keep working it. I was updating a Nim based immediate mode GUI called Fidget (https://github.com/treeform/fidget) and fixed a number of issues. It was fun getting 9-patch rectangles with corners working, etc.
However, text input is hard and tedious! Then you ideally would need to handle the different keybindings for each OS. You also loose any plugins the OS'es provide. Not to mention the lack of accessibility.
I recall reading that browsers shim out to native OS text fields and wonder how that's done. It really seems like the best approach for small GUI libraries to enabled first class text input.
Short of doing a whole CSS rule engine (best) you can also implement a Flutter-like layout system. It is described well by Flutter documentation and is quite flexible.
There might be a few, but the complexity of the task reduces the number of options (the most popular choice is probably FreeType+HarfBuzz). But even then there's the problem that FreeType's text rendering might look slightly different than the underlying system's text renderer (so your application stands out like a sore thumb), and text rendering also affects UI layout (just take right-to-left languages for instance) - so it's often not an isolated drop-in solution.
Ideally the underlying system would offer a low level text rendering API that's independent from the system's UI framework and can be combined with your own rendering efficiently (haven't used it, so don't know how good it actually is, but for instance on Windows there's DirectWrite). The problem with this approach is that not all platforms provide such a modular text renderer (for instance web browsers), and you need different code paths on different platforms (maybe even still have to integrate FreeType because one of the target platforms doesn't expose a text rendering API).
Long ago, as the silicon on the planet was still cooling, a friend of mine did exactly this. And single handedly.
What he essentially did was he cracked open “Inside Mac” and ported it to a C library that ran on the PC.
He did the bulk of it too. Memory manager, Resource manager, QuickDraw, Window manager, Event manager, Font manager.
They changed it up, they didn’t copy the window gadgets and such, scrollbars worked (and looked) different.
But the task was to port a native Macintosh application to the PC, pre-Windows, and keep it portable. It was not a one way trip. The company maintained both versions.
Got the bulk of it done in less than a year. Obviously this was early Macintosh. B&W, bitmap fonts (though the application generated PostScript for printing).
Yup, they don’t call them The Old Days for nothing.
Everything that was simple 20 years ago is now 100x more complicated. Part of the reasons made programming interesting for me long time ago was that fact that one person could tackle a rather complex job all by himself.
You could write a GUI, a game, a text processor, a compiler and even an OS as a one person team. Now you can't and some of the most complicate aspects of software engineering is how to interface your work with the work of others, how to understand what others have done, to have a high level global view of the whole software application and tools your company works on while having a very low level view of the part of the software you are working on.
You can still do that.
You just dont look at all the fancy pancy overengineered frameworks/platforms.
I run a solo business in which i need to do backend, frontend, db, networking, low level hardware, graphics, monetization and more.
I cannot be a specialist, but its still doable to understand all elements of various layers in software/hardware development. Again. Dont look at the hype stuff. Usually the people who are good at the hype stuff are super specialists in that specific thing. Not my thing at least.
>You could write a GUI, a game, a text processor, a compiler and even an OS as a one person team.
Yup.
And I had read earlier that Niklaus Wirth created a computer and many of the layers above, with just a small team. (I guess there must be other such examples from the early days of computing.) Don't have the reference. May be related to his work on Lilith, Ceres, Oberon, etc.
"some of the most complicate aspects of software engineering is how to interface your work with the work of others"
And where exactly is the difference, when you write a OS, where you have to interface with the low level hardware and the choices of those engeneers?
Apart from that, what is stopping you? Just pick a simple plattform and start. But yes, the result will be probably hard to sell, unless you find the right niche.
Alternativly, you can join SerenetyOS, which started exactly as just a one man project and came quite far alone. And now they are getting momentum (100000$ donation to build a browser).
I completely disagree. I am writing an OS in TypeScript. The GUI portion was complete with 15 days.
In JavaScript land people are scared shitless to write original software or learn the basic foundations of their common platforms. So yeah, that would make 10000000x more challenging. But that is a psychology and preparation problem, not a technology problem.
>Everything that was simple 20 years ago is now 100x more complicated
No, it's really not. Let's take just UI animations for example. I can create a fade-in transition with a custom timing function movement in 3 lines of CSS today. To do the same thing natively 20 years ago involved writing hundreds of lines of custom OpenGL code. I get that there's a lot of fatigue from framework churn, but the layers of abstraction are orders of magnitude higher today, to the point that most UI work has become an afterthought.
Everything that was simple 20 years ago is now 100x more complicated. Part of the reasons made programming interesting for me long time ago was that fact that one person could tackle a rather complex job all by himself.
You could write a GUI, a game, a text processor, a compiler and even an OS as a one person team.
You could still do all these things before the summer is out.
Compiler design is no harder today than 20 years ago.
Any text processor you would have created single-handedly 20 years ago is similarly doable.
Simple, performant GUIs are easy if you restrict yourself to a single platform. Windows 11 still runs win32 apps, Ubuntu/GTK is also straightforward.
For an OS, consider targeting a well-documented microcontroller. Some variants are approaching a similar amount of compute and RAM as 25-year-old PC hardware but have Ethernet ports and/or LCD displays.
And if you just want to build a game to say you did, you could build just about anything in the browser using vector graphics primitives reminiscent of DOS.
For a recent project (http://keymux.com/) I chose Yue (https://libyue.com/), a cross-platform native widget GUI toolkit for C++, JavaScript/Node.js, and Lua. I've only used the Lua interface and macOS backend, but it has worked quite well, despite the very steep learning curve. This was also my first desktop GUI app, so I had to learn many implicit concepts that weren't obvious from the otherwise extensive documentation.
Yue was the only option that 1) supported macOS, 2) supported Lua, 3) was sufficiently comprehensive to build a non-toy GUI app, 4) and that I could integrate into my (static) build. I couldn't even get the wxWidgets Lua interfaces to compile, and Qt and FLTK wrappers had similar stories, whereas reverse-engineering the baroque Yue build (based on Google's internal build systems) was relatively simple. The first candidate I tried was libui, but it had some crashing bugs that didn't inspire confidence, the widget set was bare, and most importantly development had ceased. Yue had some sharp edges, but I was able to work around them whilst patiently waiting for patches and fixes upstream.
Immediate mode interfaces were a non-starter for me. For a non-trivial set of otherwise typical controls and window management you have to implement too much yourself, plus being non-native they not only felt wrong (which admittedly is somewhat subjective; the younger crowd seems to think non-native, immediate mode interfaces look more state-of-the-art), but lacked other interfaces for proper desktop integration, like theme change signaling (i.e. notification that a user switch between light and dark modes in the macOS system settings panel).
I used your quotes out of context, I know, because those phrases are in different parts of your comment, and I did it because I could, ahem, reuse your words, and it looked cool to do so, but the question is genuine:
Why do you recommend it despite the very steep learning curve? Because of support for Lua? macOS?
I meant that the steep learning curve related to the intrinsic complexity of dealing with desktop GUI frameworks, which I lacked experience with previously: terminology, layout and flow caveats (e.g. with embedded scroll panels, limitations on autosizing and reflow in the absence of explicit dimensions), etc. The Yue author clearly has extensive GUI SDK experience, and while comprehensive, like many open source projects the Yue documentation assumes some minimal understanding of the concepts and inevitable limitations.
The only possibly unnecessary complexity with Yue is the build framework, but that sort of thing can be quite subjective and a function of various requirements (personal, third-party libraries--it uses Facebook's Yoga for automagic layout and reflow) and familiarity. Excepting libui (which is basically defunct), all the frameworks I investigated had terribly complex builds, so it's pretty much par for the course. Notably, Yue releases prebuilt binaries with every release. I couldn't make use of those because I wanted a fully static, fat application binary (x86-64 + arm64), and also I needed a convenient, local Yue build for writing and testing patches.
These bullet points are exactly what I did in Sciter (https://sciter.com)
- Windowing
-- Tabs
-- Menus
-- Painting
-- Animation
-- Text
-The compositor
-Handling input
-- Pointer input
-- Keyboard input
- Accessibility
- Internationalization and localization
- Cross-platform APIs
- The web view
- Native look and feel
On top of that DOM and CSS implementations to achieve declarative UI. And JS as a languuage behind UI - declarative in some sense way of defining UI behavior.
This is all a very neat summary, but I'll go out on a limb and say that for most of us, the first-order approximation should be "don't. Just don't".
Been there. Done/sort of doing that. Have impressive collection of scars. There are no t-shirts to be had.
This document only barely scratches the surface of the work necessary. If this is your calling, by all means, but expect to sink a good chunk of your life into it. Things are glossed over in a paragraph that mean years of work. (My favorite is the internationalization section, closing with "But don’t worry: there’s a standard. All you need to do is implement it." - All you need to do, indeed :)
To be clear: Colin knows it's years of work. He's been working on a number of excellent projects in the space (xi-editor, druid, ...). But I really feel this deserves a warning sticker, lest you accidentally spend a decade or two of your life on it.
Well, it is definitely not a suicide mission. At least in my Sciter I've implemented all those by myself in reasonable time frame - first version was made in 9 months.
But "yes", you need some prior experience, in order to come up with flexible architecture that will allow to expand it further without major redesigns.
First version had DOM/CSS and used just GDI. GPU support (Direct2D, OpenGL|Metal|Vulkan via Skia) was added later with API staying the same.
Working on Godot Engine, in a team adjacent to things like Unicode fonts (with left to right languages etc.) and multiple windows support was watching an uphill struggle for Godot Engine 4.0.
I have no idea how other team succeed at it either.
If you're interested in what it takes to render bidirectional text with complex scripts and line breaking, I had the experience of implementing that (in immediate mode too) and wrote about it here:
Readit News
- Rendering and dealing with text in all of its extreme permutation. Styling. Localization. Character sets. Etc.
- Modern accessibility standards. There are countless annoying yet de facto UX patterns that are just nightmarish to check off the list from scratch. Inputs/forms/etc. Even worse than accessibility, because you can decide to forgo that completely if you really wanted. The sheer volume of UX use cases and edge cases involved in even seemingly basic input components is also an exercise in rote dread. You've got input validation, error states, just so many ergonomics to deal with.
- Fluid layouts and scaffolding. This is where modern HTML/CSS finally starts to shine because making flexible layouts is actually quite painless. But it's a motherfucker to roll your own approach.
0: https://faultlore.com/blah/text-hates-you/
People like Apple, Microsoft and browsers put lots of effort into this if you use their existing frameworks right.
To do really nice form layouts in a desktop application, alignment and sizing of labels across the entire form becomes really important to me. Products like Developer Express that have a dedicated form layout work so well for this. And some of the swing layout managers I've used (I can't recall the name, too long ago) make complicated form layouts much more sane than grid, flex and other css layouts.
That might change with .NET MAUI, though. I'm not too deep into it yet, and it is significantly different enough from HTML+CSS to be a challenge to learn, but what I havelearned so far keeps making me question "why did the CSS version of this have to be so hard?"
The compositor. Dealing with ancient Win32 API, with his semi intelligent windows where seemingly every window feature is in weird undocumented ways coupled. Also, the race condition when rendering, just resize any window and see it jiggle. We seem to have collectively given up on fixing it.
Text Input. While not terrible difficult, so many features. From drag and drop, copy / paste, page up / down, CTRL up down left right, Home / End, wrapping. Text is by far the most complex GUI.
Good accessibility capabilities requires flexibility to be at the core of the UI toolkit. You basically can't make assumptions anywhere.
EDIT: I see that there are people down voting several comments in this thread in support of accessibility. I wonder what disagreement that you have? Surely it can't be "not a large enough market". There are more legally blind people in the world than Firefox users, yet web developers will happily test compatibility with that dying browser and eschew screen reader testing.
We asked our disability services office to review the webmail's accessibility. The manager of that office was a blind woman, who was both a staff member and a student, so she had her own personal student account. She told us she couldn't use Sun's webmail, it wouldn't work at all with her screen reader. We complained to Sun, their response was "we know, wait for the next major version".
What did we do? We offered her a shell account on a Solaris box with Pine, and told her that we'd offer the same to any vision-impaired students or staff members who requested it. And she was happy with that solution.
IANAL a lawyer, but from my understanding of disability discrimination law (which is different in different countries anyway), you are legally obliged to offer "reasonable accomodations" – which doesn't have to necessarily be by making the application accessible, it could be offering access to an alternative application instead.
Also, you are only obliged to provide accessibility if a disabled user asks for it, which assumes you have a user with a relevant disability – if your application is sufficiently niche, that might never happen. Suppose you build an internal GUI for SREs to use. Do you need to make that accessible for the vision impaired? Well, are any of your SREs vision impaired? If the answer is "no", then legally you don't. Maybe one day you'll employ a vision impaired SRE – at which point, then you will be obliged to make it work for them. But, maybe you never will, in which case you'll never have that legal obligation.
Didn't downvote but I want to share a couple thoughts I've had about accessibility:
- I assume that browser/electron accessibility is not really optimal for users. It's sort-of free if you're building web/browser stuff, which is nice because it's available by default, but I can imagine most applications could be tailored for accessibility and be much more productive and enjoyable for end-users. For instance a "blind mode" for a text editor would probably be a lot different than what you get out of the box from a screen reader + VS Code. (I would love to get feedback on this from someone using a screen reader or accessibility features.)
- I worry you're providing a bit of a moat if you regulate/require accessible software, since for most applications that equates to using a native GUI toolkit or browser-based solution.
(IANAL)
Approach it like that and you have a slight fighting chance because you know what you are getting into.
Funny that you mention Unity because they first had an immediate mode UI that was very difficult to work with, then they got a more flexible UI but decided to go the HTML way of having separate documents for elements and styles, making the whole design process way more complex.
I even implemented a fair subset of CSS grid:
( https://github.com/elcritch/cssgrid )However, text input is hard and tedious! Then you ideally would need to handle the different keybindings for each OS. You also loose any plugins the OS'es provide. Not to mention the lack of accessibility.
I recall reading that browsers shim out to native OS text fields and wonder how that's done. It really seems like the best approach for small GUI libraries to enabled first class text input.
Short of doing a whole CSS rule engine (best) you can also implement a Flutter-like layout system. It is described well by Flutter documentation and is quite flexible.
Ideally the underlying system would offer a low level text rendering API that's independent from the system's UI framework and can be combined with your own rendering efficiently (haven't used it, so don't know how good it actually is, but for instance on Windows there's DirectWrite). The problem with this approach is that not all platforms provide such a modular text renderer (for instance web browsers), and you need different code paths on different platforms (maybe even still have to integrate FreeType because one of the target platforms doesn't expose a text rendering API).
What he essentially did was he cracked open “Inside Mac” and ported it to a C library that ran on the PC.
He did the bulk of it too. Memory manager, Resource manager, QuickDraw, Window manager, Event manager, Font manager.
They changed it up, they didn’t copy the window gadgets and such, scrollbars worked (and looked) different.
But the task was to port a native Macintosh application to the PC, pre-Windows, and keep it portable. It was not a one way trip. The company maintained both versions.
Got the bulk of it done in less than a year. Obviously this was early Macintosh. B&W, bitmap fonts (though the application generated PostScript for printing).
Yup, they don’t call them The Old Days for nothing.
You could write a GUI, a game, a text processor, a compiler and even an OS as a one person team. Now you can't and some of the most complicate aspects of software engineering is how to interface your work with the work of others, how to understand what others have done, to have a high level global view of the whole software application and tools your company works on while having a very low level view of the part of the software you are working on.
Yup.
And I had read earlier that Niklaus Wirth created a computer and many of the layers above, with just a small team. (I guess there must be other such examples from the early days of computing.) Don't have the reference. May be related to his work on Lilith, Ceres, Oberon, etc.
https://en.m.wikipedia.org/wiki/Niklaus_Wirth
Also see Wirth's Law:
https://en.m.wikipedia.org/wiki/Wirth%27s_law
The derived / related laws mentioned there are also interesting.
https://github.com/SerenityOS/serenity
And where exactly is the difference, when you write a OS, where you have to interface with the low level hardware and the choices of those engeneers?
Apart from that, what is stopping you? Just pick a simple plattform and start. But yes, the result will be probably hard to sell, unless you find the right niche.
Alternativly, you can join SerenetyOS, which started exactly as just a one man project and came quite far alone. And now they are getting momentum (100000$ donation to build a browser).
https://serenityos.org/
In JavaScript land people are scared shitless to write original software or learn the basic foundations of their common platforms. So yeah, that would make 10000000x more challenging. But that is a psychology and preparation problem, not a technology problem.
No, it's really not. Let's take just UI animations for example. I can create a fade-in transition with a custom timing function movement in 3 lines of CSS today. To do the same thing natively 20 years ago involved writing hundreds of lines of custom OpenGL code. I get that there's a lot of fatigue from framework churn, but the layers of abstraction are orders of magnitude higher today, to the point that most UI work has become an afterthought.
You still can and many still do, but we expect a lot more from our tools in 2023 than we did in 1983.
You could write a GUI, a game, a text processor, a compiler and even an OS as a one person team.
Compiler design is no harder today than 20 years ago.
Any text processor you would have created single-handedly 20 years ago is similarly doable.
Simple, performant GUIs are easy if you restrict yourself to a single platform. Windows 11 still runs win32 apps, Ubuntu/GTK is also straightforward.
For an OS, consider targeting a well-documented microcontroller. Some variants are approaching a similar amount of compute and RAM as 25-year-old PC hardware but have Ethernet ports and/or LCD displays.
And if you just want to build a game to say you did, you could build just about anything in the browser using vector graphics primitives reminiscent of DOS.
[1] https://en.wikipedia.org/wiki/HLH_Orion
QT wasn’t just a video player but also an interactive environment, so this was a lot of API surface.
Yue was the only option that 1) supported macOS, 2) supported Lua, 3) was sufficiently comprehensive to build a non-toy GUI app, 4) and that I could integrate into my (static) build. I couldn't even get the wxWidgets Lua interfaces to compile, and Qt and FLTK wrappers had similar stories, whereas reverse-engineering the baroque Yue build (based on Google's internal build systems) was relatively simple. The first candidate I tried was libui, but it had some crashing bugs that didn't inspire confidence, the widget set was bare, and most importantly development had ceased. Yue had some sharp edges, but I was able to work around them whilst patiently waiting for patches and fixes upstream.
Immediate mode interfaces were a non-starter for me. For a non-trivial set of otherwise typical controls and window management you have to implement too much yourself, plus being non-native they not only felt wrong (which admittedly is somewhat subjective; the younger crowd seems to think non-native, immediate mode interfaces look more state-of-the-art), but lacked other interfaces for proper desktop integration, like theme change signaling (i.e. notification that a user switch between light and dark modes in the macOS system settings panel).
All in all I would highly recommend Yue.
>despite the very steep learning curve.
?
I used your quotes out of context, I know, because those phrases are in different parts of your comment, and I did it because I could, ahem, reuse your words, and it looked cool to do so, but the question is genuine:
Why do you recommend it despite the very steep learning curve? Because of support for Lua? macOS?
The only possibly unnecessary complexity with Yue is the build framework, but that sort of thing can be quite subjective and a function of various requirements (personal, third-party libraries--it uses Facebook's Yoga for automagic layout and reflow) and familiarity. Excepting libui (which is basically defunct), all the frameworks I investigated had terribly complex builds, so it's pretty much par for the course. Notably, Yue releases prebuilt binaries with every release. I couldn't make use of those because I wanted a fully static, fat application binary (x86-64 + arm64), and also I needed a convenient, local Yue build for writing and testing patches.
- Windowing
-- Tabs
-- Menus
-- Painting
-- Animation
-- Text
-The compositor
-Handling input
-- Pointer input
-- Keyboard input
- Accessibility
- Internationalization and localization
- Cross-platform APIs
- The web view
- Native look and feel
On top of that DOM and CSS implementations to achieve declarative UI. And JS as a languuage behind UI - declarative in some sense way of defining UI behavior.
Right now I'm using libgdx so I can have a cross platform UI and then specific code for USB communication for each platform.
Sciter would be great if I could use it.
Been there. Done/sort of doing that. Have impressive collection of scars. There are no t-shirts to be had.
This document only barely scratches the surface of the work necessary. If this is your calling, by all means, but expect to sink a good chunk of your life into it. Things are glossed over in a paragraph that mean years of work. (My favorite is the internationalization section, closing with "But don’t worry: there’s a standard. All you need to do is implement it." - All you need to do, indeed :)
To be clear: Colin knows it's years of work. He's been working on a number of excellent projects in the space (xi-editor, druid, ...). But I really feel this deserves a warning sticker, lest you accidentally spend a decade or two of your life on it.
But "yes", you need some prior experience, in order to come up with flexible architecture that will allow to expand it further without major redesigns.
First version had DOM/CSS and used just GDI. GPU support (Direct2D, OpenGL|Metal|Vulkan via Skia) was added later with API staying the same.
I have no idea how other team succeed at it either.
<edit>
Recognize every item on this list. EVEN THE WEBVIEW ONE https://github.com/godotengine/godot-proposals/issues/960
Unicode variables names https://github.com/godotengine/godot-proposals/issues/916
https://hasen.substack.com/p/imgui-text
So you want to write a GUI framework - https://news.ycombinator.com/item?id=28127492 - Aug 2021 (173 comments)