OpenBLCMM
OpenBLCMM copied to clipboard
Support for multiple MainGUI + OE windows
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:
- 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 commonOptions
object, so there wouldn't be any weird overwriting, or trying to deal with multiple processes attempting to unpack the datapack database, etc. - 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
- 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 toObjectExplorer.INSTANCE
. We'd need to start passing object instances around instead of relying on that, or in some cases call into theGUIManager
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.
- 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
- We'd want to be able to drag-and-drop inbetween MainGUI windows freely