On Fri, 24 Jan 2014 20:08:09 +0100 "Stian Grenborgen" <[email protected]> wrote: > Another problem with using JDialog is that they don't mix well with > JInternalFrame. Layering, focus etc is handled by the windowing system for > the former, while JDesktopPane handles it for the latter. That's why the > ChooseFoundingFatherDialog is always in front of the Colopedia help panel > you get when clicking the "help" button, for example.
True, but this is new code, and there is a routine in place to try to place both dialogs and frames such as to avoid overlap. I do not know why it is not working in this case, but this looks like a mere bug, not a fundamental showstopper. Now I cheerfully concede not really understanding Swing et al. What I do understand is FreeCol bug reports. Here is the justification for the JDialogs: - Some dialogs in FreeCol need to be modal, some need to be non-modal. - We had a trick for non-modal dialogs the centered around reimplementing an event loop handler inside FreeColDialog.getResponse. This was very clever, but outdated (did we really want to track the Java event loop code? no one had ever bothered) and brittle --- for unknown reasons it was occasionally possible to get stuck in the getResponse handler, and as such caused at least six, and possibly as high as twelve serious FreeCol bugs (we will never know, it was a client-side effect and did not reproduce easily, so several reports are suggestive but frustratingly inconclusive). - When a getResponse bug hit, there was nothing you could do but kill freecol and restart from the previous save. That is serious. - JDialog is a standard way to provide a modal or non-modal dialog. I consider that a strong case for killing getResponse. Even if it were true that JDialogs are causing windowing misbehaviour, that is nowhere near a game-killer bug. > Considering the other problems with dialogs appearing behind each other: > It should be possible just to grab the panel that is blocking the other, > and click on the panel behind. Unless you are clicking on a component (or > there are additional JPanels intercepting the mouse click), this should > make the panel you click appear in front. Isn't this working? In every case of overlap I have seen, yes, grabbing and moving either panel fixes the problem. Annoying, probably worth a bug report, but not a showstopper. The bad breakage is when panels or dialogs appear *behind the map*. That one is baffling. I do not understand how a JInternalFrame can do that, and all JDialogs should be getting a focus request when first brought up. Cheers, Mike Pope
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________ Freecol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freecol-developers
