JavaFX Pivot - Next Steps - Cursed Zip

[DanVanAtta]

I had a long conversation with @RoiEXLab today about JavaFX. I'm opening this issue to communicate our tentative consensus and communicate our plans and thinking.

In short, we're zipping up the current JavaFX code into a 'cursed zip' and will pick up JavaFX at a later date.

What is our current plan?

• with javaFX code zipped up, remove JavaFX from current codebase
• do what we can in swing (current UI) to get a better UI (background images, nicer buttons),
• redesign the UI flow and implement with the current Swing code, changing it in-place
• (heavy lift / long effort) work on the backend to split UI code from core logic. This will generally involve cleaning and improving the backend. As part of all of this the UI code should become quite separated and would be much more obvious how to replace it without rewriting the staging screen logic. As an example of what this would involve:
  • we'd like to clean up all APIs from the staging screen that interact with the backend
  • replace the staging screen network technology with websocket and create a clean network interface
  • work on server launching code to split it from the client code.
• revisit introducing JavaFX once the front-end is more decoupled from the backend logic

Why did we come to this tentative decision?

First, the evidence of history is not with us on this one. If this project were going well, it was started three years ago, we would have seen much greater momentum. The technology is not necessarily the problem, it's more that it's too much at once in a legacy code base that is not ready for it.

Second, a parallel rewrite is always a tall order. If we had a clean backend, we could swap out UI components quite readily. Instead we are re-working and rewriting code that needs to work with existing code while also trying to build out new UIs. This is just a lot to do at once. The constraints of the existing code prevent us from doing the rewrites we would really want or need, making this just an extremely difficult task.

Third, it's a lot of technology to introduce at once and we need to be sure we get it right on which ones we actually use and how. JavaFX has introduced three new technologies: FXML, CSS, and the core JavaFX components. We need to evaluate if and how we would want to use CSS, if we want to use FXML and/or go with object code instead. We should come to a very informed perspective before fully committing to a new technology set. To get there, we need some liberty to try the different options and ideally not redoing the UI while fighting with the existing legacy code while in the process.

Fourth, it's just too much all at once. New technology, backend rewrite to decouple UI code while keeping existing code working, and updating the UI navigation. If we can get the backend cleaned up and rewritten, the UI updated and re-navigated, then technology swapping will be a much cleaner and more feasible task.

Where will the javafx code be stored?

Two places: 1) as a zip attached to this issue: game-headed-javafx.zip, 2) as a zip uploaded to our assets repo: https://github.com/triplea-game/assets/blob/master/javafx/game-headed-javafx.zip

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If there is something that can be done to resolve this issue, please add a comment indicating what that would be and this issue will be re-opened. If there are multiple items that can be completed independently, we encourage you to use the "reference in new issue" option next to any outstanding comment so that we may divide and conquer.

[louhy]

Hello - big JavaFX geek here - just wondering what the status of the view/logic decoupling is. (Also I would advise a yes to both CSS and FXML, they're a huge help.)

[RoiEXLab]

@louhy Unfortunately the code is still tied to the logic to a large degree. There has been some progress from my side to clearly separate ui-based launching code from headless launching code but it is far from being perfect. There are just too many circular references to UI, i.e. code that directly calls and then waits for the UI to call it back somewhere else. It should be relatively "easy" to abstract away the swing specific code behind an implementation of an interface. Create a list of every call to swing specific code, and turn it into multiple generic interfaces (for example GenericDialog, GenericPopup, Generic whatever) and then make each implementation delegate to the actual swing calls. Once you're at that point you should be able to create another implementation using JavaFX and ideally you can swap one for the other without issues. It probably will be far more complicated than I just described and while this strategy will probably eventually reach its goal it will most likely cause a lot a headaches to try to squeeze the JavaFX API into a swing based interface and this will most likely result in a lot of duplication when 2 UI frameworks are trying to do mostly the same thing. In an ideal world this would be a desirable solution, but this will be an infeasible amount of work in practice.

What is realistic in my opinion?

As I already mentioned the game launching code is somewhat decent + there's not a lot of it. I don't know how skillful you'd consider yourself building UIs in java. But if you have a lot of time to spare and think this could be a fun project for you I'd highly encourage you to start there. Once you did your experiments and are able to show us a concept of a nice looking new launcher that matches the functionality of the current one we can reconsider introducing JavaFX if you can convince us that this project won't be a dead end. This project has the benefit that I wouldn't hesitate to drop the swing code for the current launcher. It is a complete mess right now. So if your code is built in a way that treats the UI just as some generic mandatory component that would be a huge buff to the architecture! If you have any questions feel free to reach out. We'd be happy to help you helping us.

[louhy]

Oh learning curve is no worry, I've used JavaFX for many years and Java.. well, a lot longer. lol Yeah obviously this would be a big project. But maybe worth taking up if the team here is still open to it, which is something I was curious about. I should probably finish up a project (JavaFX also) I'm currently working on first so that might take some time, but when I realized this was a Java code base and spotted the Swing UI I thought "JavaFX could make this a lot nicer".

I might start with a few minor pull requests here and there in the mean time though. I've already done a local code tweak here to allow a 150% map zoom level (not sure if that would be useful to others or not) so who knows, maybe I'll try a few smaller pull requests first.

[RoiEXLab]

@louhy Feel free to experiment. We're all volunteers here and doing it mainly for fun. However for large code changes that directly affect gameplay I'd recommend discussing the topic first before putting in a lot of work into something that is disliked by the Playerbase or does clash with our design philosophy or something

[louhy]

Yep, I'll put up an issue first if anything strikes me as worthwhile.