I tested DockingFrames a few months ago… really great work.
Now I saw the cool “Swing Application Framework”, which make it really easy to create UI desktop applications with NetBeans (of course, with eclipse too, but there’s no mantisse for eclipse).
The thing the Swing Application Framework is missing, is docking frames like with any other RCP application.
My question now is: How to integrate DockingFrames with the Swing Application Framework (SAF)? As SAF persists setting like window position and size automatically, I think it’s not directly popssible to use this features with DockingFrames, right?
Such a framework will provide some way to include custom components, so I’m sure there will be some way to combine the two frameworks. But I really don’t know enough of SAF to give you a good answer.
Such a framework will provide some way to include custom components, so I’m sure there will be some way to combine the two frameworks. But I really don’t know enough of SAF to give you a good answer.
Custom components, yes. But what about the settings of such custom components?! For a JButton or so it doesn’t matter. This components doesn’t have setting that the user can modify. But the docking frames have positions, sizes and so on.
The SAF automatically provides persisting window sizes and positions and stuff like this. All I need is to integrate DF with SAF so that not only the parent JFrames settings are persisted, but also the current layout with position and size of each DF. Like in Eclipse RCP Applications: You open Eclipse as your Java IDE, and setup a „layout“: Package view left, editor in the middle, console on the bottom, outline on the right. If I close eclipse, and open again the workspace, the layout looks like before I closed it.
If it’s possible to combine DF with SAF, this would be a quite small and simple RCP solution, totally based on Swing (I know, netbeans has there something similiar to Eclipse RCP, but it’s big and overloaded (at least from my point of view)).
Session information seems to be stored by the SessionStorage. Each Application has an ApplicationContext, which then provides access to a SessionStorage-Object (as described in the API).
As I understand this: clients will have to choose a Component that is responsible for storing information about DF, let’s assume we take the main-frame for this. Probably one would write a subclass like:
private DockController controller = ...;
}```
... and then implement a new SessionStorage.Property, let's call it DockProperty, and register this DockProperty at "SessionStorage.putProperty" using "DockJFrame.class" as key.
The data will be encoded with XMLEncoder (something like an ObjectOutputStream). I think it would be a good idea to find out how to instruct the XMLEncoder to write the df-layout with the xml-format that is used by DF anyway.
(
Some more thoughts:
- One Component representing the whole DF-framework seems for me the easiest way: DF already has methods to store its layout in one sweep. Breaking this methods apart just so that every DockStation or Dockable can store its own layout/location would mean a lot of work.
- All the funny things like registering Dockables at the DockFrontend, registering Factories, etc... still needs to be done by the client.
)