Page MenuHome

Secondary window improvements
Confirmed, HighPublicTO DO

Authored By
William Reynish (billreynish)
Sep 12 2019, 11:06 PM
"Orange Medal" token, awarded by kynu."Burninate" token, awarded by tako."Burninate" token, awarded by chironamo."Love" token, awarded by russ1642."Love" token, awarded by Kickflipkid687."Love" token, awarded by APEC."Love" token, awarded by Juangra_Membata."Like" token, awarded by Shimoon."Love" token, awarded by Oskar."Love" token, awarded by zyzzxander."Like" token, awarded by mfink."Love" token, awarded by Tetone."Love" token, awarded by Peps."Love" token, awarded by lcs_cavalheiro."100" token, awarded by fiendish55."Love" token, awarded by bnzs."Love" token, awarded by jonathanl."Love" token, awarded by 245."Love" token, awarded by galenb."Yellow Medal" token, awarded by symstract."Like" token, awarded by erickblender."Love" token, awarded by reguza64."Love" token, awarded by 0o00o0oo."Yellow Medal" token, awarded by Lumpengnom."Yellow Medal" token, awarded by rawalanche."Orange Medal" token, awarded by Zino."Yellow Medal" token, awarded by irfan.


While we definitely value and will stick to the non-blocking paradigm for the majority of cases, there are workflows that could be improved with the following suggestions.

This is especially pressing with the latest file browser changes which now uses a separate window, as well as for the the Preferences, Drivers, Info window and any other secondary windows opened manually by users.

In Blender, we already support basic multi-window functionality, but to make this work well, we’ll need to make some key improvements:

  • Secondary and temporary windows should appear above other Blender windows, but not on top of all the windows of all other apps
  • Temporary windows (open/save dialogs) could block the underlying windows until they have been closed or dismissed.
  • Temporary windows should not steal each other’s windows
  • Temporary windows should remember their last used size, and not reset to the default size every time they are opened.
  • Bring all Blender windows to the front when the main Blender window is activated.
  • 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)
  • On Windows & Linux, don't let secondary windows appear in the task bar (main windows of course should still appear here)

Less important, but maybe nice:

  • Make secondary windows use slimmer title bar, to make them visually different from the main Blender window.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
William Reynish (billreynish) lowered the priority of this task from 90 to High.Sep 12 2019, 11:06 PM
William Reynish (billreynish) created this object with edit policy "BF Blender (Project)".

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.

@KiJeon (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 (billreynish) 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.

@KiJeon (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?

Let's add fixing this: 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.

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

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.

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: @William Reynish (billreynish), @Pablo Vazquez (pablovazquez), @Campbell Barton (campbellbarton), @Brecht Van Lommel (brecht) would you be fine with me moving forward that way?

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.

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.

@Campbell Barton (campbellbarton) 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.

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?

@ogierm (ogierm) That is not related to secondary windows.

With these improvements I have an idea about the 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.

Looking at this on the Windows side, @Julian Eisel (Severin)'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:

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.

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: rB396d39c6b904

any updates on the task?