Hi all. This is a request for comments.
I thought it worth resurrecting a conversation Mungo and I started back in January about deciding what packages should have what code. For OSGi, we need to have clear separation between concrete GUI implementations, and core modules implementing the datamodel, IO, analysis, rendering, and view/model/controller functions.
Please have a look at the discussion below. Email comments/revisions to this thread, and I’ll integrate all into a master document as we develop our 3.0 vision. For now, its also worth reviewing code you’ve created to see how it fits with these guidelines…
I don’t know if you are online today, but if so could you remind me of the rules about what is, or in particular isn’t, allowed to go in the jbgui classes?
The rule with jbgui is that it should only include platform gui implementation code. No application GUI logic (although there are some exceptions which should be fixed re certain menus), and absolutely no controller/datamodel/view logic. There’s a much longer braindump below that I’d like to refine to some working rules for all of us.
But… read on first.
Reason: I have been refactoring the duplicated code in AppJmol and ChimeraViewFrame into GStructureViewer in my local branch. I suspect I may have overdone it, and need instead to create a common base class in the gui package.
nooo! The refactoring strategy here needs to be independent of the jbgui package.
As I see it, the parallels are that Chimera is a peer for viewing structure data mapped to sequences shaded according to current alignment view state and can take commands to create superpositions according to alignments. All these functions are GUI independent, but map to logical structureViewer operations so they should be in a non-gui controller package that implements a structureViewerModel API that Jalview’s GUI can employ.
Unlike Jmol and MView, Chimera doesn’t provide a rendering window, so the concrete GUI implementation for Chimera only serves as a proxy for the external chimera instance. Its geometry needs to be preserved on restore, but the way that chimera sessions are saved and restored is different to Jmol, so that functionality shouldn’t be shoehorned into the same inheritance model.
More generally, thre refactoring rule I’m following is to introduce a non-GUI dependent model wherever possible that is employed by a GUI class to maintain state, allowing multiple GUI implementations to employ the same core logic. This gets around Java’s lack of support for multiple inheritance, and to avoid lockin to particular Java platform APIs that may not always be available. jbgui classes are only necessary for concrete swing windows, and it only makes sense to inherit from the same jbgui class if the end products are different flavours of the same swing window.
Now, the braindump… which - as mentioned is a work in progress…
The basic rules I have been following are:
Refactor or implement data views and associated get/set/modify logic to concrete classes which implement interfaces defined in jalview.api. The first one of these was the Viewport.
Keep Desktop or applet specific model/state logic in gui and appletgui.
This bit needs to change [in order to create Jalview 3.0]. Originally, each one contained runtime/setup logic, actions to execute data analysis steps and construct new views from the results, and view state analysis code to make the GUI reflect current model state. What we ideally want is a full separation… so:
Refactor any control logic to classes in jalview.controller - should only import from non-gui packages.
Place any code dependent on both jalview and non-jalview APIs in ext.
Insulate GUI API dependent code (e.g. swing, awt, etc) from jalview by creating flyweight or wrapper classes implementing jalview interfaces. ** these are UI interfaces, not model interfaces - suggest these will live in a separate subpackage of the api **
Currently, the jalview2xml logic doesn’t follow the above at all. Ideally we should have a factory/GUI service interface which takes jalview view/datamodel objects, that is initialised at runtime according to jalview’s mode (e.g. running on swing, android, web, etc…).
For OSGi, I envision one or more Jalview executable modules that can be told which GUI implementation to use, and autodiscover any other available modules for runtime functionality (database accession sources, database search interfaces, file parsers, alignment and analysis methods, rendering systems) that are compatible with runtime configuration (e.g. sandboxed applet, full desktop application, headless commandline analysis engine, android app, etc).