KTX tools module

[czyzby]

An equivalent to gdx-tools that could automate some KTX-related operations. Potential candidates:

• Conversion of .properties files to type-safe i18n enums from ktx-i18n.
• Conversion of skin .json definition to type-safe builders from ktx-style.
• Generating type-safe ktx-style builders from an existing Skin instance.
• Extraction of texture region names from .atlas files, which could be saved as a type-safe enum. Useful for both ktx-style builders and general TextureAtlas usage.

Could be implemented as standalone library or Gradle plugin. Or both. The first approach seems the most flexible.

@kotcrab

[kotcrab]

Sure, why not. :+1:

[sreich]

fyi so there's no duplication, consider me working on the "Extraction of texture region names from .atlas files, which could be saved as a type-safe enum. ".

i'm currently waiting on someone else's very recent work, for me to generate the code..i'll see what i can whip up for my own project soon here, and go from there. it should be able to generate type-safe enums from all asset types (fonts/images/atlas etc). i'm sick of plain strings :)

[czyzby]

That's great! I'll create a separate branch and setup Gradle submodule for you.

[czyzby]

There. Try checking out feature/ktx-tools branch.

[sreich]

think i'm running into an issue with the gradle scripts for ktx (in general, unrelated to ktx-tools).

resources aren't getting stored in the jar..i'm thinking this is because the top-level one ends up overriding the default behavior (gradle defaults to copy the resources as expected).

you can try adding a src/main/resources/blah.txt to any of the submodules and see it not get copied. looks like the resourceDirs get wiped somehow?

[czyzby]

@sreich How are you building the jar? I added src/main/resources folder in one of the modules, put a text file there and it was present in the generated jar when using gradle build command. Maybe this is specific to Gradle plugin jars - have you checked if they are allowed to have classpath resources? I don't see a reason why they wouldn't, but still.

[sreich]

guess it's been a long day, silly mistake...i was putting them into src/resources, and since the resource is how gradle finds the plugin in the first place..that is why it couldn't find it. now the plugin works great. so i'll continue working on it and the generator. thanks for your patience :wink:

[czyzby]

It's OK. Might I ask why do you need classpath resources in the plugin in the first place?

[sreich]

from my understanding of gradle, it is required for the plugin to get picked up by gradle (the implementation-class). that's the only resource i will have

https://docs.gradle.org/current/userguide/custom_plugins.html#sec:custom_plugins_standalone_project

[czyzby]

Oh, I see. I completely forgot about the meta-data thing. Carry on.

[DavidPartouche]

@czyzby I would be happy to help with that task. The feature/ktx-tools branch is quite behind develop now, is it still the branch that should be used?

[czyzby]

@DavidPartouche Feel free to fork the current develop branch. You can check the last 2 commits on the feature/ktx-tools branch if you need any help with adding a new Gradle module. Also, you might want to look into @sreich fork here. I have to admit I didn't go through his code (he never made a PR), but it might still prove useful. Thanks.

[dwursteisen]

Could be implemented as standalone library or Gradle plugin. Or both. The first approach seems the most flexible.

You can do a standalone library that can be invoked from a gradle plugin. Best of two worlds!

Conversion of .properties files to type-safe i18n enums from ktx-i18n

For your info, I'm doing this kind of things (it's more a PoC actually): generating an object with all filenames as fields. So I don't have any filename in my code. So If I'm renaming an accept, the error will occur at the compile time and not the runtime.

https://github.com/dwursteisen/libgdx-addons/blob/master/assets-gradle-plugin/src/main/kotlin/com/github/dwursteisen/libgdx/assets/AssetsTask.kt