-
Enhancement
-
Resolution: Unresolved
-
P3
-
9
-
generic
-
generic
When a window is made visible on the screen - XWindowPeer.xSetVisible(true), such a window is automatically fronted (it calls XlibWrapper.XMapRaised()).
IssueJDK-6187066 introduced a possibility of not gaining focus for opened windows. That's good. However, it looks sort of silly to have an application that fronts it's windows, but does not give them focus. Thus I'd expect that when gaining focus is not desired, it's also not desired to front windows.
Currently, when we open a dialog from an existing frame, both frame and the dialog are pushed to the front, which might not be desired. To fix that, I suggest to introduce methods like isAutoFront() and setAutoFront() in java.awt.Window and appropriate peers, that could be used together with existing isAutoRequestFocus() and setAutoRequestFocus().
I suppose that in xSetVisible() there could be then:
if (isAutoFront()) {
XlibWrapper.XMapRaised(XToolkit.getDisplay(), getWindow());
} else {
XlibWrapper.XMapWindow(XToolkit.getDisplay(), getWindow());
}
Another option is to overload functionality of isAutoRequestFocus() and raise windows when and only when the focus is requested.
Issue
Currently, when we open a dialog from an existing frame, both frame and the dialog are pushed to the front, which might not be desired. To fix that, I suggest to introduce methods like isAutoFront() and setAutoFront() in java.awt.Window and appropriate peers, that could be used together with existing isAutoRequestFocus() and setAutoRequestFocus().
I suppose that in xSetVisible() there could be then:
if (isAutoFront()) {
XlibWrapper.XMapRaised(XToolkit.getDisplay(), getWindow());
} else {
XlibWrapper.XMapWindow(XToolkit.getDisplay(), getWindow());
}
Another option is to overload functionality of isAutoRequestFocus() and raise windows when and only when the focus is requested.