and why in the desktop-compose code there are so h...

# compose-desktop

[Michał Kalinowski]

and why in the desktop-compose code there are so heavy side-effects at initialisation in the main components (DesktopOwner, DesktopOwners, ComposeLayer) this looks a bit like a smell code

[Igor Demin]

so heavy side-effects at initialisation in the main components

This is the reason why the API is internal 😄.

[Michał Kalinowski]

Yeah, there are so many inner classes that I have to copy 50+ classes to extend something 😅, and since I spent 50h in this code this is the rest of the feedback:
1) The desktop compose code is clearly rushed, just to give features, instead of focusing on quality (which is really lacking there) and it is really hard to extend this code
2) Everything depends on the old swing, even the Dispatcher in coroutines, which makes it necessary to create a Looper and your own Dispatcher to even start thinging about an independent UI
3) Skiko code with Renderer is no better, it's weird as if someone wanted to integrate Skia with Swing at all costs(even if in Skiko nothing dependence from Swing).
4) Desktop Compose/Skiko at this point makes no sense in 99% of simulations and games because there is no backdoor for context initialization(a really basic thing) e.g. Vulkan context, which would enable integration with rendering engines that can use normal shaders or render e.g Ray Traycing

I hope that instead of adding features that have no foundation and will collapse, you guys will finally stop and think about solid foundations. Would love to see such future K

[olonho]

Michal, thanks for sharing your opinion, would be really awesome if not so strong terms were used, even if you do not like some of aspects of implementation, or believe that it could be done better.

[olonho]

Generally, all our components are OSS, and we accept contributions improving code quality or flexibility.

[Michał Kalinowski]

I didn't mean to offend anyone, I'm just sharing as a professional developer my opinion of 50h analysis of code how it works underneath.
And since the project is in beta, this is great time for feedback, and I think that criticism is better than compliments.

[Tijl]

I think it’s typically a pretty good decision to start with 1 narrow use case (Swing based in this case) and not immediately engineer additional abstractions, when there is no serious user base for it yet.

Extendibility should not be confused with quality.

[Michał Kalinowski]

yeah it doesn't make sense to give functionality to a few people, but it is worth taking care of possibility of extending the code in the future, at the moment Swing is so woven into everything that there is no separate common logic that can be used

[Michał Kalinowski]

and if quality is concerned, I gave the example of smell code in init{} blocks, there should be some factory instead 🙂

[Kirill Grouchnikov]

I personally find the integration with Swing pleasant, but I'm obviously biased as a Swing developer. Swing is there to fall back in case Compose for Desktop does not provide something. There needs to be something to fall back on in any case. Probably people who want to write games want to fall back on something else, like some sort of a object-based rendering pipeline. That wouldn't make much sense for people writing "enterprise" desktop applications, of course.

[Kirill Grouchnikov]

I'd also say that JB people are a bit biased towards Swing as that's what all their IDEs are written on top of. If a community effort rises to create a version of Compose that is built on top of a different "desktop-grade" rendering pipeline - something that, let's say, is oriented towards "game" rendering engines - that would give people another alternative.

[Tijl]

I sort of get what you mean, and with 50h looking I’m sure you have a better grasp on it than me what the current state is.

But it seems to me the while the touchpoints numerous, they are all sort of “logical”. It won’t be too hard to rewrite an abstraction layer into it since the swing API doesn’t bubble up to the higher layers.

You name tie-in of Skiko and Swing as a point, but clearly the path forward there to rendering into e.g. a Vulkan context is not very hard to imagine, and it won’t cause any major upheavals in Compose when implemented.

IMHO factory patterns for having multiple paths there only make sense when there is usage driving it. I know that’s a little bit of a chicken and egg situation, but to me a factory pattern for having multiple implementations with only one implementation present is also “smell”.

Swing itself is actually a good example for this. From the start it was designed to be “flexible” and it’s entirely possible to e.g. render the whole implementation into an OpenGL context of your own game, but it’s awful to use in practise. The abstraction are clearly written by someone that was not forced to use them in any meaningful way.

Compose will work out waaaay better, it already supports completely different input systems, and it uses abstractions for rendering that were battle tested before Compose existed.

[Michał Kalinowski]

@Tijl of course, desktop-compose has great potential, it is in the beta and I only pay attention to things that could be improved. And the factory is just an example since renderer should not be created as a side effect of the constructor 😅

[saket]

The desktop compose code is clearly rushed, just to give features

Love this comment on a framework that's in alpha right now.

... can implement what he wants to use himself?

he they

[Michał Kalinowski]

@saket I don't know what's so strange about it, but I think it's better to have a solid foundation from start than code that will have to be rewritten anyway.