Replace setAlwaysOnTop completely

[anonymous]

Many dialogs (general messageboxes, but also dialog for editing ) in JOSM have set "always on top" on them. Unfortunately, with fluxbox on linux the "always on top" propagates to parent window too, making it imposible to alt-tab away (josm keeps on top, blocking other windows behind). Even if it would work as intended (only the dialog is always on top), this would still be very annoying when alt-tabbing frequently.

I suggest always on top should not be used at all, or be used only if the messagebox is shown together with relation editor, for which having always on top makes somewhat sense, though some implementation without always-on-top would be better.

[Gubaer]

In r1901 , I've introduced the preference window-handling.option-pane-always-on-to. Set it to false if you want to disable set-always-on-top on message dialogs. set-always-on-top is still used for other windows like relation editors and history browsers.

If window-handling.option-pane-always-on-to is false

• option pane dialogs
• extended dialogs

won't be always-on-top.

[Gubaer]

I'm changing it into an enhancement.

We should replace setAlwaysOnTop() for JOSM windows by some other mechanism.

• if not used consequently message dialogs get hidden behind other windows more often than not and JOSM appears to be blocked
• if used consequently the JOSM window itself becomes always-on-top on some OS / WMs which is annoying too
• it isn't allowed in an applet environment. Applet users will therefore have a lot of unmanaged JOSM windows

I don't know yet what a new approach could look like. Any ideas?

[Gubaer]

Ticket #3128 has been marked as a duplicate of this ticket.

[anonymous]

I think only other place where always-on-top is used is the relation editor and history browser - other used seem to be only to avoid the modal dialog ending "under" relation editor, resulting in "stuck" josm.

So any of these windows that need to be always on top by design could increment some global "ontop" window counter on creation and decrement on closing it. The other dialogs (messageboxes, editing properties ....) would then have always on top set if and only if that counter is nonzero.

For controls that could be always on top by design (relation editor, history browser), include some button inside the control to toggle alway on top on/off for it and remember its state even after dialog closes -> people who have more trouble (the behavior of JOSM and Java GUI in general is slightly different across platforms, for some this is not a problem, for some it is major nuisance) than good from always-on-top can turn it off easily.

While not perfect, may be good as a temporary solution.

[plaicy]

Additionally the order of the toFront-Calls should be changed.

For example in PropertiesDialog.java:

        dialog.toFront();
        dialog.setVisible(true);

But according to ​http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Window.html#toFront() "No action will take place if this Window is not visible." So first the window should be set visible and then toFront should be called.

I'll try to make a patch. But it must be checked twice because this is difficult to test.

[plaicy]

I debugged the code. After a setVisible the code is stopped. So a toFront() would not be called :-( I won't attach the patch. If you still interested write here or mail (add "(at)gmail.com" to username).

I will change may window manager to completely ignore setOnTop for JOSM. Then this will not be a problem directly to me.

[schuetzm@…]

I'd like to add that "always on top" should only ever affect other JOSM windows. In version 1917/KDE 3.5.9 it has the effect that for example the progress bar is always on top of all other windows, not only those belonging to JOSM, which is very annoying.

[pieren]

I would like to mention that this feature "always on top" is also strongly disturbing the cadastre-fr plugin which uses a JOptionPane between two http requests where a ProgressMonitor is also running. It worked fine until recently, the JOptionPane appearing on top of the ProgreeMonitor. I tried the "window-handling.option-pane-always-on-top" set to false but it didn't help.

[Gubaer]

Replying to pieren:

I would like to mention that this feature "always on top" is also strongly disturbing the cadastre-fr plugin which uses a JOptionPane between two http requests where a ProgressMonitor is also running. It worked fine until recently, the JOptionPane appearing on top of the ProgreeMonitor. I tried the "window-handling.option-pane-always-on-top" set to false but it didn't help.

In JOSM core JOptionPanel.showXYZ-methods were replaced by similar methods from OptionPaneUtil.showXYZ (in the JOSM GUI package). The difference is that the later will put the message dialog always on top, too. In your case above the progress monitor.
Please try to replace it in the cadastre-fr plugin as well.
The whole concept of using setAlwaysOnTop(..) for JOSM windows will nevertheless have to be thought over.

[vsandre]

I think the always on top of a all system windows should be a feature and not the default. On machines with a small display I use this to input new unknown OSM-Tags while watching them in the browser. It is very comfortable and I do not want to miss that.

[plaicy]

Ticket #3297 has been marked as a duplicate of this ticket.

[plaicy]

see also #2119

[Gubaer]

I've removed setAlwaysOnTop() from the JOSM code base in [1987].

Please check in your environments.

[Gubaer]

No further comments after the fix in r1987. Seems to be OK. Closing.