About Editor Deprecation

[jojorabbit]

Hi, I just saw that a few months ago you announced that VisEditor will be no longer maintained. Is it ok if I make a fork of this repository or even new repository whatever is better for you? I don't want this project to die. I was thinking to maintain it as much as I can. I am still not 100% familiar with all code but I will get there in a month or so. My idea is to translate all code into kotlin and then just maintain the whole project in kotlin that is why I think new repository would be better so I don't modify anything related to VIS UI. Just let me know what you think and if everything is ok with you. I would still give you credit for it even if most of the code would be moved to kotlin.

Btw what are your plans with gdx-lml, autumn and other projects will you still maintain those? I can help here and there with features and maintenance.

Cheers.

[kotcrab]

Sorry for the delay. I think making a fork is simplest way and keeps visible reference to parent repo. After that you can remove ui, usl modules and modify build.gradle to use vis-ui from Maven repo instead of using module source code. Translating to Kotlin would be a good start. Depends on how much compatibility you would like to keep with previous version but it might be good idea to do some architecture refactoring while you have the chance.

Btw what are your plans with gdx-lml, autumn and other projects will you still maintain those? I can help here and there with features and maintenance.

Those are not mine projects, they are created by @czyzby. I think he still maintains them but now focusing on ktx.

[czyzby]

Btw what are your plans with gdx-lml, autumn and other projects will you still maintain those? I can help here and there with features and maintenance.

Those are not mine projects, they are created by @czyzby. I think he still maintains them but now focusing on ktx.

That is correct. I don't actively develop libraries from this repository: I usually fix bugs, implement feature requests (with sensible scopes) and upload the libraries after a new LibGDX version comes out. I don't mind if you want to help with maintenance, although I do have to warn you that today there are multiple things I would have done differently - writing units tests is an obvious one.

Anyway, if you're into Kotlin, I strongly suggest looking into KTX. It basically solves all the problems that Kiwi, LML and Autumn attempt to solve, without introducing annotation hell or a new non-Kotlin DSL you have to learn.

[jojorabbit]

@kotcrab Yeah I plan to change some architecture and refactor few things. But am more thinking move all code to kotlin then refactor and improve it with some new features or starting from scratch and using vis editor code as sort of reference. My idea was to use artemis entity as id instead of using Entity class. I would probably use gdx-lml for UI or Autumn but will see.

Few questions:

1. Do i still need to call it VisEditor or can i change name, package names etc..?
2. Can i use old icons or do i have to create new icons, because i was thinking to change some parts of UI one day?

@czyzby Yeah i saw ktx it is nice library i even wrote some kotlin extensions for libgdx that am using in my projects. Ok that is nice to know, i like lml and autumn just yeah too much annotations. No worries i will create forks for all your repos and see what i can do. Thanks.

[czyzby]

I would probably use gdx-lml for UI or Autumn but will see.

From personal experience, Autumn and LML injection annotations do not go well with Kotlin. I might be wrong, as I was just starting out with Kotlin when I tried to pair these. Still, there's just too much ceremony with lateinit or nullable fields. Plain LML could work - and the painless hot UI reload is nice - but I suggest against using Autumn.

It may be depressing to hear from the original author, but Autumn requires quite a bit of learning, especially if you have no experience with Spring or enterprise-style dependency injection. Learning LibGDX and Kotlin and LML and Autumn to make a pull request might be too much for most people. If you want others to contribute, I suggest keeping it simple and going with something that most developers interested in VisEditor already know: (almost) plain LibGDX. If you're keen on using Kotlin, KTX should be non-invasive enough for LibGDX devs to understand.

[jojorabbit]

Ok tnx for letting me know about kotlin and Autumn. Am almost 10 years in Java/JavaEE so am pretty familiar with dependency injections etc. I agree it should be as simple as possible that is why am in doubt for moving code to kotlin. But since Google announced kotlin will be main language for android am sure more ppl will learn kotlin. Am used to JavaFX and FXML your LML reminds me on it and it makes everything more clear but yeah again if anyone wants to contribute there is a lot to learn like you said, specially artemis-odb, libgdx, dependency injection etc. I think i will for now just make project and remove ui, usl, and add some features that i have ready locally, then i can slowly go and move it to kotlin. Any other suggestions, ideas? What do you think project is missing etc?

[kotcrab]

1. Do i still need to call it VisEditor or can i change name, package names etc..?

You can, changing name would be probably a good idea anyways.

2. Can i use old icons or do i have to create new icons, because i was thinking to change some parts of UI one day?

You can use old ones or create new, doesn't really matter.

But since Google announced kotlin will be main language for android am sure more ppl will learn kotlin.

IIRC it will be officially supported but they didn't say it's going to be main language. Still, I'd recommend converting code to Kotlin and using KTX.

[jojorabbit]

Thanks a lot for your answers.

[kotcrab]

Sure. Going to close this one.