UI: Tear-Off Windows as Children On Top
AbandonedPublic
Actions

Authored by Harley Acheson (harley) on Dec 1 2019, 7:52 PM.

Details

Reviewers

Campbell Barton (campbellbarton)
Julian Eisel (Severin)
Ray Molenkamp (LazyDodo)
Brecht Van Lommel (brecht)
William Reynish (billreynish)

Summary

I think this has been asked for since the beginning of time, but not sure if we actually want this. After Julian added the code to allow File Browser to be a child window always on top, doing so for new windows created with SCREEN_OT_area_dupli ("Duplicate Area into New Window") is a trivial change.

It certainly makes the feature usable on Windows, since your newly-created windows no longer dive under the main one. I realize that other platforms might have window manager features that get around this.

But windows like this, including File Browser, cannot be individually minimized - that just isn't something that can coexist with "always on top". So this could be much better in cramped screen conditions where not overlapping is required, but the lack of minimization might be missed where there is more space when using multiple monitors.

I am assuming that this "is dialog" behavior has been tuned to work nicely on Mac and Linux, so can't think this would have negative affect there.

Following shows a torn-off window overlapping the main one, even though it does not have focus. The secondary one does not have “minimize” option. Tasktray shows only one icon that you can use to minimize them both at once.

Diff Detail

Repository: rB Blender

Event Timeline

Harley Acheson (harley) created this revision.Dec 1 2019, 7:52 PM

I'm sure you've see this? T69819

I think it's somewhat reasonable to assume that if users tear off a single editor, it should probably spawn as a child window - users would like to use floating windows on top of the main window for some things, and this would make that possible. As for the minimise thing, that is really more a Windows issue than a Blender issue I think.

Added more changes to represent my "wish list" for window changes.

"WM_window_open_temp" is changed to "WM_window_open_space" and gets a new bool arg that specifies whether is temp or not, so whether to set screen->temp.

wm_window_new_exec - opens dialog (owned) window with only SPACE_VIEW3D.

This means that Window / New Main Window remains untouched. It opens a new window the same size as current with same layout of editors. And remains a regular un-owned window.

But Window / New Window no longer has the identical behavior as above. Instead it opens a dialog (owned) window containing only a 3DEditor. The most likely use for this menu item is to get a window of a specific type so this act becomes faster since there is less cleanup to do first. Just open a window and change its type. And it remains on top. And its min/restore status changes with that of the spawning window.

However, you can open a new main window and then open windows from there and they will be controlled by this new window instead.

The combination of choices should let us do almost anything in a quick a logical way.

Harley Acheson (harley) mentioned this in T69819: Secondary Window Behaviors.Dec 3 2019, 7:42 PM

KiJeon (0o00o0oo) awarded a token.Dec 3 2019, 10:28 PM

KiJeon (0o00o0oo) added a subscriber: KiJeon (0o00o0oo).

This seems fine to me, but someone with access to Windows should test this, since this change is specific to Blender on Windows.

Resigning as reviewer since I can’t test, but overall seems ok.

Not sure how much i can add to this review honestly, I can validate that it builds on windows, seems to work and it's not calling any windows API's in a bad way, so based on that i'll happily accept the patch. However given it's an UI change the UI team has to have the final say here.

This revision is now accepted and ready to land.Dec 5 2019, 5:35 PM

This patch is not specific to Windows, it affects macOS and Linux and needs to be tested there.
On macOS, more work is needed in GHOST, the code changes there were only for a blocking modal file dialog case and behavior will be glitchy with this patch.
The state is not preserved through .blend file save and load, windows will always load as non-dialog.

This revision now requires changes to proceed.Dec 5 2019, 7:02 PM

@Brecht Van Lommel (brecht) - This patch is not specific to Windows, it affects macOS and Linux and needs to be tested there.

Yes, my thought (right or wrong LOL) was that just treating these the same as we are now doing with temp windows would be safe since that behavior on those other platforms is already tested.

On macOS, more work is needed in GHOST, the code changes there were only for a blocking modal file dialog case and behavior will be glitchy with this patch.

Bloody hell.

The state is not preserved through .blend file save and load, windows will always load as non-dialog.

Actually I didn't even realize that multiple windows are restored. So this would be fixable, but not sure worth doing anything if we have other platform issues.

I think that would mean there is nothing for this patch. I can't see adding windows-specific blocks for this behavior since the new Dialog stuff is meant to be for all platforms.

Could just make all secondary windows owned in Windows, I suppose. Then the behavior would still be similar between platforms. Oh well, thought this was easy. LOL

stefano severi (Tetone) awarded a token.Dec 5 2019, 9:21 PM

@Brecht Van Lommel (brecht) wrote:

This patch is not specific to Windows, it affects macOS and Linux and needs to be tested there.

On macOS, more work is needed in GHOST, the code changes there were only for a blocking modal file dialog case and behavior will be glitchy with this patch.

The state is not preserved through .blend file save and load, windows will always load as non-dialog.

To be honest all that makes this simpler...

The central issue is that any blender window that we would consider to be a "child", on the Windows OS means that it has an owner set. Without an owner set it is an independent thing with its own taskbar icon and has a depth relationship is not related to any other windows. With owner set it minimizes with its owner, stays above its owner, and shares taskbar icon.

This patch just makes it so any new window with win->parent sets is_dialog for Windows OS (only). This way it doesn't affect other OSs but at least these popup windows will finally be usable. And yes, the state is preserved when separate windows are saved together.

I also left in the other small change that makes the result of "New Window" simpler and a bit smaller.

Brecht Van Lommel (brecht) added inline comments.Dec 7 2019, 7:04 PM

source/blender/windowmanager/intern/wm_window.c
968–969	It seems wrong to use file browser data here.
976–978	Isn't this clearing the temp flag of the wrong screen? And it's better to rename and pass a parameter to `WM_window_open_temp`, rather than make changes afterwards to undo things, that makes code fragile.

@Brecht Van Lommel (brecht): Actually will abandon this and break it into two pieces.

Windows only needs that two-line change to work correctly with these torn-off windows. The other issue (simplifying "New Window") is unrelated and I see that I have done dumb things here only to keep the changes as small as possible for no good reason I can see. LOL. Will do it again better in two pieces shortly.