Keep Transformation Command Windows on top

[tischi]

Hi @imagejan @ctrueden,

Do you now whether it is possible to keep a SciJava Command window on top?

I guess one would need to be able to get a handle on the frame?

---

chatGPT suggests something like this (I did not test it):

// Run on the event dispatch thread to ensure thread safety
            SwingUtilities.invokeLater(() -> {
                // Get all windows
                Window[] windows = Window.getWindows();

                // Iterate through the windows to find the specific command frame
                for (Window window : windows) {
                    if (window instanceof JFrame) {
                        JFrame frame = (JFrame) window;

                        // You can customize this condition to match your specific command window
                        if ("Your Command Window Title".equals(frame.getTitle())) {
                            // Set the frame to always be on top
                            frame.setAlwaysOnTop(true);
                            break;
                        }
                    }
                }
            });

[ctrueden]

How about, if instead of hacking around the limitation and making assumptions that Swing will always be the UI... if we instead add a new style attribute that sets the always-on-top flag in the framework? First idea: attrs = {@Attr("always-on-top")} on the @Plugin? Or a new empty interface AlwaysOnTop that, when implemented, signals this behavior is desired? Either way should work.

[tischi]

Good point.

I am wondering whether that is a feature that's mainly interesting for Commands that implements Interactive (at least that's my use-case). Maybe implements Interactive could be enough to make it always be "always-on-top"? Or do you think that should be configurable, e.g. by means of an additional AlwaysOnTop interface?

[ctrueden]

I like the idea of adding default boolean isAlwaysOnTop() { return false; } to the Interactive interface, and then checking that method when constructing the dialog to configure it accordingly. Do you think it would work?

[tischi]

...I am not sure I get how one would use this: Where and when would one be able to call setAlwaysOnTop( boolean isAlwaysOnTop }?

[imagejan]

I guess Curtis suggests that in your own implementation MyCommand implements Interactive, you'd override:

public boolean isAlwaysOnTop() { return true; }

public void run() {
...
}

and if SwingDialog and SwingInputHarvester are modified accordingly, they could check if the provided Module implements Interactive and then (possibly with a new constructor for SwingDialog) call:

boolean alwaysOnTop = (module instanceof Interactive) && ((Interactive) module).isAlwaysOnTop() ? true : false;
final SwingDialog dialog =
			new SwingDialog(pane, optionType, messageType, doScrollBars, alwaysOnTop);

The changes would possibly have to go here:

https://github.com/scijava/scijava-ui-swing/blob/2770bbfbd67cf9f1fe3f1b7968cf4b0241587ea4/src/main/java/org/scijava/ui/swing/widget/SwingInputHarvester.java#L64-L90

and here:

https://github.com/scijava/scijava-ui-swing/blob/2770bbfbd67cf9f1fe3f1b7968cf4b0241587ea4/src/main/java/org/scijava/ui/swing/SwingDialog.java#L69

[tischi]

I see, that makes sense! I did not think about the possibility to override the method!

OK, shall we go for it? Shall I try it out and then do the PRs?