Secondary Window Behaviors #69819

New Issue

William Reynish · 2019-09-12T23:06:23+02:00

William Reynish commented

2019-09-12 23:06:23 +02:00

We want users to be able to use multiple windows on multiple monitors, have them behave in ways that are as consistent as possible between platforms, conform to expected per-platform norms, and offer maximum flexibility for different workflows.

Windows should be created and restored at the size they are requested and saved, even when the scale and/or dpi differs between monitors.

- Windows - This all seems correct now
- Mac - Some windows are created at incorrect size on high-dpi (Retina) displays
- Linux - Unknown status

Windows should be restored at the same position where they were saved, regardless of monitor arrangement.

- Windows - This all seems correct now
- Mac - Probably does not restore some windows correctly with multiple monitors in vertical arrangement.
- Linux - Unknown status

Secondary and temporary windows should appear above other Blender windows, but not on top of all the windows of all other apps

- Windows - Platform variation: Child windows are above parents, but parent siblings have no on-top behavior
- Mac - Considered to be working as users prefer
- Linux - Unknown status

Bring all Blender windows to the front when the main Blender window is activated.

- Windows - Platform variation: Each main window will bring children to front when activated, but not other main windows.
- Mac - Unknown status
- Linux - Unknown status

Temporary windows should be created at a last-used size, and not reset to the default size every time they are opened.

- All Platforms

Temporary windows should not steal each other’s windows

- All Platforms - These windows are only now reused if the titles are identical.

All Windows should have informative titles to help differentiate them.

- All Platforms - This might (eventually) do the trick: D12365: UI: Improved Window Titles

