Is the long term plan to replace awt with skiko (to whatever extent possible)?

# compose-desktop

[eygraber]

Is the long term plan to replace awt with skiko (to whatever extent possible)?

[jim]

Compose already uses Skiko. Swing/AWT is just an interoperability layer that gives you a jvm-compatible place to put your skiko canvas.

Your question makes me wonder if you were under the impression that Compose was drawing to AWT. If this was the genesis of your question, it is understandable how you came to this conclusion, but it's actually not how it works.

[eygraber]

I'm asking because I was doing some work on Jetbrains Compose yesterday and noticed that in a bunch of places there are still awt APIs being used for desktop when (I think) it could be using Skiko.

For example, an extension on KeyEvent in the desktop source set is comparing the native value against awt values, while the js and native ones use a Skiko value.

I'm guessing that it's like that because awt was used before Skiko was introduced, and I'm asking if the eventual plan is to move everything over to Skiko

[jim]

Ah, yeah, that's fair. The Skiko key event APIs were added to Skiko fairly recently, it might make sense to migrate those over to expose the Skiko wrappers.

There is always a balance though. Oftentimes details/subtleties are lost when abstracting across platforms/APIs. Wrappers can only lose fidelity, they can never generate new information, so there will likely always be times when users may need to drop to lower level APIs and access the underlying objects. This is why KotlinNative objects often expose the underlying native objects, and we'd probably need to continue doing that even if we added references to Skiko wrappers as a level of abstraction.

But yes, exposing skiko wrappers for key events would make it easier to abstract across platforms, which seems desirable long-term.

[alexey.tsvetkov]

Is the question about lack of Skiko APIs compared to AWT APIs or that Skiko uses AWT under the hood?
If the question is about the lack of Skiko APIs, then it’s better to file a feature request.

If the question is about the current implementation, then I think replacing AWT is possible, but we don’t have a definite plans or even decision to do so. AWT is used by the desktop Skiko for window management & input handling (mouse/keyboard/touch events). I know the following reasons, why it is used:
1. AWT already exists & it already implements window management & input handling for all major desktop operating systems. Alternative implementation can be done, but that requires some non-trivial amount of work. We’re open to that some time in future, but we have a lot of other work, which seems more important.
2. Using AWT simplifies the interop with Swing. Of course, Swing is not a very popular technology these days. But all JetBrains IDEs (and Android Studio) are using Swing, and we think it should be possible to use Compose/Desktop for Intellij plugin development.

[eygraber]

I was looking for the latter. Mostly just curious, thanks!