Support for multiple MainGUI + OE windows

[apocalyptech]

So, I'd like to refactor some stuff so that users can have multiple windows open, of both the MainGUI itself (so users can have more than one patchfile open at once), and for OE (most likely for when folks want to look at different games' data at once, though could be used for the same game as well). This also folds in my desire to be able to launch just OE.

It's a pretty tall order at the moment, so I'm not sure when/if I'll ever actually get to it, but some high-level thoughts about how it'd have to work:

1. We'd want the multiple windows to be open in a single Swing/AWT app, rather than having multiple copies of the app open at once. That way, we can share a DataManagerManager between them, and they'd share a common Options object, so there wouldn't be any weird overwriting, or trying to deal with multiple processes attempting to unpack the datapack database, etc.
2. A launch arg should be added to allow users to launch directly into OE without loading a mod. It might make sense to support some args to start OE with a specified game's data
3. We'll need some kind of IPC so that freshly-launched OpenBLCMM processes notice if there's already an OpenBLCMM process open, and handle things accordingly.

Various challenges/issues/details that I forsee:

• Will probably add something like a GUIManager class to keep tabs on all the MainGUI and OE windows that are open
• There are a lot of references in the code to MainGUI.INSTANCE, and at least some references to ObjectExplorer.INSTANCE. We'd need to start passing object instances around instead of relying on that, or in some cases call into the GUIManager class, if an operation needs to be done on all instances of MainGUI/OE
• OE will need a menu of its own, providing access to the settings, and the ability to launch a new MainGUI (and launching new OEs, as well)
• Settings dialog should probably be modal across the entire app, rather than just a single window (I don't think that's the case right now -- it's not a problem at the moment because only MainGUI can launch it, and there can only be one MainGUI, but it'll become a problem if we allow multiple windows). Perhaps use GUIManager to disable the Settings menu option in all other windows, once it's been opened in another?
• Should OE be able to drag tabs from one to another? Can it drag a tab "out" to create a whole new OE window? If we drag the last tab from one OE to another, should it auto-close that OE window, or create a new "start" tab?
• Figure out what to do with various CLI args in various circumstances
  • If someone launches an OE shortcut but there's already an OE window open, should it just raise the existing window, or create a new one?
  • If someone launches a MainGUI with a filename arg, should it open in a new window, or open in the existing window?
• I think we block the theme-switch dropdown when OE is open, because there were rendering issues when trying to update OE's theme dynamcally. Ideally we'd fix that issue instead of continuing that behavior.
• We'd need to figure out what to do with auto-backup files. Might make sense to start including the open-file name as part of the backup file name, though we'd want some more strict checking to make sure that we don't by chance try to write to the same file twice.
• We remember MainGUI/OE window statuses between runs. Will we just keep the parameters for the most-recently-active window?
• What to do with logging on newly-launched processes -- we'd presumably want to have some logging for that.
• "Uninstall" menu option might need some tweaking to account for multiple windows being open
• Recently-opened-files menu should probably get synced between MainGUI windows
• Opening object links from a MainGUI edit window: should it just go to the most recently open OE window? Or maybe if there are multiple OE windows, each with a different game selected, should it go to the one with the appropriate game? Or even default to opening a new OE window if the object is in a game which doesn't already have an OE window open?
• Font-size changes will require some validation and tweaks, though I think once I get that sorted out in general, it should probably be all right, since the font-size code already goes through and repaints everything necessary on the main window, if present.
  • Did we want to support allowing different windows to have different font sizes? That would entail a fair amount of extra work; right now everything just shares a common FontInfo object.
• We'd want to be able to drag-and-drop inbetween MainGUI windows freely

[TotallyABot1]

Some thoughts i have about this (no specific order):

• I'd like to suggest migrating the whole project to JavaFX. Its performance is way better than Swing and it has a lot better documentation. That would allow us to inslude the better JavaFX listener classes as well. Managing multiple windows / instances wouldn't be a problem either, but it would require a new dependency
• I'd also suggest to migrate the project to maven. That would allow the devs to actually manage dependencies and releases without much trouble.
• The current tests aren't that good maintained and / or useful. I'd vote for switching to JUnit and rebuilding the test suit from the ground up. That would allow the devs to actually validate the runtime logic and splitting the test data into useful and maintainable chunks while laso having a good test coverage without having to staticly mock everything
• I'd also like to create some kind of code base documentation. That should include stuff like core features (What is absolutely necessary for this software regarding features?), supporting features (WHich featurs are important since they're supporting the core mechanics?) and optional features (Which features could be ignroed or solved using simple methods?). This could also improve the expandability of the software for future features. And it should include features that are important but not yet implemented (multi-window for example).
• The code is kind of messy and needs some refactoring. I'd suggest to do that before attempting to change other stuff in the code base. Maybe create the architecture overview before that as well. The refactoring should inslude java doc as well (in my opinion)

I'll add more stuff if i find something :D