Creating a detached window makes the main window irreversibly loose focus in 2.93.2 + #92331

New Issue

Philipp Sokolov · 2021-10-19T08:57:35+02:00

Philipp Sokolov commented

2021-10-19 08:57:35 +02:00

System Information
Operating system: macOS Big Sur 11.5.2
Graphics card: Apple M1 8 core, Metal GPUFamily Apple 7

Blender Version
Broken:
2.93.2, 1eb06de260, master, 2021-08-03 05:58
2.93.5, a791bdabd0, master, 2021-10-05 12:04 (both ARM and Intel)
2.93.6 Release Candidate, 0930a70e81, master, 2021-10-06 10:52
3.0.0 Alpha, 452c78757f, master, 2021-10-17 17:10

Worked: 2.92.0, 02948a2cab, master, 2021-02-24 16:25

Short description of error
Creating a new detached window from any viewport by holding shift and dragging the corner
makes the main window loose focus without ability to regain it.
The focus can't be regained by clicking on the main window -- the newly created window stays focused instead.
The main window with the lost focus stays below the new window and can't be put on top. No hotkeys are working in the main window with the lost focus, however menus and objects are selectable.
The focus to the main window can only be regained by closing this newly created detached window.
When connecting a second monitor and dragging the new detached window there, the focus on the main window that stays on the main monitor remains lost with the same behaviour as described above. However, after dragging the main window to the secondary monitor as well, it becomes focused when clicking on it, comes on top of the new window and regains hotkey functionality. The new window can be focused as well by clicking on it. Dragging either of the windows back to the main monitor makes the main window loose focus again and become unfocused as described above.

Exact steps for others to reproduce the error
Based on the default startup:

Hold shift and drag the corner of the 3D viewport inwards to create a new detached window
When window is created observe it getting focus and the main window loosing focus
Click on the main window which is currently below the newly created detached window
4. Observe the main window staying unfocused and still staying below, with the menus and objects selectable but hot keys not working.
Connect a secondary monitor
Drag the focused window to the secondary monitor
Observe the main window still unable to be focused on with the hotkey functionality still lost
Drag the focused window back from the external monitor
Observe the main window becoming able to be focused on with the functionality regained
Drag either of the windows back to the secondary monitor
Observe the main window loose focus again

*edit:
Creating a detached window in blender 2.92.0, saving the file and then opening it in the 2.93.5 makes the windows work properly in that file, with the ability to change focus between them and hotkey functionality working.
Currently this is the only way to bypass this bug and make detached windows work as they used to.

**System Information** Operating system: macOS Big Sur 11.5.2 Graphics card: Apple M1 8 core, Metal GPUFamily Apple 7 **Blender Version** Broken: 2.93.2, 1eb06de2607a, master, 2021-08-03 05:58 2.93.5, a791bdabd0b2, master, 2021-10-05 12:04 (both ARM and Intel) 2.93.6 Release Candidate, 0930a70e8110, master, 2021-10-06 10:52 3.0.0 Alpha, 452c78757f44, master, 2021-10-17 17:10 Worked: 2.92.0, 02948a2cab44, master, 2021-02-24 16:25 **Short description of error** Creating a new detached window from any viewport by holding shift and dragging the corner makes the main window loose focus without ability to regain it. The focus can't be regained by clicking on the main window -- the newly created window stays focused instead. The main window with the lost focus stays below the new window and can't be put on top. No hotkeys are working in the main window with the lost focus, however menus and objects are selectable. The focus to the main window can only be regained by closing this newly created detached window. When connecting a second monitor and dragging the new detached window there, the focus on the main window that stays on the main monitor remains lost with the same behaviour as described above. However, after dragging the main window to the secondary monitor as well, it becomes focused when clicking on it, comes on top of the new window and regains hotkey functionality. The new window can be focused as well by clicking on it. Dragging either of the windows back to the main monitor makes the main window loose focus again and become unfocused as described above. **Exact steps for others to reproduce the error** Based on the default startup: 1. Hold shift and drag the corner of the 3D viewport inwards to create a new detached window 2. When window is created observe it getting focus and the main window loosing focus 3. Click on the main window which is currently below the newly created detached window **4. Observe the main window staying unfocused and still staying below, with the menus and objects selectable but hot keys not working.** 5. Connect a secondary monitor 6. Drag the focused window to the secondary monitor 7. Observe the main window still unable to be focused on with the hotkey functionality still lost 9. Drag the focused window back from the external monitor 10. Observe the main window becoming able to be focused on with the functionality regained 11. Drag either of the windows back to the secondary monitor 12. Observe the main window loose focus again ***edit:** Creating a detached window in blender 2.92.0, saving the file and then opening it in the 2.93.5 makes the windows work properly in that file, with the ability to change focus between them and hotkey functionality working. Currently this is the only way to bypass this bug and make detached windows work as they used to.

