|
|
|
|
|
|
by MomsAVoxell
12 days ago
|
|
|
Ah, that makes sense .. so I could write a clx-oriented app which chooses to load the clx-objcsend module (based on its assessment of which platform its running on of course) .. which I could then use to formulate a native GUI on MacOS/iOS. I have a few GUI libraries I've written in Lua for other projects, which depend basically on having surface-manipulation and event-management functions from the native platform available .. I might have a go at porting these once I dive a bit deeper into clx. I've used other Lua-based engines in the past to accomplish a 'one codebase/GUI runs on all platforms' target in the past, but those engines have faded away - mostly due to the dependency on LuaJIT and the subsequent brickwalling of JIT in iOS, where the apps were making their revenue - so having clx at hand is an exciting opportunity .. assuming I can get the GUI code ported in a way that it is functional on at least the major platforms .. will ping you on GitHub if I make some progress on this, I've been meaning to bring the GUI code from those older projects into the modern context, and clx may well be the way to do it .. |
|
|
This is exactly the kind of scenario where I think third-party clx modules make sense: keep the core runtime portable and let platform-specific bindings live outside of it.
A clx-objc (or metal-cpp or any gui backend) module would be an interesting experiment, and the same approach could apply to other platforms (Win32, GTK, etc.)
Clx is still a relatively young project, so please be a bit indulgent with bugs or missing features, but I'd definitely be interested in seeing/helping what you build!