prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.75k stars 1.93k forks source link

Slicer dialogs open as system modal dialogs #1974

Open mgg4 opened 5 years ago

mgg4 commented 5 years ago

Version

1.42.0-alpha7

Operating system type + version

Windows 10

3D printer brand / version + firmware version (if known)

Prusa i3 Mk3 with MMU2

Behavior

When starting Slic3r, there are occasionally dialogs that pop up when there are configuration updates available. These dialogs are opening as system modal dialog boxes, which causes them to steal the input focus. If I am working in another window, this causes problems as it interprets inputs intended for another program, and possibly does something in Slic3r that I don't want to do.

This is not a new feature request. It is a Bug Report.

Project File (.3MF) where problem occurs

N/A

bubnikv commented 5 years ago

I checked the code (wxWidgets and Slic3r) and I did not find any system modal attribute.

When starting Slic3r, there are occasionally dialogs that pop up when there are configuration updates available.

Such a dialog shall open at the application startup only. How could such a dialog steal your focus? Does the application startup take so long that you get distracted and you switch to another application?

mgg4 commented 5 years ago

--Mark

On Mar 24, 2019, at 6:32 AM, bubnikv notifications@github.com wrote:

I checked the code (wxWidgets and Slic3r) and I did not find any system modal attribute.

When starting Slic3r, there are occasionally dialogs that pop up when there are configuration updates available.

Such a dialog shall open at the application startup only. How could such a dialog steal your focus? Does the application startup take so long that you get distracted and you switch to another application?

It has happened. I don’t get distracted, but while getting ready to bring a design from Fusion, if I notice Slic3r isn’t open, I double click to start it, and then go back to Fusion to finish exporting the design. Normally this causes no problem, but on one occasion the Slic3r dialog about new configurations opened just in time to steal the “Enter” keystroke meant for Fusion. This caused the Slic3r dialog box to close instantly, with no chance to read it.

In this case it caused no damage, but other dialogs opening like that could ask to take actions I’d prefer to defer. In these cases, having the dialog steal input focus is an undesirable behavior.

I’ve been writing code professionally for 40 years. One of the first things I learned is, “Never surprise your customer.” Well, I was surprised by the focus being stolen, so I thought you’d want to know.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

bubnikv commented 5 years ago

The dialogs are not open as system dialogs. The problem is, that the application opens up and then it gets focus. I experienced this with many Windows applications, not just Slic3r.

I personally program for Windows for about 18 years and I would have to dig out on the internet, how the current Windows handles application start up, if one happens to decide to not wait for the application to open up, but to work in the other application until the first application initializes and opens its first window. I would be thankful for an advice of how a good Windows application shall behave.

On Sun, Mar 24, 2019 at 5:01 PM mgg4 notifications@github.com wrote:

--Mark

On Mar 24, 2019, at 6:32 AM, bubnikv notifications@github.com wrote:

I checked the code (wxWidgets and Slic3r) and I did not find any system modal attribute.

When starting Slic3r, there are occasionally dialogs that pop up when there are configuration updates available.

Such a dialog shall open at the application startup only. How could such a dialog steal your focus? Does the application startup take so long that you get distracted and you switch to another application?

It has happened. I don’t get distracted, but while getting ready to bring a design from Fusion, if I notice Slic3r isn’t open, I double click to start it, and then go back to Fusion to finish exporting the design. Normally this causes no problem, but on one occasion the Slic3r dialog about new configurations opened just in time to steal the “Enter” keystroke meant for Fusion. This caused the Slic3r dialog box to close instantly, with no chance to read it.

In this case it caused no damage, but other dialogs opening like that could ask to take actions I’d prefer to defer. In these cases, having the dialog steal input focus is an undesirable behavior.

I’ve been writing code professionally for 40 years. One of the first things I learned is, “Never surprise your customer.” Well, I was surprised by the focus being stolen, so I thought you’d want to know.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/Slic3r/issues/1974#issuecomment-475972508, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5Iwzqur8cTc0uvQdASiYxTTfmLzGsks5vZ6FKgaJpZM4b4rA_ .

tillmanjr commented 2 years ago

Me trying not to rant and complain about my focus being stolen

This is an issue in Windows -though it's lessened- and macOS (up through at least Monterey). Setting aside start up related launches an application load is normally user initiated with the intent to interact with the application. In other words, autofocus on launch for an application makes sense - mostly anyways. Stealing focus at any other time -other than certain critical events- is simply inexcusable (maybe exceptions for explicitly set by user option to allow specific cases and the default is always disallow).

Nonetheless, it seriously pi$$es me off when it happens.

Userland things

TweakUI had a toggle that blocked focus stealing and it worked pretty well. Sadly, TweakUI is long gone (hmm, maybe I should dbl-check) The ForegroundLockTimeout key is often set to 0. Increasing it to some decent value can help significantly - mine is set to 0x30d40-. It's not perfect, but helps and stomps all over Outlook's incredibly annoying stealing.

Coding around the launch external app focus pain

If your app needs to spawn an application but you don't want it to steal focus then call the winuser fn LockSetForegroundWindow before you spawn the other application.

There are other tricks, but much messier (and my Windows programming chops are becoming quite stale)