[HelloNurse]

> the backend for rendering could be skia, vulkan, directx etc.

It doesn't really matter, these are just ways to draw into a native window and not the backend that owns that window.

> Once the hierarchy of UI widgets are built and rendered, what is left, is the interaction with the user.

Without interaction they aren't UI widgets, but merely organized graphics. You are only considering the easy, portable part of a GUI.

> I gave a look at other open source projects but I couldn't find any simplified one.

Consider the Windows API functions that deal with the GUI: they are comprehensive (particularly with respect to handling input and events), reasonably low level and more mature than anything you can design.

If you want to do more, layering something portable on top of them and on top of similar libraries for other platforms, the end product will be more complex, not simple (or naively "simplified").

I suggest Dear IMGUI and Qt as good case studies of opposite approaches: forfeiting platform specific and advanced features in order to simplify the user's job, or adding to native libraries whatever it takes to do everything well and in the same way on all platforms without reducing complexity. Test question: what do you want to do for assistive technology?

[CodeVisio]

>It doesn't really matter, these are just ways to draw into a native window and not the backend that owns that window.

I know. I mentioned them because I wanted to give a bit of context.

>Without interaction they aren't UI widgets, but merely organized graphics. You are only considering the easy, portable part of a GUI.

Again, I know.

>Consider the Windows API functions that deal with the GUI: they are comprehensive (particularly with respect to handling input and events), >reasonably low level and more mature than anything you can design.

For sure they have been maintained for a long time but if you have followed the development of the basic ones (edit, checkboxes, combos etc) and the common control ones (listview, treeeview) etc, you should have known how much they are a pin in the ass when it comes to customize them (owner drawn and custom drawn). They were never updated by Microsoft but only extended. QT, for example, took the opposite side as an approach. Everything is stretchable by default.

The trend nowadays is to use some sort of chromium embedded engine and building upon that your programs or web apps with CSS&HTML&JS. Now, the fact that we have tons of RAMS, TBs of hard disks, and missiles as CPUs doesn't justify to have a more than 100GB of desktop program just to say "Hello World!"

>I suggest Dear IMGUI and Qt...

Dear ImGUI is more appropriate for games logic than for desktop programs. QT has GBs of DLL you have to bring with you just to say, again, Hello World. Additionally, you have to follow a university course to understand their policy regarding licences. For desktop programs there is no need for a retained mode approach. I would consider both: a GUI you can build from an xml-alike file and by interacting with objects.

>what do you want to do for assistive technology?

I didn't get it. What do you mean exactly?

A similar question like mine:

https://www.reddit.com/r/cpp/comments/1eek3a5/what_would_you...

[HelloNurse]

Do you intend to support screen readers, voice input etc. with not very portable complex technology or to leave behind disabled end users for the sake of "simplicity" and portability?

More generally, what do you plan to do better than current multiplatform GUI libraries? A clear value proposition is necessary.

[CodeVisio]

Before walking and running, it should be capable first of standing up.

Screen readers, voice input, etc are additional features one can add once the "core" is done, in future steps.

My issues are basic. How to organize a hierarchy of UI widgets and in a clean way such that it supports features like event notifications, bubbling them, hovering, focusing, mouse capturing, and it is at the same scalable: If I add another UI widgets later (a composition of basic and available ones), it should be done with less efforts and leaving me to concentrate on the new functionalities instead of replicating existing behaviors.

I was able to handle buttons, check boxes and single line text boxes with a custom rendering system I can change at design time. But the hierarchy of widgets, the design of C++ classes, and the event notification are not clean (although working), hence the bells started to ring.