Is there any reason of why skiko depends on AWT? I...

# compose-desktop

[Abdelilah El Aissaoui]

Is there any reason of why skiko depends on AWT? If I'm not mistaken, skija doesn't depend on it (using HumbleUI fork). My idea is to, eventually, be able to use Compose without AWT nor Swing but skiko is the first issue I'm facing, so I was wondering about the reason behind this dependency. The Skija version with GraalVM native image is a standalone binary without any AWT or extra dependencies, but the skiko also builds a bunch of files that require additional libraries (or a fallback build)

[Kirill Grouchnikov]

You still need the underlying layer of windowing APIs to host the content and process the events. AWT / Swing was the prime choice given JB experience with using Swing for all their IDEs.

[Kirill Grouchnikov]

Skija is an older go they had at it, and the reason it doesn’t have windowing stuff is that they abandoned it and switched to kotlin before they added these implementation dependencies

[jw]

What are you actually trying to do by avoiding the AWT dependency?

[jw]

They recently moved motion event handling out of Skiko which was a huge boon to setting it up on different stacks.

[jw]

Now you pretty much just need a working GL or GLES context and you're good insofar as Skiko is concerned

[jw]

Compose UI has some other things you'll have to do, but nothing insurmountable

[jw]

That's where the touch events and key events are now, along with knowledge of the main thread and various hooks into platform capabilities and behaviors

[Adam Brown]

I'm sure it would be super low priority, but I would love to eventually see native windows and Mac implementations

[Adam Brown]

that was a great talk about the light switch by the way @jw

[jw]

Skiko has native Mac

[jw]

The original Compose UI native demos were on Mac before they were on iOS

[seb]

I'd like an official native Compose for Desktop, too, but mostly for "embedded" (on reasonably performant SOCs of course)

[seb]

On desktop the JVM is relatively easy to handle/embed — see https://github.com/fourlastor-alexandria/construo

[Abdelilah El Aissaoui]

You still need the underlying layer of windowing APIs to host the content and process the events. AWT / Swing was the prime choice given JB experience with using Swing for all their IDEs.

Yes, I know. I have got an example running of Skiko/Skija (also Compose UI) with Winit (https://github.com/rust-windowing/winit) instead of AWT/Swing to host the content and handle the events

[Abdelilah El Aissaoui]

What are you actually trying to do by avoiding the AWT dependency?

Multiple factors like curiosity, better wayland support (unless there have been improvements in this regard that I'm not aware of), smaller binary size & remove any dependency that difficults GraalVM native-image builds.

In part I'd like to have compose-desktop & Kotlin as an alternative to Flutter for Rust desktop projects (again, it's more of a toy project than anything serious)

[jw]

The JetBrains runtime on which Compose UI for JVM Desktop runs does have native wayland support but you'd have to recompile and bundle your own Skiko to take advantage of that.

[seb]

In general if you do UI on the JVM you pretty much must use the JBR

[seb]

It's the only one that has hidpi support and is able to do semi-competent font loading on Windows and Linux

[seb]

Unfortunately Swing/AWT have been in bugfix mode only since forever, outside of the JBR

[jw]

Yeah and the Wayland support in OpenJDK has been very slow going. Don't see much public progress on it, although that doesn't mean that aren't making progress.

[Abdelilah El Aissaoui]

Skiko doesn't support wayland tho. I just tested that a few mins ago 😞 It seems to depend on some X11 calls, there is an issue about it iirc

[seb]

Oh also font rendering on other JVMs is generally atrocious

[Abdelilah El Aissaoui]

Ah it's the dependency on JAWT dang

[Abdelilah El Aissaoui]

https://github.com/JetBrains/skiko/issues/28

[jw]

Yes, but now that event handling has moved from Skiko to Compose UI it should be pretty simple to compile in Wayland support yourself for now.

[jw]

You might not even need it, actually, since Skiko can set itself up with just a GL context.

[jw]

So the Wayland setup could be done locally in your app to get a GL context and then you initialize Skiko on that

[jw]

I did this recently but with OpenGL ES. Skiko doesn't know anything about how it gets set up

[Abdelilah El Aissaoui]

Yep, that's exactly what I'm trying right now 😄
One more reason to get rid of the AWT/Swing stuff is to be able to finally fix some minnor issues like this one https://github.com/JetBrains/compose-multiplatform/issues/188

[Abdelilah El Aissaoui]

Using Winit took 5min to add proper hidpi scaling in linux while the issue has been open for quite a while 😕

[seb]

Fractional scaling on Linux is only sort of kind of working correctly even in Swing, or at least was six months ago when I checked. Only integer scaling works correctly, and that only on the JBR

[Abdelilah El Aissaoui]

For now I've only tested integer scaling, I'll spin up a KDE VM which supports fractional scaling, it would be nice for a 1080p laptop with small display that I'm using. For now I'm setting the scaling manually in my app but it would be nice to work oob.

In any case, thank you for your time and responses 🙂 I'll share my progress in the future in case someone else is interested