| > We really should be trying to use the native GUI toolkit Yes. The problem with that is that it requiere experience * each toolkit and that is pain-full for many. This cause a FORCED split (when multi-platform): - You want easy to use and fast iteration. You NOT use native UI. Reach for mediocre options - You want the BEST of the BEST of the BEST. You pick native UI. However sometimes that toolkit is nuts (Windows API, Android, Linux. Ok like all of them?) Or if lucky you know the other alternative (Windows -> Delphi, Android -> Kotlin, Linux -> ????) ---- This is not a fair fight. UI is too hard everywhere. C++ toolkits are nuts. And it not need to be this way. I think today we already have a good idea in how truly a good toolkit must be done:
https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh... - A lot can be actually cross-platform: Layouts, Units, colors, fonts calculation... - Widget definition with a DSL (like SwiftUI) This allow: - Real-time drawing of widgets AND easy drag-drop UI creation like Delphi or HyperCard (this is where HTML beat almost everything) The above are candidates for cross-ui then you need: - Rendered by each toolkit. With native controls - Some way to communicate the backend to this front-end I think this is alike a game engine: 1- You define the UI: <Window title="hello"><UIButton if="iOS"> <Button if="the others">
2- You have a driver that launch the UI: UI derived from BaseUI..
//customize it for my project or create a new platform
UI.register(UIButton...
UI.register(UIWindow for "Window"
//Attach listeners..
UI.listen(...)
//Run the UI
UI.run(the UI directory)
When using a "no namespaced" control like "Button" it work like Flutter: The engine chose whatever it want. When use a specific control "UIButton" it trust the launcher to handle it. Or fallback if to the generic.--- To be clear: This is almost the same as usual. Except it work like a interpreted language: It have a monolithic core but is possible to code a specific version per platform (if desired). The critical component is the ability to register to the engine (very easily!) new widgets, listeners, behaviors. etc. |