Since Compose splits the machinery and the UI, how...

# compose

[CLOVIS]

Since Compose splits the machinery and the UI, how complicated would it be to create adapt Compose for other frameworks? Let's say I'm writing something directly with OpenGL and I'd like to use Compose with it. Is it just a matter of reimplementing all Composables (which there are a lot of, so it would take a lot of time) or is there actually something complicated that ties Compose to Skija/Skiko?

[Zach Klippenstein (he/him) [MOD]]

Are you trying to create a port of Compose UI that uses OpenGL for drawing, but with all the same existing Compose UI apis? That would probably be a ton of work, because I think that layer is pretty coupled to skia. If you're trying to just create an API for something specific to OpenGL, eg doing 3D rendering, you’d have a lot more freedom to think up what composables you’d even want to make available. Then you'd need to implement a custom Applier and figure out what you want your “nodes” in your emitted tree to be.

[CLOVIS]

Maybe not 100% exactly (I don't really want feature parity with normal Compose UI), but more something like “hey, the OpenGL will have 3d and stuff, but at some point it needs menus”

Using Compose features for these menus would be very convenient, but of course that's fairly simple so I guess it's only a few dozen widgets at most

[CLOVIS]

Essentially I'm interested in the basics like List, LazyList, Button, Text, ... but they don't need to be exactly the same, just similar enough that I get the benefits from declarative frameworks (instead of having to use events etc)

[CLOVIS]

I would still be using Compose for 2D UI, but with a completely different backend than Skija. Because the domain (game menus) is much simpler than full blown desktop UIs, it sounds like it should be a few dozen Composables, but I have no idea if it's even possible

[CLOVIS]

I've heard someone made a Compose UI version for the terminal/CLI, I'll need to check that I guess 🤔

[Zun]

I guess you mean this project? https://github.com/JakeWharton/mosaic

[CLOVIS]

I think so. I have no idea how that works though.

[Zach Klippenstein (he/him) [MOD]]

Does skija not support rendering to an arbitrary OpenGL context/surface? One other approach that might get you up and running quicker is to find an existing, object-oriented toolkit for building UIs in OpenGL, then just write a composable wrapper around that.

[Alexandre Elias [G]]

Compose is tied to Skia via the code in the ui/graphics directory. Every composable winds up doing drawIntoCanvas or similar. ui/graphics assumes it's targeting specifically Skia in a number of ways so it probably doesn't make sense to rewrite the implementation of graphics to target a custom OpenGL backend

[Alexandre Elias [G]]

you could build stuff directly on Compose compiler+runtime low level like that command-line-UI project. If you also value the layout-related parts of Compose, they are technically independent of graphics but in the same Maven artifacts, so you'd need to fork UI+foundation and strip out most of the other files

[Alexandre Elias [G]]

for a UI toolkit designed specifically for games, I might also suggest https://github.com/ocornut/imgui . That toolkit's "immediate-mode" philosophy has some affinity to Compose's "declarative" philosophy

[CLOVIS]

Thanks a lot for the ideas 👍

[CLOVIS]

Is there any chance that the layout logic be extracted into its own artifact?