Better activation behavior as the mouse moves back and forth between the windows (don't require a click to activate another blender window so shortcuts can be pressed)

- Windows - If desired on platform, this might work: D13951: Win32: Auto-Raise and -Focus Windows on Hover
- Mac - N/A
- Linux - Unknown status

Don't let secondary windows appear in the task bar (main windows of course should still appear here)

- Windows - All windows of app instance are bundled together on Task Bar.
- Mac - N/A
- Linux - Unknown status

Secondary windows could use a slimmer title bar, to make them visually different from the main Blender window.

- Windows - Platform does not currently have such a style as would decrease the mouse hit size.
- Mac - Unknown status
- Linux - Unknown status

Temporary windows (open/save dialogs) could block the underlying windows until they have been closed or dismissed. Although breaks our non-blocking paradigm.

- Windows - Not currently desired on this platform. Behavior could be implemented if we ever have very small and simple dialogs.
- Mac - Considered working as users prefer
- Linux - Unknown status

We want users to be able to use multiple windows on multiple monitors, have them behave in ways that are as consistent as possible between platforms, conform to expected per-platform norms, and offer maximum flexibility for different workflows. Windows should be created and restored at the **size** they are requested and saved, even when the scale and/or dpi differs between monitors. - - [x] Windows - This all seems correct now - - [ ] Mac - Some windows are created at incorrect size on high-dpi (Retina) displays - - [ ] Linux - Unknown status Windows should be restored at the same **position** where they were saved, regardless of monitor arrangement. - - [x] Windows - This all seems correct now - - [ ] Mac - Probably does not restore some windows correctly with multiple monitors in *vertical* arrangement. - - [ ] Linux - Unknown status Secondary and temporary windows should appear above other Blender windows, but not on top of all the windows of all other apps - - [x] Windows - Platform variation: Child windows are above parents, but parent siblings have no on-top behavior - - [x] Mac - Considered to be working as users prefer - - [ ] Linux - Unknown status Bring all Blender windows to the front when the main Blender window is activated. - - [x] Windows - Platform variation: Each main window will bring children to front when activated, but not other main windows. - - [ ] Mac - Unknown status - - [ ] Linux - Unknown status Temporary windows should be created at a last-used size, and not reset to the default size every time they are opened. - - [ ] All Platforms Temporary windows should not steal each other’s windows - - [x] All Platforms - These windows are only now reused if the titles are identical. All Windows should have informative titles to help differentiate them. - - [ ] All Platforms - This might (eventually) do the trick: [D12365: UI: Improved Window Titles](https://archive.blender.org/developer/D12365) Better activation behavior as the mouse moves back and forth between the windows (don't require a click to activate another blender window so shortcuts can be pressed) - - [ ] Windows - If desired on platform, this might work: [D13951: Win32: Auto-Raise and -Focus Windows on Hover](https://archive.blender.org/developer/D13951) - - [ ] Mac - N/A - - [ ] Linux - Unknown status Don't let secondary windows appear in the task bar (main windows of course should still appear here) - - [x] Windows - All windows of app instance are bundled together on Task Bar. - - [ ] Mac - N/A - - [ ] Linux - Unknown status Secondary windows *could* use a slimmer title bar, to make them visually different from the main Blender window. - - [ ] Windows - Platform does not currently have such a style as would decrease the mouse hit size. - - [ ] Mac - Unknown status - - [ ] Linux - Unknown status Temporary windows (open/save dialogs) *could* block the underlying windows until they have been closed or dismissed. Although breaks our non-blocking paradigm. - - [x] Windows - Not currently desired on this platform. Behavior could be implemented if we ever have very small and simple dialogs. - - [x] Mac - Considered working as users prefer - - [ ] Linux - Unknown status

Julian Eisel was assigned by William Reynish

2019-09-12 23:06:23 +02:00

William Reynish commented

2019-09-12 23:06:23 +02:00

Added subscribers: @WilliamReynish, @RosarioRosato, @semaphore, @mendio, @0o00o0oo, @antoniov, @T.R.O.Nunes, @Ehab, @BartekMoniewski, @DuarteRamos, @MaciejJutrzenka, @Znio.G, @brecht, @Sergey, @dfelinto, @mont29, @ideasman42

blender-admin commented

2019-09-12 23:06:23 +02:00

#94432 was marked as duplicate of this issue

blender-admin commented

2019-09-12 23:06:23 +02:00

#82295 was marked as duplicate of this issue

blender-admin commented

2019-09-12 23:06:23 +02:00

#69820 was marked as duplicate of this issue

KiJeon commented

2019-09-13 03:17:09 +02:00

Oh, my gosh, my heart skipped a beat seeing the descriptions of this task. I've been wanting this fundamental feature for years and it's finally coming. Thank you so much for tackling this.

If I may, I'd like to suggest some additional behaviors to consider, to make Blender even better than all other production programs I use:

Could the "always-on-top" be made a toggle? By default, secondary windows could be always-on-top (or maybe a changeable option in Preferences), but it would be useful if the user can easily click on a pin, or a dot or something in the title bar that toggles its behavior. With other programs, I frequently wish certain windows would sit in the background until I call them forward because I don't want to close the window that I've setup, but I also don't want them to overlap another window I want to prioritize in the front (e.g. from another program).
If 1 becomes a feature, it would also be useful/essential to be able to either press a hotkey or a button that brings all children windows to the front. (else, we'd just have the same behavior as now where we can lose track of which window belongs to which Blender instance).
Another toggle that allows a window to become always-on-top of ALL windows.

Oh, my gosh, my heart skipped a beat seeing the descriptions of this task. I've been wanting this fundamental feature for years and it's finally coming. *Thank you so much for tackling this.* If I may, I'd like to suggest some additional behaviors to consider, to make Blender even better than all other production programs I use: 1. **Could the "always-on-top" be made a toggle?** By default, secondary windows could be always-on-top (or maybe a changeable option in Preferences), but it would be useful if the user can easily click on a pin, or a dot or something in the title bar that toggles its behavior. With other programs, I frequently wish certain windows would sit in the background until I call them forward because I don't want to close the window that I've setup, but I also don't want them to overlap another window I want to prioritize in the front (e.g. from another program). 2. If 1 becomes a feature, it would also be useful/essential to be able to either **press a hotkey or a button that brings all children windows to the front.** (else, we'd just have the same behavior as now where we can lose track of which window belongs to which Blender instance). 3. Another **toggle that allows a window to become always-on-top of ALL windows**.

William Reynish commented

2019-09-13 07:44:16 +02:00

@0o00o0oo We already have two types of windows in Blender. You can have multiple main windows too, mainly for multi-monitor support. These won’t be on top.

I don’t see the need for adding all sorts of toggles and options - we should just do the right thing. Other apps ‘just work’ without the need for dozens of options to make it behave appropriately.

@0o00o0oo We already have two types of windows in Blender. You can have multiple main windows too, mainly for multi-monitor support. These won’t be on top. I don’t see the need for adding all sorts of toggles and options - we should just do the right thing. Other apps ‘just work’ without the need for dozens of options to make it behave appropriately.

William Reynish commented

2019-09-13 08:30:58 +02:00

Added subscriber: @GavinScott

KiJeon commented

2019-09-13 08:55:33 +02:00

@WilliamReynish I understand, just doing what all the other programs fundamentally do is great.
I was channeling the feeling of users in discussions I've seen on forums who are glad Blender doesn't do this because they don't like when all windows are forced to the front. But also, I personally have experience where I wish I could control this behavior.

So, if not for this task, I would hope being able to toggle the behavior with the ability to call all other windows forward would be something looked into in the future.

In #69819#775073, @WilliamReynish wrote:
@0o00o0oo We already have two types of windows in Blender. You can have multiple main windows too, mainly for multi-monitor support. These won’t be on top.

I'm not sure what you mean by "These won't be on top." Are main windows not going to also get some of the secondary window behaviors? Namely, if one instance of Blender has two different main windows across two different monitors, and one of them gets buried beneath other windows, would activating the one visible main window bring the other main window forward in the other monitor?

@WilliamReynish I understand, just doing what all the other programs fundamentally do is great. I was channeling the feeling of users in discussions I've seen on forums who are glad Blender doesn't do this because they don't like when all windows are forced to the front. But also, I personally have experience where I wish I could control this behavior. So, if not for this task, I would hope being able to toggle the behavior with the ability to call all other windows forward would be something looked into in the future. > In #69819#775073, @WilliamReynish wrote: > @0o00o0oo We already have two types of windows in Blender. You can have multiple main windows too, mainly for multi-monitor support. These won’t be on top. I'm not sure what you mean by "These won't be on top." Are main windows not going to also get some of the secondary window behaviors? Namely, if one instance of Blender has two different main windows across two different monitors, and one of them gets buried beneath other windows, would activating the one visible main window bring the other main window forward in the other monitor?

Ludvik Koutny commented

2019-09-13 16:11:40 +02:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2019-09-13 16:11:40 +02:00

Let's add fixing this: https://devtalk.blender.org/t/workspaces-change-content-of-floating-window/8673 to the list.
Right now, floating windows very limited in usability when used with workspaces, or conversely, workspaces are very limited in usability when used with multiple windows.
The use case of switching workspaces but having something else on the second window on the second monitor needs to be improved.

Let's add fixing this: https://devtalk.blender.org/t/workspaces-change-content-of-floating-window/8673 to the list. Right now, floating windows very limited in usability when used with workspaces, or conversely, workspaces are very limited in usability when used with multiple windows. The use case of switching workspaces but having something else on the second window on the second monitor needs to be improved.

Brecht Van Lommel commented

2019-09-13 16:26:04 +02:00

No, that's outside the scope of this task.

Michael Hermann commented

2019-09-13 21:20:58 +02:00

Added subscriber: @MichaelHermann

Michael Hermann commented

2019-09-13 21:20:58 +02:00

Maybe this is worth adding/fixing:

Modifier Keys seem to be ignored on secondary windows when they are not in focus (New Main Window as well as New Window).

This happens for example when I have an orthographic or camera view of my current scene on the other monitor (in another Window) and I want to move the view by Ctrl/Shift+MMB dragging. What happens is that the view rotates instead of zooming/panning, as if I had used only MMB to orbit. It only works when I have given focus to the secondary window prior to the changing the view. No big deal, but this happens a LOT while working.

Maybe this is worth adding/fixing: Modifier Keys seem to be ignored on secondary windows when they are not in focus (New Main Window as well as New Window). This happens for example when I have an orthographic or camera view of my current scene on the other monitor (in another Window) and I want to move the view by Ctrl/Shift+MMB dragging. What happens is that the view rotates instead of zooming/panning, as if I had used only MMB to orbit. It only works when I have given focus to the secondary window prior to the changing the view. No big deal, but this happens a LOT while working.

Sebastian Villanueva commented

2019-09-14 03:08:01 +02:00

Added subscriber: @vr_sebas

Galen Beals commented

2019-09-14 03:26:33 +02:00

Added subscriber: @galenbeals

Julian Eisel commented

2019-09-15 19:29:13 +02:00

Added subscriber: @pablovazquez

Julian Eisel commented

2019-09-15 19:29:13 +02:00

My suggestion was to start by making all temporary windows to be always-on-top, see D5765. That literally means always on top, even on top of non-Blender windows. Then try to get to this task as soon as possible, hence why it's set to high priority.
Multi-window support in Blender is far from great in regards to usability, but that's nothing new and we won't be able to fix it for 2.81. But again - I see it as a high priority issue.

Asking UI module owners to see if there's any consensus: @WilliamReynish, @pablovazquez, @ideasman42, @brecht would you be fine with me moving forward that way?

My suggestion was to start by making all temporary windows to be always-on-top, see [D5765](https://archive.blender.org/developer/D5765). That literally means always on top, even on top of non-Blender windows. Then try to get to this task as soon as possible, hence why it's set to high priority. Multi-window support in Blender is far from great in regards to usability, but that's nothing new and we won't be able to fix it for 2.81. But again - I see it as a high priority issue. Asking UI module owners to see if there's any consensus: @WilliamReynish, @pablovazquez, @ideasman42, @brecht would you be fine with me moving forward that way?

Brecht Van Lommel commented

2019-09-15 19:41:39 +02:00

We should order Blender windows relative to each other. So that the file browser is highest, then other windows without a topbar, then the main windows with a topbar. Not always on top of non-Blender windows.

Campbell Barton commented

2019-09-15 20:01:04 +02:00

In X11 you can either:

Set the always-on-top window property.
Set windows as being the child of the main window. (let the window manager be responsible for handling order - typically they won't allow child windows to be below main windows).

I expect users will find always-on-top gets annoying, so proper window parenting should be supported. I assume this can match Blender's own window parenting.

In X11 you can either: - Set the always-on-top window property. - Set windows as being the child of the main window. (let the window manager be responsible for handling order - typically they won't allow child windows to be below main windows). I expect users will find always-on-top gets annoying, so proper window parenting should be supported. I assume this can match Blender's own window parenting.

William Reynish commented

2019-09-23 23:55:13 +02:00

Some Mac-related resources on how to control window ordering:

Stack Overflow about window ordering on Mac:
https://stackoverflow.com/questions/5364460/keep-nswindow-front

NSwindow documentation:
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/WinPanel/Concepts/WindowLevel.html
https://developer.apple.com/documentation/appkit/nswindow

NSwindow order:
https://developer.apple.com/documentation/appkit/nswindow/1419672-order
https://developer.apple.com/documentation/appkit/nswindow/1419495-orderfront

Add child window:
https://developer.apple.com/documentation/appkit/nswindow/1419152-addchildwindow

Make windows interactive even if a modal window is in front:
https://developer.apple.com/documentation/appkit/nswindow/1419220-workswhenmodal

Put window on the very front layer (not what we want, but adding here anyway)
https://developer.apple.com/documentation/appkit/nswindow/1419444-orderfrontregardless

Some Mac-related resources on how to control window ordering: Stack Overflow about window ordering on Mac: https://stackoverflow.com/questions/5364460/keep-nswindow-front NSwindow documentation: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/WinPanel/Concepts/WindowLevel.html https://developer.apple.com/documentation/appkit/nswindow NSwindow order: https://developer.apple.com/documentation/appkit/nswindow/1419672-order https://developer.apple.com/documentation/appkit/nswindow/1419495-orderfront Add child window: https://developer.apple.com/documentation/appkit/nswindow/1419152-addchildwindow Make windows interactive even if a modal window is in front: https://developer.apple.com/documentation/appkit/nswindow/1419220-workswhenmodal Put window on the very front layer (not what we want, but adding here anyway) https://developer.apple.com/documentation/appkit/nswindow/1419444-orderfrontregardless

Jose commented

2019-09-27 15:04:56 +02:00

Added subscriber: @Dogway

Giuseppe Bufalo commented

2019-09-28 16:21:48 +02:00

Added subscriber: @giuseppebufalo

Julian Eisel commented

2019-09-28 16:42:26 +02:00

@ideasman42 parenting is not what you'd think it is. In X based UIs, every widget used to be an own X window, whereby the parenting was used to manage the hierarchy. So on X, a child window draws without window decorations, and always within the parent window. You could call it superimposing & clipping windows I guess.
AFAIK on Windows and MacOS, parenting has the same effect, although I'm not sure if it's for the same reason.

I think closest to what we want is `XSetTransientForHint(), which has the issue that most common window managers disallow minimizing and maximizing windows with that hint set. I tried hard to bring those back, without luck.

We don't want to set the always-on-top property indeed, since that wouldn't allow having non-Blender windows on top either.

@ideasman42 parenting is not what you'd think it is. In X based UIs, every widget used to be an own X window, whereby the parenting was used to manage the hierarchy. So on X, a child window draws without window decorations, and always within the parent window. You could call it superimposing & clipping windows I guess. AFAIK on Windows and MacOS, parenting has the same effect, although I'm not sure if it's for the same reason. I think closest to what we want is `XSetTransientForHint(), which has the issue that most common window managers disallow minimizing and maximizing windows with that hint set. I tried hard to bring those back, without luck. We don't want to set the always-on-top property indeed, since that wouldn't allow having non-Blender windows on top either.

Bent Hillerkus commented

2019-09-28 16:49:33 +02:00

Added subscriber: @bent

Bent Hillerkus commented

2019-09-28 16:49:33 +02:00

It's not in the description of the task, but wouldn't it be a good point, to also implent a borderless design with the window buttons in the top bar ?

It's not in the description of the task, but wouldn't it be a good point, to also implent a borderless design [with the window buttons in the top bar ](https://ui.pablovazquez.art/)?

William Reynish commented

2019-09-28 16:51:15 +02:00

@bent That is not related to secondary windows.

Antonio Vazquez commented

2019-10-07 12:41:31 +02:00

Removed subscriber: @antoniov

Marco Fink commented

2019-10-29 19:30:13 +01:00

Added subscriber: @mfink

Marco Fink commented

2019-10-29 19:30:13 +01:00

Love you Guys

Oskar commented

2019-11-01 10:33:31 +01:00

Added subscriber: @Oskar3d

Oskar commented

2019-12-03 12:35:39 +01:00

With these improvements I have an idea about the Window menu:

WINDOW MENU

New Window
New Main Widnow
General Editors >
Animation Editors >
Scripting Editors >
Data Editors >
- Outliner - This opens the Outliner in a new child window
- Properties
- File Browser
- Preferences

I think it saves a few extra steps after you open a new window. (to change it to the editor you need)
Having them in a menu makes it easy for new users to assign shortcuts for opening editors.
It's something familiar (you can find editors in the Window menu in most DCC apps - Maya, Photoshop, After Effects, GIMP etc.)
Opening the Outliner in this case could have some default window size values (if it wasn't used before) so it's more of a vertical rectangle. And the Graph Editor more of a horizontal rectangle.

With these improvements I have an idea about the Window menu: WINDOW MENU ``` New Window New Main Widnow General Editors > Animation Editors > Scripting Editors > Data Editors > - Outliner - This opens the Outliner in a new child window - Properties - File Browser - Preferences ``` * I think it saves a few extra steps after you open a new window. (to change it to the editor you need) * Having them in a menu makes it easy for new users to assign shortcuts for opening editors. * It's something familiar (you can find editors in the Window menu in most DCC apps - Maya, Photoshop, After Effects, GIMP etc.) * Opening the Outliner in this case could have some default window size values (if it wasn't used before) so it's more of a vertical rectangle. And the Graph Editor more of a horizontal rectangle.

ML commented

2019-12-03 17:13:44 +01:00

Added subscriber: @MarcelLegindi

Harley Acheson commented

2019-12-03 19:42:21 +01:00

Added subscriber: @Harley

Harley Acheson commented

2019-12-03 19:42:21 +01:00

Looking at this on the Windows side, @JulianEisel's code seems perfect. Setting his "dialog" on Windows results in a window that is "owned" by the window that creates it. Which is exactly what results in having the window always above the main window and minimizing and restoring with it. On the Windows OS these windows can't be individually minimized (since that is controlled by the owning window), but this is fine.

The following patch applies this to the other windows that can be created:

https://developer.blender.org/D6338

So will give you an always-on-top window when you "duplicate into a new window".

And also does so if you select "New Window" from the "Window" menu. But it also changes the window itself too. Instead of giving you a huge window with default layout with multiple editors it instead gives you a slightly smaller window with a single editor. That way it is easier to quickly make new windows since you have less cleanup to get to what you desire.

The patch makes no change to "New Main Window". So it creates the same layout and remains the same type of window. Which is cool. This means you can "New Window" on the main window to get multiple children that do not create new tasktray icons and are controlled with the main window. But then make a new Main window (and get a second tasktray icon) and make make children from that and they are controlled by that new main window.

Looking at this on the Windows side, @JulianEisel's code seems **perfect**. Setting his "dialog" on Windows results in a window that is "owned" by the window that creates it. Which is exactly what results in having the window always above the main window and minimizing and restoring with it. On the Windows OS these windows can't be individually minimized (since that is controlled by the owning window), but this is fine. The following patch applies this to the other windows that can be created: https://developer.blender.org/D6338 So will give you an always-on-top window when you "duplicate into a new window". And also does so if you select "New Window" from the "Window" menu. But it also changes the window itself too. Instead of giving you a huge window with default layout with multiple editors it instead gives you a slightly smaller window with a single editor. That way it is easier to quickly make new windows since you have less cleanup to get to what you desire. The patch makes no change to "New Main Window". So it creates the same layout and remains the same type of window. Which is cool. This means you can "New Window" on the main window to get multiple children that do not create new tasktray icons and are controlled with the main window. But then make a new Main window (and get a second tasktray icon) and make make children from that and they are controlled by that new main window.

Eugene Du commented

2020-07-13 18:30:46 +02:00

Added subscriber: @APEC

Russell commented

2020-08-29 17:01:17 +02:00

Added subscriber: @Russ1642

Russell commented

2020-08-29 17:01:17 +02:00

I figure the following bug should be captured with this task. I have a second window on a second monitor showing only the properties panel. The dropdown menus don't go behind or on top of other windows. They're actually cut off. That's my black desktop wallpaper by the way.

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 452.06

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-08-25 19:28, hash: 396d39c6b9

I figure the following bug should be captured with this task. I have a second window on a second monitor showing only the properties panel. The dropdown menus don't go behind or on top of other windows. They're actually cut off. That's my black desktop wallpaper by the way. ![2020-08-29 0856 17.jpg](https://archive.blender.org/developer/F8819092/2020-08-29_0856_17.jpg) **System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 452.06 **Blender Version** Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-08-25 19:28, hash: `396d39c6b9`

RedMser commented

2020-09-12 22:42:29 +02:00

Added subscriber: @RedMser

Wenzo commented

2020-09-13 19:15:19 +02:00

Added subscriber: @kivo

Wenzo commented

2020-09-21 18:15:27 +02:00

any updates on the task?

Robert Guetzkow commented

2020-11-01 10:24:53 +01:00

Added subscribers: @Memento, @jenkm

CybranM commented

2021-05-04 22:00:16 +02:00

Added subscriber: @IihT2cWA9xiP30BsYphz3EiEISNoScoe

CybranM commented

2021-05-04 22:00:16 +02:00

Any news on this? Its a really useful feature and would help immensely

Harley Acheson commented

2021-05-04 22:06:51 +02:00

@IihT2cWA9xiP30BsYphz3EiEISNoScoe - Any news on this? Its a really useful feature and would help immensely

Which feature in particular, since this mentions many different things.

On Windows now (2.93 and newer) these are now complete:

Secondary and temporary windows should appear above other Blender windows, but not on top of all the windows of all other apps
Bring all Blender windows to the front when the main Blender window is activated.
don't let secondary windows appear in the task bar (main windows of course should still appear here)
Temporary windows should not steal each other’s windows

> @IihT2cWA9xiP30BsYphz3EiEISNoScoe - Any news on this? Its a really useful feature and would help immensely Which feature in particular, since this mentions many different things. On Windows now (2.93 and newer) these are now complete: - Secondary and temporary windows should appear above other Blender windows, but not on top of all the windows of all other apps - Bring all Blender windows to the front when the main Blender window is activated. - don't let secondary windows appear in the task bar (main windows of course should still appear here) - Temporary windows should not steal each other’s windows

CybranM commented

2021-05-05 23:55:15 +02:00

@Harley wrote:
On Windows now (2.93 and newer) these are now complete:

Secondary and temporary windows should appear above other Blender windows, but not on top of all the windows of all other apps

Bring all Blender windows to the front when the main Blender window is activated.

don't let secondary windows appear in the task bar (main windows of course should still appear here)

Temporary windows should not steal each other’s windows

I downloaded 2.93 (use 2.92 normally) to test it and Blender does bring all "sub-windows" to the front when becoming active which is great!
However it still doesn't allow me to effectively use a floating outliner (on another monitor) in the way I had hoped, this video shows the issue I'm having: https://streamable.com/7isso0 with a clip from Modo to show what I'd hoped for.

You wrote that it shouldn't show "sub-windows" in the task bar which it still does unless I'm missing something?

Hope it doesn't come off as too negative, I appreciate the work that has gone into this!

>@Harley wrote: > On Windows now (2.93 and newer) these are now complete: > - Secondary and temporary windows should appear above other Blender windows, but not on top of all the windows of all other apps > - Bring all Blender windows to the front when the main Blender window is activated. > - don't let secondary windows appear in the task bar (main windows of course should still appear here) > - Temporary windows should not steal each other’s windows I downloaded 2.93 (use 2.92 normally) to test it and Blender does bring all "sub-windows" to the front when becoming active which is great! However it still doesn't allow me to effectively use a floating outliner (on another monitor) in the way I had hoped, this video shows the issue I'm having: https://streamable.com/7isso0 with a clip from Modo to show what I'd hoped for. You wrote that it shouldn't show "sub-windows" in the task bar which it still does unless I'm missing something? ![05_23-39-53_explorer-118.png](https://archive.blender.org/developer/F10055489/05_23-39-53_explorer-118.png) Hope it doesn't come off as too negative, I appreciate the work that has gone into this!

Harley Acheson commented

2021-05-06 00:26:32 +02:00

I think what you are showing in the linked video is normal Windows OS behavior in that it only forwards input events to the one window that currently has focus. You can change that to be more like Linux by enabling "Activate a window by hovering over it with the mouse", somewhere in Ease of Access - should be easy to find with a google search.

What I mean about "subwindows" in the Taskbar is that they should be "grouped", unless you turn off taskbar grouping "Combine buttons" is what it is called in control panel

I _think_ what you are showing in the linked video is normal Windows OS behavior in that it only forwards input events to the one window that currently has focus. You can change that to be more like Linux by enabling "Activate a window by hovering over it with the mouse", somewhere in Ease of Access - should be easy to find with a google search. What I mean about "subwindows" in the Taskbar is that they should be "grouped", unless you turn off taskbar grouping "Combine buttons" is what it is called in control panel

CybranM commented

2021-05-06 09:32:58 +02:00

I'm by no means a programmer but in my example with Modo I had the smaller side window active but could still activate the move tool and rotate tool without having to click the main window to activate it.
Its the same with other programs like Spotify, I can scroll to increase/decrease volume and in Chrome I can still scroll by just hovering over an inactive window.

I'm by no means a programmer but in my example with Modo I had the smaller side window active but could still activate the move tool and rotate tool without having to click the main window to activate it. Its the same with other programs like Spotify, I can scroll to increase/decrease volume and in Chrome I can still scroll by just hovering over an inactive window.

Marco Fink commented

2021-05-06 14:29:46 +02:00

Unfortunately the Ease of Access hovering over Checkbox doesn't work in both ways, i ve tested it with 1 undocked Window, it only works on the SubWindow, not vice versa.
Besides that this always gives the User a tiny delay on activating what can be a bit annoying in long term.

Unfortunately the Ease of Access hovering over Checkbox doesn't work in both ways, i ve tested it with 1 undocked Window, it only works on the SubWindow, not vice versa. Besides that this always gives the User a tiny delay on activating what can be a bit annoying in long term.

Giuseppe Bufalo commented

2021-05-06 14:31:12 +02:00

Removed subscriber: @giuseppebufalo

Ray Mairlot commented

2021-05-24 20:42:47 +02:00

Added subscriber: @RayMairlot

Ray Mairlot commented

2021-05-24 20:42:47 +02:00

I don't know whether I am missing something or maybe what I'm about to bring up is already on the agenda, but having just started using Blender 3.0 with a dual screen setup (one main window and one secondary/regular window), having used blender for years with multiple windows on multiple monitors, I am finding the new 'child' window feature is now severely interfering with how I normally work.

If I am writing a script in the Text Editor on my secondary window and want to have StackOverflow open on my other monitor (where the main blender window is), clicking the text editor to type now hides the web browser (by bringing the main blender window into focus). Or, I minimise the main Blender window to view the web browser and now the secondary blender window is hidden.
A reference image open in front of the secondary window gets hidden as soon as the main window is clicked on making it impossible to use as a reference unless I remember to minimise the secondary window first.
I have not completely identified when, but sometimes it takes two clicks on the taskbar icon of a program instead of one to bring a program window (e.g. a web browser window) back into focus from behind the main blender window.
I can't restore just the secondary window if the main window is minimised because the secondary window disappears from the taskbar. Again, this seems incredibly inflexible compared to the way previous blender versions worked.

These problems seem to get in the way of the point of having a dual monitor setup.

Having two main windows might fix this (I haven't tried) but then I don't get the benefit of each window remembering which scene is active (an option which was previously controlled by the 'Global Scene' option, though that option was removed when 'main' and 'secondary' windows were introduced, as the active scene on a secondary window is linked to the scene on the main window). (The benefit of 'Global Scene' is that you don't get into a situation where you're editing something on one monitor and wondering why you can't see the changes on the other, only to find that the other window is showing a different scene. 'Global Scene' makes sure all windows are updated to the same scene when the scene is changed in any window.)

Personally I thought blender had one of best ways of using multiple windows on multiple monitors, which worked exactly how I would expect a multi window program to work and gave me the most flexibility on how I wanted to use blender. I can understand wanting to make changes to how temporary windows work, but for the 'permanent' windows, this seems like quite a step back. Maybe these things are something I will get used to, but at the moment it seems more interrupting to how I want and expect to be able to work than it is useful and I can't really understand the motivation to change blender to work like this. Maybe bringing back the 'Global Scene' option and changing to using two main windows will fix all this?

I don't know whether I am missing something or maybe what I'm about to bring up is already on the agenda, but having just started using Blender 3.0 with a dual screen setup (one main window and one secondary/regular window), having used blender for years with multiple windows on multiple monitors, I am finding the new 'child' window feature is now severely interfering with how I normally work. - If I am writing a script in the Text Editor on my secondary window and want to have StackOverflow open on my other monitor (where the main blender window is), clicking the text editor to type now hides the web browser (by bringing the main blender window into focus). Or, I minimise the main Blender window to view the web browser and now the secondary blender window is hidden. - A reference image open in front of the secondary window gets hidden as soon as the main window is clicked on making it impossible to use as a reference unless I remember to minimise the secondary window first. - I have not completely identified when, but sometimes it takes two clicks on the taskbar icon of a program instead of one to bring a program window (e.g. a web browser window) back into focus from behind the main blender window. - I can't restore *just* the secondary window if the main window is minimised because the secondary window disappears from the taskbar. Again, this seems incredibly inflexible compared to the way previous blender versions worked. These problems seem to get in the way of the point of having a dual monitor setup. Having two main windows might fix this (I haven't tried) but then I don't get the benefit of each window remembering which scene is active (an option which was previously controlled by the 'Global Scene' option, though that option was removed when 'main' and 'secondary' windows were introduced, as the active scene on a secondary window is linked to the scene on the main window). (The benefit of 'Global Scene' is that you don't get into a situation where you're editing something on one monitor and wondering why you can't see the changes on the other, only to find that the other window is showing a different scene. 'Global Scene' makes sure all windows are updated to the same scene when the scene is changed in any window.) Personally I thought blender had one of best ways of using multiple windows on multiple monitors, which worked exactly how I would expect a multi window program to work and gave me the most flexibility on how I wanted to use blender. I can understand wanting to make changes to how temporary windows work, but for the 'permanent' windows, this seems like quite a step back. Maybe these things are something I will get used to, but at the moment it seems more interrupting to how I want and expect to be able to work than it is useful and I can't really understand the motivation to change blender to work like this. Maybe bringing back the 'Global Scene' option and changing to using two main windows will fix all this?

CybranM commented

2021-06-03 20:36:35 +02:00

The new way Blender handles multi-window setups is vastly better for what I'm doing but I can understand how it might affect people who use it differently, such as what madog described.
I'm working with multiple Blender windows open at the same time (maximized viewport on main window and outliner, properties etc on a secondary monitor). I have to switch very often to other programs such as Unreal Engine which I also have split open into multiple windows. The way Blender used to handle this was that I'd always have to open each Blender sub-window one at a time which was a huge annoyance and wasted time, this new system is very smooth and is a lot closer to what I'd expect.
Modo, Maya and Unreal Engine (and basically every multi-window program that I've used) all work like this in regards to multiple windows and its great that Blender now does too (only thing I want is for it to recognize which window is under the cursor )

The new way Blender handles multi-window setups is vastly better for what I'm doing but I can understand how it might affect people who use it differently, such as what madog described. I'm working with multiple Blender windows open at the same time (maximized viewport on main window and outliner, properties etc on a secondary monitor). I have to switch very often to other programs such as Unreal Engine which I also have split open into multiple windows. The way Blender used to handle this was that I'd always have to open each Blender sub-window one at a time which was a huge annoyance and wasted time, this new system is very smooth and is a lot closer to what I'd expect. Modo, Maya and Unreal Engine (and basically every multi-window program that I've used) all work like this in regards to multiple windows and its great that Blender now does too (only thing I want is for it to [recognize which window is under the cursor ](https://streamable.com/7isso0) )

Kathryn Fawkes commented

2021-06-08 16:44:05 +02:00

Added subscriber: @Crazy

Kathryn Fawkes commented

2021-06-08 16:44:05 +02:00

I have to second what madog said with the new window setup - it's vastly interfering with my workflow, as I have three monitors, and have one window on each - usually the main window, material editor, and UV/misc editor. I'm not always using both the UV editor and the material editor at the same time, so I usually have a browser/explorer/photo/etc window covering one of the two, which worked great when the windows were treated independently; now when I interact with any of the other windows, it covers up my other applications with the editor that I'm not currently using, which is hardly useful. On top of that, since blender doesn't save multi-monitor UI setups, whenever I open blender I have to juggle windows around (since the main one likes to open behind one of the secondary windows), instead of just selecting the main window in the taskbar. While I can see why always-on-top functionality would be useful in certain cases, I think this would work better if we have a per-window pin feature instead of a global, non-toggle-able, always-on-top functionality. It's incredibly frustrating that when I click on one of the three windows, it boots all my other windows off the other screens.

Harley Acheson commented

2021-06-08 16:58:45 +02:00

@RayMairlot - I don't know whether I am missing something...Having two main windows might fix this (I haven't tried)

You should give that a try to see if that helps. "Window / New Window" versus "Window / New Main Window" give quite different results from each other now. Each main window controlling children, with separate grouping on taskbar, etc.

@Crazy - On top of that, since blender doesn't save multi-monitor UI setups, whenever I open blender I have to juggle windows around (since the main one likes to open behind one of the secondary windows)

It does now save the positions of multiple monitors. But only when they are arranged horizontally - You can have an unlimited number of windows spread over an unlimited number of monitors and they should come back where they were when you saved. They can sometimes be out by a few pixels when you have multiple monitors that differ in dpi or scale, but there is a patch to fix that. https://developer.blender.org/D10863

However, I mention this now works correctly when multiple monitors are arranged horizontally. If you have a vertical arrangement (where any monitor is above or below any other) there are issues that will be fixed if the following gets committed: https://developer.blender.org/D10637

> @RayMairlot - I don't know whether I am missing something...Having two main windows might fix this (I haven't tried) You should give that a try to see if that helps. "Window / New Window" versus "Window / New Main Window" give quite different results from each other now. Each *main* window controlling children, with separate grouping on taskbar, etc. > @Crazy - On top of that, since blender doesn't save multi-monitor UI setups, whenever I open blender I have to juggle windows around (since the main one likes to open behind one of the secondary windows) It does now save the positions of multiple monitors. But only when they are arranged horizontally - You can have an unlimited number of windows spread over an unlimited number of monitors and they should come back where they were when you saved. They can sometimes be out by a few pixels when you have multiple monitors that differ in dpi or scale, but there is a patch to fix that. https://developer.blender.org/D10863 However, I mention this now works correctly when multiple monitors are arranged horizontally. If you have a vertical arrangement (where any monitor is above or below any other) there are issues that will be fixed if the following gets committed: https://developer.blender.org/D10637

Ray Mairlot commented

2021-06-08 17:58:03 +02:00

In #69819#1173214, @Harley wrote:

@RayMairlot - I don't know whether I am missing something...Having two main windows might fix this (I haven't tried)

You should give that a try to see if that helps. "Window / New Window" versus "Window / New Main Window" give quite different results from each other now. Each main window controlling children, with separate grouping on taskbar, etc.

In that case I would like to request that the 'Global Scene' user preference be reintroduced to help keep the active scene synced in each window:

The benefit of 'Global Scene' is that you don't get into a situation where you're editing something on one monitor and wondering why you can't see the changes on the other, only to find that the other window is showing a different scene. 'Global Scene' makes sure all windows are updated to the same scene when the scene is changed in any window.

In addition to this I have just found that Workspaces also don't sync across multiple 'Main Windows', meaning any time I switch workspaces on one monitor I will have to manually switch other windows to a workspace for that monitor, e.g. I would have to have left and right monitor variants ('Left Monitor Sculpting' and 'Right Monitor Sculpting') for every workspace, which immediately makes workspaces less useful and more cumbersome to use.

Again, this is something that the Main/Secondary window concept had fixed compared to 2.79 and its 'Screens' concept which also had this issue.

> In #69819#1173214, @Harley wrote: >> @RayMairlot - I don't know whether I am missing something...Having two main windows might fix this (I haven't tried) > > You should give that a try to see if that helps. "Window / New Window" versus "Window / New Main Window" give quite different results from each other now. Each *main* window controlling children, with separate grouping on taskbar, etc. In that case I would like to request that the 'Global Scene' user preference be reintroduced to help keep the active scene synced in each window: >The benefit of 'Global Scene' is that you don't get into a situation where you're editing something on one monitor and wondering why you can't see the changes on the other, only to find that the other window is showing a different scene. 'Global Scene' makes sure all windows are updated to the same scene when the scene is changed in any window. In addition to this I have just found that Workspaces also don't sync across multiple 'Main Windows', meaning any time I switch workspaces on one monitor I will have to manually switch other windows to a workspace for that monitor, e.g. I would have to have left and right monitor variants ('Left Monitor Sculpting' and 'Right Monitor Sculpting') *for every workspace*, which immediately makes workspaces less useful and more cumbersome to use. Again, this is something that the Main/Secondary window concept had fixed compared to 2.79 and its 'Screens' concept which also had this issue.

Ray Mairlot commented

2021-10-21 16:17:20 +02:00

@Harley @JulianEisel

I would like to reiterate that the way child windows work now is still causing me issues and the suggested solution of having two 'Main' windows (instead of a Main and Secondary one) is still not viable unless workspaces sync across windows and the 'Global Scene' option, mentioned in my previous post, is restored.

I currently have the option of using two main windows, but then neither scenes nor workspaces sync (I could put up with the scene not syncing but not workspaces), or I have to put up with the previous issues I mentioned and the two new ones below:

In a Main Window and Secondary window setup, the 'System Console' (Window> Toggle System Console) is hidden whenever you click on either window. This makes it very hard to debug script output as whenever I run a script the output is hidden (due to clicking on the secondary window) and I have to keep bringing it to the front.
In a Main Window and Secondary window setup it takes two clicks to restore a program to the front that is behind either blender window (unless it was minimised, in which case it restores normally). Normally clicking on a taskbar icon for an open program immediately brings it to the front (on Windows 10). However, if a non-Main window has been clicked on first, it takes two clicks to restore it. The first click seems to minimise the program (still behind the blender window) and the second restores it.

I would be interested to know how people at the Blender Animation studio manage this, or maybe they just use large, single monitors?

Thanks.

@Harley @JulianEisel I would like to reiterate that the way child windows work now is still causing me issues and the suggested solution of having two 'Main' windows (instead of a Main and Secondary one) is still not viable unless workspaces sync across windows and the 'Global Scene' option, mentioned in my previous post, is restored. I currently have the option of using two main windows, but then neither scenes nor workspaces sync (I could put up with the scene not syncing but not workspaces), or I have to put up with the previous issues I mentioned and the two new ones below: 1. In a Main Window and Secondary window setup, the 'System Console' (Window> Toggle System Console) is hidden whenever you click on either window. This makes it very hard to debug script output as whenever I run a script the output is hidden (due to clicking on the secondary window) and I have to keep bringing it to the front. 2. In a Main Window and Secondary window setup it takes two clicks to restore a program to the front that is behind either blender window (unless it was minimised, in which case it restores normally). Normally clicking on a taskbar icon for an open program immediately brings it to the front (on Windows 10). However, if a non-Main window has been clicked on first, it takes two clicks to restore it. The first click seems to minimise the program (still behind the blender window) and the second restores it. I would be interested to know how people at the Blender Animation studio manage this, or maybe they just use large, single monitors? Thanks.

Philipp Oeser commented

2021-12-28 16:51:22 +01:00

Added subscribers: @slepy8, @lichtwerk

Julian Eisel removed their assignment 2022-01-27 19:01:33 +01:00

Julian Eisel commented

2022-01-27 19:01:33 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2022-01-27 19:01:33 +01:00

Although the exact status is a bit unknown to me, @Harley already addressed most points for the Windows platform, so at this point I think it's not a high priority task anymore. He will update the task shortly.
Plus, I'm personally not gonna be able to work on this any time soon either, so setting it as up for grabs.

Although the exact status is a bit unknown to me, @Harley already addressed most points for the Windows platform, so at this point I think it's not a high priority task anymore. He will update the task shortly. Plus, I'm personally not gonna be able to work on this any time soon either, so setting it as up for grabs.

Harley Acheson self-assigned this 2022-01-27 21:57:23 +01:00

Harley Acheson commented

2022-01-27 21:57:23 +01:00

Claiming. Will edit to show which parts are done on Windows, how things differ between platforms, etc.

Harley Acheson changed title from ~~Secondary window improvements~~ to Secondary Window Behaviors

2022-01-30 20:30:37 +01:00

Sam Morse-Brown commented

2022-04-20 18:24:17 +02:00

Added subscriber: @ParallelMayhem

Rey Leonard M. Amorato commented

2022-05-01 20:39:35 +02:00

Added subscriber: @RL

Sander commented

2022-11-25 08:41:20 +01:00

Added subscriber: @Sworly

Sander commented

2022-11-25 08:41:20 +01:00

This is still a major issue on MacOS: a 2 window setup has terrible UX, because the focus of the windows does not follow the mouse.

For instance if you hover the mouse over your second window and use the scroll wheel while the window has no focus, the window receives scroll input but not modifiers.
If you move the mouse to hover over an object on another window on another screen and use a shortcut key, nothing happens until you click the window menubar first to make it the active window.

I work with two 27" for large animations: dope sheet fills one screen, other panels the main screen. It's a very bad experience having to activate windows before you can send key input all the time.

This is still a major issue on MacOS: a 2 window setup has terrible UX, because the focus of the windows does not follow the mouse. - For instance if you hover the mouse over your second window and use the scroll wheel while the window has no focus, the window receives scroll input but not modifiers. - If you move the mouse to hover over an object on another window on another screen and use a shortcut key, nothing happens until you click the window menubar first to make it the active window. I work with two 27" for large animations: dope sheet fills one screen, other panels the main screen. It's a very bad experience having to activate windows before you can send key input all the time.

Ludvik Koutny commented

2022-11-25 09:45:34 +01:00

Are the secondary windows expected to remember their size? From this task description, it is not clear to me. But I always found it quite frustrating that user preference window would always reset its size when re-opened, even during the very same Blender session. User preferences are very bloated with lots of settings, so it's almost unusable at the default size, and therefore requires resizing every single time it's opened. This is an example of how it opens at 2560x1440 resolution:

It uses like 1/8th of the screen. And it never remembers the size and position user has changed it to.

Are the secondary windows expected to remember their size? From this task description, it is not clear to me. But I always found it quite frustrating that user preference window would always reset its size when re-opened, even during the very same Blender session. User preferences are very bloated with lots of settings, so it's almost unusable at the default size, and therefore requires resizing every single time it's opened. This is an example of how it opens at 2560x1440 resolution: ![image.png](https://archive.blender.org/developer/F13967899/image.png) It uses like 1/8th of the screen. And it never remembers the size and position user has changed it to.

Sander commented

2022-11-25 10:56:47 +01:00

My second window is always re-opened on the first display every time a file opens. That's not ideal.

Philipp Oeser removed the

Interest

User Interface

label 2023-02-10 09:25:09 +01:00

Sign in to join this conversation.