Is there any support in the Core library for floating dockables? If there’s no direct support, what is the recommended way to float a dockable?
Also, what built-in dockable actions are there in the Core library? I only found out the maximize/restore button (which exist by default in any DefaultDockable) and the CloseAction. Actually, there isn’t much more to expect if floating is not supported, except maybe a minimize button that would replace the dockable with some button (like the taskbar in Windows).
The ScreenDockStation can put Dockables into JDialogs. Just create one and register it, after that any Dockable can be dragged out onto the screen.
The maximize/restore action only exists for children of the SplitDockStation, DefaultDockable does not have any default actions. And yes, there are no more actions because “core” handles “core”-stuff, and nice actions are an add, not a requirement for the framework.
More actions, like “minimize”, are in “Common”, but if you want to use them then you need to use “Common” everywhere. (Sorry, that is just how it is. Either you choose the “hardcore”-way or the “everything prepared”-way. Usually I suggest the second one, and to my knowledge you did not yet make anything that would conflict with “Common”).
P.S. you might want to have a look at the demo “help”, it uses only “core” but implements a “minimize”-action.
I tried ScreenDockStation. It does allow me to drag dockables out of the frame, but once I drag a dockable there, it’s gone… It doesn’t get a frame of its own.
Thanks, it’s working. Also, I’ve created a title button action for making a dockable float, and I added this button using “dockable.setActionOffers”. Can I make sure this action is only available when the dockable is not floating? I can’t find how to remove it once I float it.
If you use a DefaultDockableActionSource for setActionOffers, you could call “remove” to remove the action. Or calling “setActionOffers” with an empty ActionSource should work as well (hm, not tested that one).
Or you could use an ActionGuard instead of “setActionOffers”. That ActionGuard could check whether a Dockable is a child of a ScreenDockStation or not. This might even be a more general solution.
I use an action which drags the dockable from its SplitDockStation parent and drops it in a ScreenDockStation, which makes it float. Are the “floating” attributes customizable? E.g. if I want to move the floating window, I need to drag only the top area where the title is displayed. Dragging the top area outside the title has no effect. Also, the controller seems to have a preference for dropping inside the SplitDockStation when all I want it to move the dockable to some other place but keep it floating.
And finally, is there a way to make the floating windows show as ordinary application windows, let the OS set up the decorations etc?
Customization: Since a ScreenDockStation can’t do anything interesting, it has (almost) no cutsomizable properties.
Dragging the top area outside the title has no effect
The cursor should change its shape while it is over the border, that does not work? Or do I missunderstand you? Or do you want do disable that behavior?
Decorations: right now the only way would be to overridde the ScreenDockStations „createDialog“-method and reactivate the dialogs decorations.
Ok, this is not yet optimal. Maybe you should wait for version 1.0.7p3 before you try to change the behavior by yourself… (I’ll try to upload it before Monday, but without guarantee!) [Edit: this „createDialog“-method will be replaced by a factory-interface. A few different factories will be available, one of them allowing standard-decorations]
Always floating: Actually the controller preferes any station other than the ScreenDockStation. There is however a „DockRelocatorMode“ which switches the behavior. Hold down „shift“ while dragging a title, and the Dockable will always be „floating“ afterwards (The key-combination is customizable).
this „createDialog“-method will be replaced by a factory-interface. A few different factories will be available, one of them allowing standard-decorations
Currently the class ScreenDockDialog extends JDialog.
I changed that into „ScreenDockDialog extends JFrame“, because otherwise the ScreenDockDialog is always in front of the „main“ window.
Ok, I’ve written something. In preview 3 you can force the station to use a decorated JFrame. The code below has to be called before the first window is made:
DefaultScreenDockWindowFactory windowFactory = new DefaultScreenDockWindowFactory();
windowFactory.setUndecorated( false );
windowFactory.setKind( DefaultScreenDockWindowFactory.Kind.FRAME );
controller.getProperties().set( ScreenDockStation.WINDOW_FACTORY, windowFactory );
```
It is also possible to set a standard icon and text for the title of the frame.
Hm, I for me it would feel more natural that the close-button does the same as „normalize“, but right know neither is possible. Perhaps next week, a button that does not do anything annoys me…
(I’ll try to upload it before Monday, but without guarantee!) [Edit: this „createDialog“-method will be replaced by a factory-interface. A few different factories will be available, one of them allowing standard-decorations]