The two things I’m trying to look for immediately when triaging an UI framework are:
How do I create/add custom widgets in it? (I seem to have found that the need to do this shows up always sooner or later in any non-trivial GUI app.)
Can I access the native “handle” of the underlying native OS GUI API somehow? (The HWND on M$Win, etc.; again, I’m quite sure I’ll need to use it to add some feature that is Not Yet Available™ in this yet another forever Not Fully Featured Yet™ UI framework - in spite of the little bit of sarcasm I see it as more than fine and am absolutely grateful, because we all know you don’t have Qt-level experience and budget; far from it, we know most UI libs are usually one awesome person’s gift to humanity, including notably and healthily themselves - but let’s not pretend it’s otherwise, and thus please, pretty pretty please, let me open the warranty-voiding service access hatch so that I can do work around the inherently leaky abstractions).
Dear @raph, would you mind sharing your thoughts on that? Though sorry if that’s too early - I got it that the article is mostly an early conceptual discussion (as kindly disclaimed in the final section). It may well be an implementation detail that’ll come into play only later. But you also say you want ”[to] gather feedback” - so here’s mine! :) And thanks a lot for sharing; although I must admit I haven’t really managed to understand the contents on the article yet on my first read; but I’m pretty sure there are others who did, and maybe I’ll manage at some later read, possibly. Or I’ll just wait until this gets to some more advanced stage of development, and try again then 😅
The question of creating custom widgets is orthogonal to the reactivity architecture. SwiftUI, for example, is essentially a closed world, and does not give direct access to layout and drawing protocols. Note though that a lot of the things it gives you are fairly low level; you can basically do semi-custom widgets with Canvas and gesture recognizers, and similarly semi-custom layout with GeometryReader.
That said, in what I’m building everything is open-ended and transparent, and people are invited to make custom things. That’s actually kinda necessary, because building a full set of primitives requires a lot of work.
Getting the handle is only half the story, but it does exist in Druid under a feature flag. The deeper question is, for example, whether scrolling is integrated with the compositor. That’s a much harder problem, and not one I’m making any claims to solve.
Regarding open-endedness and window handles and whatnot, I hope you steal iced’s best feature — its modularity. With iced, you don’t have to use iced-winit, you can always integrate the windowing system on your own instead. This is really good.
This is very much a tradeoff. It makes sense when the integration with the host is simple, but when you get into things like IME and accessibility, it’s not at all clear how to make things pluggable.
I’m not saying it can’t be solved, just that it’s harder than it may first seem. I have a companion blog post in the works, and will try to address this somewhat in that.
Having state and view hierarchies known at compile time makes it sound to me at least that you’d have great difficulty building anything with user-driven UI, either in response to data or simple customisation / scripting?
If statically typed view hierarchies were the only way to do it, yes. But there is opt-in type erasure (AnyView) and a working prototype of Python bindings. I would characterize this flexibility as one of the great strengths of the architecture.
I haven’t been following Druid all that closely. Does anyone have some color to add to this?
I see what you did there.
The two things I’m trying to look for immediately when triaging an UI framework are:
HWNDon M$Win, etc.; again, I’m quite sure I’ll need to use it to add some feature that is Not Yet Available™ in this yet another forever Not Fully Featured Yet™ UI framework - in spite of the little bit of sarcasm I see it as more than fine and am absolutely grateful, because we all know you don’t have Qt-level experience and budget; far from it, we know most UI libs are usually one awesome person’s gift to humanity, including notably and healthily themselves - but let’s not pretend it’s otherwise, and thus please, pretty pretty please, let me open the warranty-voiding service access hatch so that I can do work around the inherently leaky abstractions).Dear @raph, would you mind sharing your thoughts on that? Though sorry if that’s too early - I got it that the article is mostly an early conceptual discussion (as kindly disclaimed in the final section). It may well be an implementation detail that’ll come into play only later. But you also say you want ”[to] gather feedback” - so here’s mine! :) And thanks a lot for sharing; although I must admit I haven’t really managed to understand the contents on the article yet on my first read; but I’m pretty sure there are others who did, and maybe I’ll manage at some later read, possibly. Or I’ll just wait until this gets to some more advanced stage of development, and try again then 😅
The question of creating custom widgets is orthogonal to the reactivity architecture. SwiftUI, for example, is essentially a closed world, and does not give direct access to layout and drawing protocols. Note though that a lot of the things it gives you are fairly low level; you can basically do semi-custom widgets with Canvas and gesture recognizers, and similarly semi-custom layout with GeometryReader.
That said, in what I’m building everything is open-ended and transparent, and people are invited to make custom things. That’s actually kinda necessary, because building a full set of primitives requires a lot of work.
Getting the handle is only half the story, but it does exist in Druid under a feature flag. The deeper question is, for example, whether scrolling is integrated with the compositor. That’s a much harder problem, and not one I’m making any claims to solve.
Regarding open-endedness and window handles and whatnot, I hope you steal iced’s best feature — its modularity. With iced, you don’t have to use
iced-winit, you can always integrate the windowing system on your own instead. This is really good.This is very much a tradeoff. It makes sense when the integration with the host is simple, but when you get into things like IME and accessibility, it’s not at all clear how to make things pluggable.
I’m not saying it can’t be solved, just that it’s harder than it may first seem. I have a companion blog post in the works, and will try to address this somewhat in that.
Having state and view hierarchies known at compile time makes it sound to me at least that you’d have great difficulty building anything with user-driven UI, either in response to data or simple customisation / scripting?
If statically typed view hierarchies were the only way to do it, yes. But there is opt-in type erasure (AnyView) and a working prototype of Python bindings. I would characterize this flexibility as one of the great strengths of the architecture.
Ah, I thought that part (the erasure view) was describing the SwiftUI system, thanks for clearing that up.