Hi, is there any tools that you know about (e.g a ...

# compose-desktop

[Francesco Pedron]

Hi, is there any tools that you know about (e.g a gradle plugin) that generates something similar to android's R.drawable from a compose desktop `main/resources`folder?
What I would like to achieve is to avoid referencing the image path as a string when using painterResource , but instead to get a class with all the resources paths generated at build time and get a build error if some resource is missing.

[ephemient]

I haven't used it but https://github.com/icerockdev/moko-resources supports desktop

[gildor]

Personally, knowing how much issues causes auto generation resources on Android, I wouldn't introduce it for other platforms and instead specify paths manually (maybe with some compile or static validation), it's a very convenient mechanism, but it introduces a lot of problem with which Android Tools team fighting for years starting from generation itself, requirements for complex tooling on IDE side, issues with incremental compilation, lack of visibility modifiers and so on and so on

None of them is blocker for a small project I believe, but if the project scales, it will probably bite you again and again

[Michael Paus]

@gildor I understand your gut feeling but do you really think it is easier to retrieve all resources manually in some way, e.g., on iOS or the Web, when you are away from the Java platform and don’t have a common mechanism to read resources anymore?

[gildor]

Web and iOS already doing this manually, right?

[Francesco Pedron]

@gildor a compile or static validation will be acceptable for me, what I need now is just to be sure no resource will be missing at runtime, will check moko-resources, thanks @ephemient.
Anyway one of the advantages of a complex tooling such as the Android one is that refactoring of resources names is supported on IDE and that's very handy in my experience.

[gildor]

Though, I didn't have this case personally, when I have to share resources on mpp environment on scale, I would probably just use expect/actual and implement it on every platform through native api (resources on Android, hardcoded paths on other platforms) to return requires resouces, yes, it's boilerplate, but I would take a bit of boilerplate instead of Android way to generate resources

Maybe some other resources generation approach, like separate dependency with all resources generates for every platform

[Francesco Pedron]

@ephemient should have mentioned that I'm on a JVM project and not on a multiplatform project, trying moko resources I found that it works on multiplatform only: https://github.com/icerockdev/moko-resources/issues/263