Page MenuHome

UI: Let the OS treat the file browser as proper dialog window
ClosedPublic

Authored by Julian Eisel (Severin) on Sep 16 2019, 12:05 PM.
Tags
None
Subscribers
None
Tokens
"Love" token, awarded by billreynish."Love" token, awarded by Scaredyfish."Party Time" token, awarded by manitwo.

Details

Summary

Makes the file browser window behave as follows:

  • Always on top of its parent Blender window, but not on top of non-Blender windows.
  • Minimize with its parent window
  • Can be moved independently
  • Doesn't add an own item in task bars
  • Doesn't block other Blender windows (we may want to have this though)
  • Open as floating window for tiling window managers (e.g. i3wm/Sway)

As this introduces a new kind of temporary window we have to take care
they don't conflict with each other. E.g. a Preferences window should not
become a dialog file browser window, and vice versa. I made it so that a
new window is opened if we try to open a dialog in a regular temporary
window, or the other way around.
This has the nice side effect that the file browser doesn't steal the
preferences window anymore, which was planned to be fixed anyway (see
T69652)

There are some differences between Windows and Linux (can't tell for
macOS), I'd like to have them as similar as possible though. Some more
things to note:

  • Temporary windows don't stay on top of all Blender windows, only on top of its parent window (the one it was created in).
  • When opening a file browser from the Preference window (or any temporary window), the main window, as the file browsers parent is moved on top of the Preferences, which makes it seem like it was closed. This is the general issue of bad secondary window handling as window activation changes. I made it so that the window is moved back once the file browser is closed.
  • On Linux the temporary windows don't allow minimizing and maximizing. GTK and Qt have the same issue (if we consider it one).
  • I disabled minimizing on Windows, otherwise minimizing does this:
  • I left in some code for embedded child windows, but we don't use it (was for game engine). I'd suggest getting rid of it first (GHOST_TEmbedderWindowID).

Not sure how ready the macOS implementation is (or if it works at all).

Diff Detail

Repository
rB Blender
Branch
master
Build Status
Buildable 4970
Build 4970: arc lint + arc unit

Event Timeline

Temporary windows don't stay on top of all Blender windows, only on top of its parent window (the one it was created in).

That's fine.

On Linux the temporary windows don't allow minimizing and maximizing. GTK and Qt have the same issue (if we consider it one).

This seems like a problem for the render window, you want to be able to minimize that.

I didn't find a way to disable minimizing and maximizing popup windows on Windows. Minimizing behaves a bit weird in that it minimizes within the main window.

Overlapping the status bar that way is problematic, is there no other solution? Is popup window the right window type for cases other than the file browser?

The way we should think about this, IMO, is that some windows are temporary or blocking windows and others are just secondary or child windows. Here are the three types of windows and what, in my estimation, they each should allow:

window typeexamplesoverlaps parent windowallows input to other windowsallows minimizingappears in taskbar
Main windowsThe main Blender windowNoYesYesYes
Temporary/blocking windowsFile BrowserYesNoNoNo
Secondary/child windowsPrefs, Render, Info, Drivers, user windowsYesYesYesNo

Rewrite patch to make file browser window be a proper dialog window for the OS

Julian Eisel (Severin) retitled this revision from Ghost: Make temporary windows on-top popup windows to UI: Let the OS treat the file browser as proper dialog window.Sep 27 2019, 4:20 PM
Julian Eisel (Severin) edited the summary of this revision. (Show Details)
Julian Eisel (Severin) edited the summary of this revision. (Show Details)Sep 27 2019, 4:23 PM
Julian Eisel (Severin) edited the summary of this revision. (Show Details)
William Reynish (billreynish) requested changes to this revision.EditedSep 27 2019, 5:22 PM

Tested this on macOS. This comment only refers to the macOS behavior.

On Mac, it works like this:

This patch makes it so the File Browser is on top, which is good, and the Preferences and File Browser can now be opened separately. (Although Preferences still isn't displayed on top)

However, the issue is that it is permanently on top of *all* windows in the Mac OS. This makes it impossible to switch to another Mac app while the Blender File Browser is open.

IMO, that isn't going to be acceptable, since that is a very common thing to do on macOS.

This revision now requires changes to proceed.Sep 27 2019, 5:22 PM

@William Reynish (billreynish) did you test the latest version? The macOS implementation does not build and seems incomplete, so I guess you tried an older one.

I'll get the latest one working.

Make macOS implementation work, only stay on top within the Blender application. What this doesn't do (yet?) is ignore mouse events into the main window, even the dialog window always stays active.

Also simplify code, seems simpler not that have separate dialog window method if it ends up calling the same unified one.

The macOS version seems to work now. It always stays on top, and also the window also moves with the parent. Is this on purpose? I guess it might be nice thing, and makes it behave a little bit like a sheet, which is interesting.

As @Brecht Van Lommel (brecht) points out, probably it should block mouse input also. Not sure if we should require that for 2.81 or not.

Tested on x11 with various window managers, worked well on all,
WM changes seem fine too.

Accepting now, we can always block mouse input in the main window later if needed.

This revision is now accepted and ready to land.Oct 3 2019, 2:55 PM

I think this is ok to commit for macOS and Linux, did not test Windows.

It always stays on top, and also the window also moves with the parent. Is this on purpose? I guess it might be nice thing, and makes it behave a little bit like a sheet, which is interesting.

The ordering works by making the dialog a child window, which has the side effect of moving along with the parent window. I think it's ok, you're not that like to move the parent window and if you do move it e.g. to a second monitor, it makes sense for the dialog to move along.

As @Brecht Van Lommel (brecht) points out, probably it should block mouse input also. Not sure if we should require that for 2.81 or not.

I think it should block, but would not consider it a blocker to get this committed. It can still be fixed for 2.81. The same issue exists on Linux too.

For blocking mouse input to other windows, we could do this in windowmanager by ignoring the events there.

I'm not entirely sure if that's the best solution, there may be issues with missed release events for modifiers keys etc, but the same issue might exist at the GHOST level anyway.