Project sounds great. I’ve long wished for a native Ada GUI library!
Is there (or will there) be support for rendering openGL into a widget?
Yes, I plan to add some kind of canvas widget, and also opengl can be also a good thing to add. Feel free to add an issue for feature request
Are there plans for accessibility (for screenreaders for example)? Or is this use case already working?
Thanks, the project looks interesting.
Edit: sorry for the noise. It’s in the roadmap 
There has long been Gnoga, a native Ada GUI library! There has less long been the sample implementation of Ada GUI, also a native Ada GUI library.
Aside. “Native” means using drivers or OS calls for rendering. Browser-based GUI is not native.
Then in my view Ada GUI worth of considerable efforts it would require to develop and maintain should refrain from using anything but Ada language and be self-contained. The latter is especially important, because for example GTK is incredibly difficult to deploy because of countless configuration and supplementary files needed to make it work. So, please, no CSS, no XML, no Toml, no JSON (the list is countably infinite).
Something like VCL or LCL would be nice to have, but with several backends for drawing widgets.
I’m wondering if it would be possible to embed web based stuff in adi, i.e. youtube videos.
the html view widget is intended to be for inline documentation, not a fully fledged web browser, if you need that, you can use webview[1], adi2 could adopt it as an extension with a dedicated widget
Yup, having that as an extension would be very useful.
I use “native” to mean “not a binding”. Note that what you call a “native” implementation of Ada GUI is possible and would be welcomed.
So long the OS that has no Ada API, any GUI must be bindings. I prefer “native” to refer to the target. If the target is a browser it can be script-based. But for a proper OS the GUI should be binding to that OS rather than binding to some library like Qt, GTK, MFC.
But before all, there must be an idea of the architecture. I find the event-driven approach lacking and insufficient for Ada, especially in the context of tasking. This is tightly related to the choice of decomposition running along the widget hierarchy and containers of, which is proven to be useful by many decades of practice, but leaves the processing to unstructured and untyped event handling. I have no idea how to address this, so I expect someone more clever than me to come up.
I’m trying to add it now.
Looks like webview can only take in a native window pointer, not a surface pointer for a widget. Google says to use cef instead.
You can with SDL3/SDL_GetWindowProperties - SDL Wiki
You can get the window pointer via that and assign the entire window to have the browser drawn inside, but not a widget because offscreen rendering isn’t in webview.
I will check, because we can also say to webview which region of the window to use for render, so the adi’s webview widget needs to track it’s own area and then we need only to ensure that webview renders after the widget tree is rendered, does it make sense?
The only dimensions I see in api.h and the bindings is webview_set_size and set_size, which only sets the width and height, not the origin.
You are right and there are open webview issues regarding this, I think cef is a better bet right now.
The webview was a nice idea because it uses the native system browser, and it should be relatively easy to patch to set the widget area, on windows, linux and macos, except on wayland, where things get complicated.
There is a shift in how most “modern” GUI frameworks (react, Android, …) are designed.
Widgets cannot generate events at arbitrary time, but only in the cycle of state → render and then event → update state. So both render and state update are pure functions without side effects by default.
There are different techniques to reduce the effort required for render, e.g. “shadow DOM”, etc.
This design method has not been used for any native GUI SDKs as far as I know.