GPX-Animator Modularization

[McPringle]

I wouldlike to create a GitHub organization called "gpd-animator" and move the repository over. Then I would like to divide the code into smaller modules:

• gpx-animator-core with the all the core and animation stuff
• gpx-animator-cli with the command line client interface
• gpx-animator-ui with the graphical interface

For the end user nothing should change. The core is used as a library in the ui project. Positive effect: The cli project produces a cli application without all the graphical stuff. Together with GraalVM the cli project can create very small and fast native cli applications which can be automatically published to e.g. linux repositories for easy installation.

The animation and rendering code is seperated from the UI code and can't be mixed. In the future, plugins can be created with the ability to enhance the functionality without resulting in a bloated and heavy monolith.

We both will have full access. What do you think, @zdila?

[zdila]

Actually I think it would be wasting of resources. GPX Animator is not that huge app that would benefit from splitting it to smaller bundles. Nobody complained that he only uses GUI and he wants to remove CLI or otherwise.

[thomergil]

While I think it's a noble goal, @McPringle, I agree with @zdila it's likely not worth the effort. I second his reasoning. I modestly suggest closing this issue.

[McPringle]

In the meantime, I have adjusted my opinion a bit. I am still in favor of modularization, but not on GitHub in different projects. Instead, I have in mind a simple modularization via "module-info.java" files within the source code. It's very easy to implement and the separation prevents too much tangling between the frontend and backend.

Together with a UX designer, I am in the process of revising the user interface. I have received feedback that some users are overwhelmed by the current interface and are " knocked out" by the number of options. So our idea is to call the current UI with all options the "Expert UI" and complement it with a simpler UI with the most used features. To prevent too tight a binding between UI and the actual functionality, I want to separate the code module-wise. With the modules available since Java 9, this can be achieved very easily within the same source code.

[thomergil]

@McPringle improving the UI sounds like a good idea! (Though I'd argue that's a separate issue, and not related to modularization, which I still think is a waste of time for such a small project.) I certainly was overwhelmed in the beginning which initially caused me to give up on GPX Animator, believing it was unusable. In particular, I very much dislike the interface to modify durations, where hours, minutes, seconds, and milliseconds need to be individually set, and they do not respond to keyboard input correctly. It is also unclear which options interact with each other and which options are mutually exclusive.

I think the user interface should only ask for an input file and have all other options set to reasonable defaults, much like the command-line interface where you can run with just the --input parameter set. New users should be able to try out the simplest possible thing and be reassured that it works.

[poorlymac]

I too am interested in this as I would like to bundle just a CLI build into an larger OSX Swift App and call it. However that will require the user to have Java, which many won't, so I am investigating GraalVM but it fails with:

Warning: Dynamic proxy method java.lang.reflect.Proxy.newProxyInstance invoked at org.glassfish.jaxb.runtime.v2.model.annotation.LocatableAnnotation.create(LocatableAnnotation.java:53) Warning: Aborting stand-alone image build due to dynamic proxy use without configuration.

Note also the application will also have its own static build of ffmpeg, so that could be reused. Would a gradle build of only the CLI be possible ?

[McPringle]

Theoretically, that should be possible. But I would limit this issue to introducing modularization only. Because it might need more work to split the build into several parts. Same for having more flexibility regarding the reuse of existing ffmpeg libraries on the client. That could become complex because certain features of GPX Animator need at least a minimum version of ffmpeg.