Page MenuHome

Secondary window improvements
Open, Confirmed, HighPublic

Tokens
"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.
Authored By

Description

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.

Details

Type
To Do

Event Timeline

William Reynish (billreynish) lowered the priority of this task from Needs Triage by Developer to Confirmed, 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: 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.

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.