I do not think this post is going to get any responses but I had some questions about floating windows.
Just wondering if there is any interest in the topic.
I would also be interested in hearing other users opinions/experiences.
The main two windows I will use as examples are
-Virtual Keyboard
-Nightly Demo Time Limit Nag Screen
Both of these windows are programmed to be “Always On Top”
The issue I have with this is that it is not just “Always On Top” within Ardour itself, but for your systems window manager.
This means that even when Ardour is not currently the window in focus, these AOT windows end up appearing on top of your other programs windows.
Virtual Keyboard
This tool can be helpful to provide a visual keyboard GUI on your screen.
Ardour does not allow this keyboard to be docked in bottom dock (I have a suggestion post I plan on making in the future for this)
But even still if user wanted to use this as a floating window.
If you snap this window to the bottom of Ardour / screen and then open a different applications window, this Ardour keyboard window is now on top of that applications window, which is not desired.
Nightly Demo Time Limit Dialog
This AOT window can be even worse.
For a while now I have been trying to “help” test out the Ardour official nightly builds for bugs/feature requests.
In doing so, if I encounter a bug for example, I open a text editor so I can create a post or notes about this issue.
When working on something in a separate window, such as a text editor, it can be an issue to have a dialog from a different program (Ardour) popup on top the current window being used.
For example if you should happen to by typing and you hit ENTER or SPACEBAR key and this dialog appears, it opens with focus on the button to launch your web browser application window.
I understand the purpose of this dialog but if users are trying to help test out this application, this can cause many issues.
Just because I know some will make comments about this. I am aware of the “Remain Silent” button.
-Sometimes issues can be audio related which means would still require audio.
-This popup would still be dealt with at least once.
To me it seems like these windows should only be “Always On Top” within Ardour itself, not all other application windows on your system.
Basically requesting that these windows be made to function similar to how plugin windows currently behave.
I was just wondering if either of these issues would be considered to be improved upon?
Also I would be interested if any other users experience AOT window issues like these, or with any other windows within Ardour.
This is a limitation of the X11 window manager model.
On macOS, you can create layer groups that are associated with an application, and then say “put this window on the top of the application layer group”. When the application loses focus, the window manager does just what you’re asking for.
No such concept exists across all X11 window managers, nor on Windows. Any attempt to do so would be a hack that targets particular window managers and/or weaknesses in the window manager API.
Hey Paul, thank you for your response.
Yeah but these floating windows are generated by Ardour, so why would they not be able to stay within Ardour?
Plugin GUI windows
Preferences window (I think)
Plugin Selector window (I think)
Plugin Manager window (I think)
Session Saving dialogs
Closing dialogs (Are you sure you want to quit)
etc.
All of these seem able to be “embedded” within Ardour and can remain “Always On Top” generally speaking.
Are the “Virtual Keyboard” and Nightly Demo Time Limit dialogs somehow different then these other windows mentioned above?
You do not have to respond, but I am not sure that I follow based on question I mentioned.
I will just use “Plugin GUI” windows as example.
If Ardour can already create an embedded window for Plugin GUIs, and this Plugin GUI window can be made to appear “Always On Top” within Ardour only, as it does currently
Couldn’t the same settings be used for Ardour virtual keyboard window?
Same for the Nightly Time Limit dialog?
Couldn’t its floating window get the same behavior used in the Plugin GUI window, or other dialogs such as how the “Save session” input field dialog remains on top but within Ardour.
Or again as I asked above, are the two floating windows I mentioned, different “types” of windows compared to the list of windows I mention.
We could take the same approach as we do with plugin GUIs, sure - explicitly hide them all when the application loses focus (*). We haven’t done that because we don’t really anticipate that the user may have multiple instances of those sorts of windows open at the same time, whereas we do expect many users to have N different plugin GUI’s visible at once.
As has been typical with many of your recent suggestions, it’s not a bad idea, just not particularly high priority.
(*) this is what macOS does for us automatically (and all other apps)
I’m sure you are correct that this type of application development is possible. I’m also sure that any careful study of Ardour on the Mac reveals that these possibilities are not implemented. Modal windows from Ardour over the top of other apps do exist, as do inconsistencies of Ardour’s own various windows in Ardour’s own stack.
Not complaining, just repeating things that often get (unsuccessfully) hashed out over on the MixBus forum.
Modal windows are a different beast entirely, on macOS as on other platforms. There is never any reason why a plugin GUI should ever be modal with respect to the rest of the GUI; other dialogs … less clear, and one could reasonably argue for both outcomes (modal or non-modal).
Making a window modal is saying “the user cannot interact with this app until the interaction with this dialog is complete”. It would make no sense for the window manager, upon taking focus from that app, to hide the window. OK, I take it back … not no sense, but limited … and macOS makes the choice that it doesn’t make sense (even if you and I can both see an argument for choosing the other way around).
A most simple (among many many) example on my Mac…
I’m working in Ardour, and switch to Safari to consult part of the Ardour user guide. Ardour, as expected, now sits behind Safari. Unexpected, however is that I can’t see Safari because my Ardour meter bridge is on top, and it has lots of tracks. Ardour’s team could have chosen to craft the meter bridge window in a way so it does not stay on top. Ardour’s team did not.
Like you say, choices, and perhaps arguments exist for all options. Personally, when Safari is brought to the foreground, it really really should be in the foreground. Just my opinion.
the dilemma here is, as I mentioned above: macOS’s layering model is completely different, and much more powerful, than the one found on Linux and Windows. since we use a cross-platform GUI toolkit, making things work “right” in both kinds of layering systems is really quite challenging. we could probably make the layering of the meter bridge work the way you want on macOS, and then discover that this changes how it ought to work on other platforms. and, obviously, vice versa.
it’s a difficult technical challenge, given our resource limitations and general tendency to try to avoid incredibly platform-specific code as much as possible.
[Edit…] Sorry, I’ve changed this from my original post…
On Windows, not all AOT windows affect other apps. For example the Big Clock window is AOT but it allows the user to interact with with background windows (i.e. it’s AOT but non-modal). System->Properties is also AOT and non-modal. But the Big Clock blocks non-Ardour apps (i.e. it stays on top of them) whereas the Properties window doesn’t.
adjust Ardour’s own code to hide dialogs/windows when it loses kbd focus, no matter what windows are visible. This would be done explicitly using Gtk::Window::hide()
think about how to do things at the GDK/GTK level, which is tricky because the real problem is that the abstractions possible on Linux and Windows are more limited. You cannot put windows into a layer group, which is the key concept in the macOS world. GDK/GTK has already made an effort to come up with a “least common denominator” across these platforms, and it is clear that this isn’t enough by itself to create “platform native” behavior at all times.
Presumably you only mean child windows? But wouldn’t that create a situation where AOT windows can’t be always on top any more? Or maybe you mean hiding child windows when there’s no other Ardour window with the kbd focus?