Philipp Sokolov commented

2021-10-19 08:57:35 +02:00

Added subscriber: @philippsokolov

blender-admin commented

2021-10-19 08:57:35 +02:00

#96103 was marked as duplicate of this issue

blender-admin commented

2021-10-19 08:57:35 +02:00

#88841 was marked as duplicate of this issue

blender-admin commented

2021-10-19 08:57:35 +02:00

#94346 was marked as duplicate of this issue

Philipp Sokolov changed title from ~~Creating a detached window makes the main window irreversibly loose focus~~ to Creating a detached window makes the main window irreversibly loose focus in 2.93.5 +

2021-10-19 09:12:00 +02:00

Philipp Sokolov changed title from ~~Creating a detached window makes the main window irreversibly loose focus in 2.93.5 +~~ to Creating a detached window makes the main window irreversibly loose focus in 2.93.2 +

2021-10-19 09:22:30 +02:00

Germano Cavalcante commented

2021-10-28 15:20:09 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2021-10-28 15:20:09 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Germano Cavalcante commented

2021-10-28 15:20:09 +02:00

Thanks for the report, I can confirm it on a Mac M1.
It's pretty inconvenient not to be able to use hotkeys in the main window.

Thanks for the report, I can confirm it on a Mac `M1`. It's pretty inconvenient not to be able to use hotkeys in the main window.

Philipp Sokolov commented

2021-10-29 12:03:52 +02:00

Thanks @mano-wii !

Yevgeny Makarov commented

2021-12-21 22:39:08 +01:00

Added subscriber: @jenkm

Yevgeny Makarov commented

2021-12-21 22:39:08 +01:00

be9842f65b

It's not clear to me why topbar's "New Window" and editor's "Duplicate into New Window" work differently,
for me it's the same feature. It probably works differently on Windows and makes some sense there.

So just revert back to how it was before this commit, for Mac at least:

diff --git a/source/blender/editors/screen/screen_ops.c b/source/blender/editors/screen/screen_ops.c
--- a/source/blender/editors/screen/screen_ops.c
+++ b/source/blender/editors/screen/screen_ops.c
@@ -1419,21 +1419,21 @@ static int area_dupli_invoke(bContext *C, wmOperator *op, const wmEvent *event)
 
   /* Create new window. No need to set space_type since it will be copied over. */
   wmWindow *newwin = WM_window_open(C,
                                     "Blender",
                                     area->totrct.xmin,
                                     area->totrct.ymin,
                                     area->winx,
                                     area->winy,
                                     SPACE_EMPTY,
                                     false,
-                                    true,
+                                    false,
                                     false,
                                     WIN_ALIGN_ABSOLUTE);
 
   if (newwin) {
     /* copy area to new screen */
     bScreen *newsc = WM_window_get_active_screen(newwin);
     ED_area_data_copy((ScrArea *)newsc->areabase.first, area, true);
     ED_area_tag_redraw((ScrArea *)newsc->areabase.first);
 
     /* screen, areas init */

be9842f65b It's not clear to me why topbar's "New Window" and editor's "Duplicate into New Window" work differently, for me it's the same feature. It probably works differently on Windows and makes some sense there. So just revert back to how it was before this commit, for Mac at least: ``` diff --git a/source/blender/editors/screen/screen_ops.c b/source/blender/editors/screen/screen_ops.c --- a/source/blender/editors/screen/screen_ops.c +++ b/source/blender/editors/screen/screen_ops.c @@ -1419,21 +1419,21 @@ static int area_dupli_invoke(bContext *C, wmOperator *op, const wmEvent *event) /* Create new window. No need to set space_type since it will be copied over. */ wmWindow *newwin = WM_window_open(C, "Blender", area->totrct.xmin, area->totrct.ymin, area->winx, area->winy, SPACE_EMPTY, false, - true, + false, false, WIN_ALIGN_ABSOLUTE); if (newwin) { /* copy area to new screen */ bScreen *newsc = WM_window_get_active_screen(newwin); ED_area_data_copy((ScrArea *)newsc->areabase.first, area, true); ED_area_tag_redraw((ScrArea *)newsc->areabase.first); /* screen, areas init */ ```

Harley Acheson commented

2021-12-21 23:19:41 +01:00

Added subscriber: @Harley

Harley Acheson commented

2021-12-21 23:19:41 +01:00

@jenkm

I'm not seeing this change in the commit you reference. But there were a lot of changes in there and in other patches at that time.

It's not clear to me why topbar's "New Window" and editor's "Duplicate into New Window" work differently,

AFAIK they shouldn't, but can vary by platform if you want. "New Main Window" should generally behave like an entirely separate window, as if it belonged to a different application. While "New Window" and "Duplicate into New Window" should act like children of the main window, so controlled by or subservient to the main window in whatever makes sense for the platform. But in all cases all windows should be usable at any time. That difference is controlled by that first argument - "toplevel".

The intent of "dialog" is to make visual changes to make the window appear like a temporary "dialog-like" window, optionally constraining input to just that window. Really just for actual dialogs, not real windows.

But that argument is not used on Windows at all yet. Which means your proposed change does not do any harm on Windows. So if that fixes this on Mac I'd say submit a patch. You'd just want to make it clear it is to fix this Mac issue, but add either me or Ray to sign off that it doesn't break Windows. And would probably need a check on Linux too.

> @jenkm I'm not seeing this change in the commit you reference. But there were a lot of changes in there and in other patches at that time. > It's not clear to me why topbar's "New Window" and editor's "Duplicate into New Window" work differently, AFAIK they shouldn't, but can vary by platform if you want. "New **Main** Window" should generally behave like an entirely separate window, as if it belonged to a different application. While "New Window" and "Duplicate into New Window" should act like children of the main window, so controlled by or subservient to the main window in whatever makes sense for the platform. But in all cases all windows should be usable at any time. That difference is controlled by that first argument - "toplevel". The intent of "dialog" is to make visual changes to make the window appear like a temporary "dialog-like" window, optionally constraining input to just that window. Really just for actual dialogs, not real windows. But that argument is not used on Windows at all yet. Which means your proposed change does not do any harm on Windows. So if that fixes this on Mac I'd say submit a patch. You'd just want to make it clear it is to fix this Mac issue, but add either me or Ray to sign off that it doesn't break Windows. And would probably need a check on Linux too.

Yevgeny Makarov commented

2021-12-21 23:44:37 +01:00

I'm not seeing this change in the commit you reference.

It looks like it was:
area_dupli_invoke > WM_window_open > wm_window_new with dialog = false
and it became:
area_dupli_invoke > WM_window_open with dialog = true

Maybe just a typo. I guess dialog = true is only needed for file selector.

> I'm not seeing this change in the commit you reference. It looks like it was: `area_dupli_invoke` > `WM_window_open` > `wm_window_new` with dialog = false and it became: `area_dupli_invoke` > `WM_window_open` with dialog = true Maybe just a typo. I guess dialog = true is only needed for file selector.

Harley Acheson commented

2021-12-22 00:32:19 +01:00

Maybe just a typo

Probably since it has no change on my platform.

I guess dialog = true is only needed for file selector

It probably has some change on Mac that you guys like. On windows I'd rather it behave just as a regular child window and not do any of the app modal dialog stuff. I don't mind little windows that just ask "yes" and "no" being modal but nothing too complex.

But again, give it a try with dialog true and false and see what you like. It is the Mac guys that get to decide which is better.

> Maybe just a typo Probably since it has no change on my platform. > I guess dialog = true is only needed for file selector It probably has some change on Mac that you guys like. On windows I'd rather it behave just as a regular child window and not do any of the app modal dialog stuff. I don't mind little windows that just ask "yes" and "no" being modal but nothing too complex. But again, give it a try with dialog true and false and see what you like. It is the Mac guys that get to decide which is better.

Yevgeny Makarov commented

2021-12-23 18:40:32 +01:00

Added subscriber: @dresban

Pratik Borhade commented

2022-01-25 05:33:50 +01:00

Added subscribers: @jean-martin-barbut, @lichtwerk, @ankitm, @PratikPB2123

Germano Cavalcante commented

2022-02-27 20:27:22 +01:00

Added subscriber: @brecht

Germano Cavalcante commented

2022-02-27 20:27:22 +01:00

This small change seems to do the trick:

diff --git a/intern/ghost/intern/GHOST_WindowCocoa.mm b/intern/ghost/intern/GHOST_WindowCocoa.mm
index 4a1b3c2fe16..54643865eed 100644
--- a/intern/ghost/intern/GHOST_WindowCocoa.mm
+++ b/intern/ghost/intern/GHOST_WindowCocoa.mm
@@ -152,8 +152,7 @@ - (GHOST_SystemCocoa *)systemCocoa
 
 - (BOOL)canBecomeKeyWindow
 {
-  /* Don't make other windows active when a dialog window is open. */
-  return (associatedWindow->isDialog() || !systemCocoa->hasDialogWindow());
+  return YES;
 }
 
 // The drag'n'drop dragging destination methods

Even reviewing the code in edffb0, the patch and the comments, I'm still not sure why non-dialog windows cannot be active if there is a dialog window.
@brecht, if I'm not mistaken you worked on this code, is this something for you to check?

This small change seems to do the trick: ``` diff --git a/intern/ghost/intern/GHOST_WindowCocoa.mm b/intern/ghost/intern/GHOST_WindowCocoa.mm index 4a1b3c2fe16..54643865eed 100644 --- a/intern/ghost/intern/GHOST_WindowCocoa.mm +++ b/intern/ghost/intern/GHOST_WindowCocoa.mm @@ -152,8 +152,7 @@ - (GHOST_SystemCocoa *)systemCocoa - (BOOL)canBecomeKeyWindow { - /* Don't make other windows active when a dialog window is open. */ - return (associatedWindow->isDialog() || !systemCocoa->hasDialogWindow()); + return YES; } // The drag'n'drop dragging destination methods ``` Even reviewing the code in edffb0, the patch and the comments, I'm still not sure why non-dialog windows cannot be active if there is a dialog window. @brecht, if I'm not mistaken you worked on this code, is this something for you to check?

Brecht Van Lommel commented

2022-02-27 22:38:20 +01:00

@mano-wii, a dialog window is blocking and modal. That's the standard definition in other UI toolkits, and it's the same in Blender. So that's why no other window can become active, the users must complete the task in the dialog window before doing other tasks.

The SCREEN_OT_area_dupli operator should not be creating a dialog window.

@mano-wii, a dialog window is blocking and modal. That's the standard definition in other UI toolkits, and it's the same in Blender. So that's why no other window can become active, the users must complete the task in the dialog window before doing other tasks. The `SCREEN_OT_area_dupli` operator should not be creating a dialog window.

Brecht Van Lommel commented

2022-02-27 22:40:51 +01:00

@jenkm's proposed change in #92331#1276749 looks good to commit to me.

Harley Acheson commented

2022-02-27 22:53:39 +01:00

Just to reiterate my earlier comment, and probably state the obvious, on the Windows platform we are choosing to do nothing special if the Blender window is created with isDialog. This is because Blender currently does not create any windows that we’d consider meeting the definition of “dialog” for us (small, simple, app-modal).

Just to reiterate my earlier comment, and probably state the obvious, on the Windows platform we are *choosing* to do nothing special if the Blender window is created with isDialog. This is because Blender currently does not create any windows that we’d consider meeting the definition of “dialog” for us (small, simple, app-modal).

Brecht Van Lommel commented

2022-02-27 23:21:14 +01:00

I think the file browser should be modal on all platforms, and at least when we initially added the new filebrowser window it was meant to be that way but not implemented on all platforms, not a deliberate choice. This summarizes the intended behavior at the time: D5810 #133638

There may have been other design discussions or decisions since though.

I think the file browser should be modal on all platforms, and at least when we initially added the new filebrowser window it was meant to be that way but not implemented on all platforms, not a deliberate choice. This summarizes the intended behavior at the time: [D5810](https://archive.blender.org/developer/D5810)#133638 There may have been other design discussions or decisions since though.

Harley Acheson commented

2022-02-28 00:23:51 +01:00

In #92331#1314525, @brecht wrote:
I think the file browser should be modal on all platforms, and at least when we initially added the new filebrowser window it was meant to be that way but not implemented on all platforms, not a deliberate choice. This summarizes the intended behavior at the time: D5810 #133638

There may have been other design discussions or decisions since though.

That's mostly why I mentioned it, because quite often we are not aware of differences between platforms.

On the Windows platform all the windows-related stuff is working so nicely now, including the behavior of File Browser, Preferences, etc. I'd hate to deliberately add blocking to a program meant to be as non-blocking as possible. Being app-modal is generally only a constraint to user behavior, without much benefit, except maybe when it is asking something important like "are you sure you want to do this scary thing?" LOL. How these windows are expected to behave can vary because of platform norms. But I probably should add add support for modal windows anyway, just in case.

> In #92331#1314525, @brecht wrote: > I think the file browser should be modal on all platforms, and at least when we initially added the new filebrowser window it was meant to be that way but not implemented on all platforms, not a deliberate choice. This summarizes the intended behavior at the time: [D5810](https://archive.blender.org/developer/D5810)#133638 > > There may have been other design discussions or decisions since though. That's mostly why I mentioned it, because quite often we are not aware of differences between platforms. On the Windows platform all the windows-related stuff is working so nicely now, including the behavior of File Browser, Preferences, etc. I'd hate to deliberately add blocking to a program meant to be as non-blocking as possible. Being app-modal is generally only a constraint to user behavior, without much benefit, except maybe when it is asking something important like "are you sure you want to do this scary thing?" LOL. How these windows are expected to behave can vary because of platform norms. But I probably should *add* add support for modal windows anyway, just in case.

Germano Cavalcante commented

2022-02-28 20:38:51 +01:00

In #92331#1314515, @brecht wrote:
@jenkm's proposed change in #92331#1276749 looks good to commit to me.

I tested the proposed solution in #92331#1276749, and noticed some changes that might not be desirable:

The new window is not always at the top (if you select the main one, the new window will be hidden behind)
The new window no longer follows the positioning of the last active window (it is as if it is no longer a child window)
If we want to keep these behaviors (and not change the behavior of dialog windows), we may need to think about a new design for the window creation API.

> In #92331#1314515, @brecht wrote: > @jenkm's proposed change in #92331#1276749 looks good to commit to me. I tested the proposed solution in #92331#1276749, and noticed some changes that might not be desirable: - The new window is not always at the top (if you select the main one, the new window will be hidden behind) - The new window no longer follows the positioning of the last active window (it is as if it is no longer a child window) If we want to keep these behaviors (and not change the behavior of dialog windows), we may need to think about a new design for the window creation API.

Brecht Van Lommel commented

2022-03-01 17:57:46 +01:00

I think we simply don't support these types of child windows that always stay on top. Due to the lack of proper focus it was already not possible in practice to make use of this, and it's not following Blender's non-overlapping design anyway.

Harley Acheson commented

2022-03-01 18:18:47 +01:00

@brecht wrote:
I think we simply don't support these types of child windows that always stay on top. Due to the lack of proper focus it was already not possible in practice to make use of this, and it's not following Blender's non-overlapping design anyway.

It is unclear what exactly you are referring to here.

"these types of child windows" on this thread would be child windows on Mac, which currently exhibit a specific problem that does not exist on Windows. These types of windows work well on Windows.

"Due to the lack of proper focus it was already not possible in practice to make use of this" - Again, these windows work very well for our Windows users now. A very small number have asked for changes to focus behavior but that is not a big complaint as our windows are behaving platform-compliant, so working as almost all users expect them to.

So not sure if your comment was specific to this issue on Mac, or was a response to my earlier comments and you are somehow wanting to remove functionality from Windows users.

> @brecht wrote: > I think we simply don't support these types of child windows that always stay on top. Due to the lack of proper focus it was already not possible in practice to make use of this, and it's not following Blender's non-overlapping design anyway. It is unclear what exactly you are referring to here. "these types of child windows" on this thread would be child windows on Mac, which currently exhibit a specific problem that does not exist on Windows. These types of windows work well on Windows. "Due to the lack of proper focus it was already not possible in practice to make use of this" - Again, these windows work very well for our Windows users now. A very small number have asked for changes to focus behavior but that is not a big complaint as our windows are behaving platform-compliant, so working as almost all users expect them to. So not sure if your comment was specific to this issue on Mac, or was a response to my earlier comments and you are somehow wanting to remove functionality from Windows users.

Harley Acheson commented

2022-03-01 20:10:54 +01:00

In #92331#1276749, @jenkm wrote:
be9842f65b
So just revert back to how it was before this commit, for Mac at least:

diff --git a/source/blender/editors/screen/screen_ops.c b/source/blender/editors/screen/screen_ops.c
--- a/source/blender/editors/screen/screen_ops.c
+++ b/source/blender/editors/screen/screen_ops.c
@@ -1419,21 +1419,21 @@ static int area_dupli_invoke(bContext *C, wmOperator *op, const wmEvent *event)
 
   /* Create new window. No need to set space_type since it will be copied over. */
   wmWindow *newwin = WM_window_open(C,
                                     "Blender",
                                     area->totrct.xmin,
                                     area->totrct.ymin,
                                     area->winx,
                                     area->winy,
                                     SPACE_EMPTY,
                                     false,
-                                    true,
+                                    false,
                                     false,
                                     WIN_ALIGN_ABSOLUTE);
 
   if (newwin) {
     /* copy area to new screen */
     bScreen *newsc = WM_window_get_active_screen(newwin);
     ED_area_data_copy((ScrArea *)newsc->areabase.first, area, true);
     ED_area_tag_redraw((ScrArea *)newsc->areabase.first);
 
     /* screen, areas init */

Yes, this patch is correct. Although this is less a revert of my changes, but more of a correction of my mistake there.

In my commit you'll see lots of changes to the window-opening code. The old area_dupli_invoke called a lot of code but ultimately used the old WM_window_open which always created non-temp windows with "dialog" set to false. The updated WM_window_open was given more options. so could be used with area_dupli_invoke, but is now called with "dialog" true, and "temp" false.

I was trying to make changes to this code without affecting other platforms, but failed in this case. I didn't notice because we don't currently implement "modal" behavior on Windows.

> In #92331#1276749, @jenkm wrote: > be9842f65b > So just revert back to how it was before this commit, for Mac at least: > > ``` > diff --git a/source/blender/editors/screen/screen_ops.c b/source/blender/editors/screen/screen_ops.c > --- a/source/blender/editors/screen/screen_ops.c > +++ b/source/blender/editors/screen/screen_ops.c > @@ -1419,21 +1419,21 @@ static int area_dupli_invoke(bContext *C, wmOperator *op, const wmEvent *event) > > /* Create new window. No need to set space_type since it will be copied over. */ > wmWindow *newwin = WM_window_open(C, > "Blender", > area->totrct.xmin, > area->totrct.ymin, > area->winx, > area->winy, > SPACE_EMPTY, > false, > - true, > + false, > false, > WIN_ALIGN_ABSOLUTE); > > if (newwin) { > /* copy area to new screen */ > bScreen *newsc = WM_window_get_active_screen(newwin); > ED_area_data_copy((ScrArea *)newsc->areabase.first, area, true); > ED_area_tag_redraw((ScrArea *)newsc->areabase.first); > > /* screen, areas init */ > ``` Yes, this patch is correct. Although this is less a revert of my changes, but more of a correction of my *mistake* there. In my commit you'll see lots of changes to the window-opening code. The **old** `area_dupli_invoke` called a lot of code but ultimately used the **old** `WM_window_open` which always created non-temp windows with "dialog" set to false. The updated `WM_window_open` was given more options. so could be used with `area_dupli_invoke`, but is now called with "dialog" true, and "temp" false. I was trying to make changes to this code without affecting other platforms, but failed in this case. I didn't notice because we don't currently implement "modal" behavior on Windows.

Harley Acheson commented

2022-03-01 20:34:54 +01:00

In #92331#1314515, @brecht wrote:
@jenkm's proposed change in #92331#1276749 looks good to commit to me.

@jenkm

I think you should just submit that patch, and set just me as reviewer (own code) and I can commit with you as author.

> In #92331#1314515, @brecht wrote: > @jenkm's proposed change in #92331#1276749 looks good to commit to me. @jenkm I think you should just submit that patch, and set just me as reviewer (own code) and I can commit with you as author.

Richard Antalik commented

2022-03-02 00:35:11 +01:00

Added subscriber: @Robw

Harley Acheson self-assigned this 2022-03-06 20:00:45 +01:00

Harley Acheson commented

2022-03-06 20:00:45 +01:00

Sorry, can't wait any longer. Will submit a patch.

blender-admin commented

2022-03-08 22:54:19 +01:00

This issue was referenced by 353376c783

This issue was referenced by 353376c783390a158c0a3cedf9887a4df06c7cf1

Harley Acheson commented

2022-03-08 22:57:55 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Harley Acheson closed this issue

2022-03-08 22:57:55 +01:00

Rob van Wees commented

2022-03-10 11:56:32 +01:00

Can confirm, newly created windows are no longer modal and multiple areas can be separated out from a window, all as expected.

Thank you @Harley!

There is some residual behavior: each window acts as a 'main application window'. It is possible to get the same (in my case: 'Quit') dialog in multiple windows.
Steps to reproduce:

separate out an area to its own window
hit CMD-Q with that window active
activate the 'old main' window
hit CMD-Q
You now have Quit dialogs in both windows.

This behavior does not seem to hinder application functionality, it is something users may need to be aware of.

Can confirm, newly created windows are no longer modal and multiple areas can be separated out from a window, all as expected. Thank you @Harley! There is some residual behavior: each window acts as a 'main application window'. It is possible to get the same (in my case: 'Quit') dialog in multiple windows. Steps to reproduce: - separate out an area to its own window - hit CMD-Q with that window active - activate the 'old main' window - hit CMD-Q You now have Quit dialogs in both windows. This behavior does not seem to hinder application functionality, it is something users may need to be aware of.

Harley Acheson commented

2022-03-10 21:38:50 +01:00

@Robw - Thank you @Harley!

You're welcome.

There is some residual behavior: each window acts as a 'main application window'. It is possible to get the same (in my case: 'Quit') dialog in multiple windows.
Steps to reproduce:

separate out an area to its own window

hit CMD-Q with that window active

activate the 'old main' window

hit CMD-Q
You now have Quit dialogs in both windows.

This behavior does not seem to hinder application functionality, it is something users may need to be aware of.

Interesting. I can see the same behavior in 3.0 (didn't check back further), but I don't think anyone else has noticed that yet. You could file a bug report for it, but not sure what the best behavior would be. It is nice to get the warning on the active monitor. And I don't think I'd want to remove dialogs from a window just because it loses focus. Seems harmless though. So just don't do that. LOL.

> @Robw - Thank you @Harley! You're welcome. > There is some residual behavior: each window acts as a 'main application window'. It is possible to get the same (in my case: 'Quit') dialog in multiple windows. > Steps to reproduce: > - separate out an area to its own window > - hit CMD-Q with that window active > - activate the 'old main' window > - hit CMD-Q > You now have Quit dialogs in both windows. > > This behavior does not seem to hinder application functionality, it is something users may need to be aware of. Interesting. I can see the same behavior in 3.0 (didn't check back further), but I don't think anyone else has noticed that yet. You could file a bug report for it, but not sure what the best behavior would be. It is nice to get the warning on the active monitor. And I don't think I'd want to remove dialogs from a window just because it loses focus. Seems harmless though. So just don't do that. LOL.

Rob van Wees commented

2022-03-11 01:04:38 +01:00

Seems harmless though. So just don't do that. LOL.

Was planning on doing exactly that 😄
Hence the "doesn't hinder - users may need to be aware of"

>>Seems harmless though. So just don't do that. LOL. Was planning on doing exactly that :smile: Hence the "doesn't hinder - users may need to be aware of"

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Creating a detached window makes the main window irreversibly loose focus in 2.93.2 + #92331