Re: [Rails-devel] Swing Docking Framework for Rails

[Frederick W. <fre...@go...>]

Erik/Stefan:
based on your replies and my first experiences, I decided not to move
substantially further with the adoption of the docking framework.
There are several reasons for that:
- I've already achieved my main goal of being able to detach panels
from the OR window.
- Demand beyond this is currently not clearly existing.
- Any further adoption of the framework would be invasive and
longer-term oriented (not being part of master).

This decision means the following (already available in the repository):

(1) docking framework included into master - but disabled by default
       - option (within section "Window") for enabling dockable panels
of the OR Window
       - Anybody can evaluate the docking framework by activating
option (no patch/branch need)

(2) Only add a few key features in addition to the prototype
       - the button panel can be detached
            - e.g., I put it below the upgrade panel in my local layout
       - the OR Window layout is persisted / restored on a per-game basis
       - upgrade panel tiles are displayed in the same zoom step as in the map
            - This wasn't possible before as the upgrade panel's width
couldn't be adjusted

(3) Refrain from refactoring OR window's panels
       - supporting the configuration option renders such refactoring
too cumbersome

(4) Refrain from extending the scope of the docking framework to other
windows/panels for the time being
       - wait until there is the "pull" for more (based on others'
experiences / feedback)

> Erik:
> [Docking Framework] It would release ORPanel again from its chains, but what other problems would it solve?

Even for one monitor, I could perceive advantages of adopting the
docking framework: Each round could have its own perspective which
could be further configured by the user. Think of minimizing /
reducing the size of the stock market / chart for ORs and the
map/tracks during SR.

-- Frederick