Non-modal settings window loses focus after accepting dialog

[n8bot]

Version

2.4.0-beta3 stock prusaslicer build I promise I did not break it

Operating system type + version

Win 10 64

Behavior

When using non-modal settings, the focus is returned to the main window when a dialog is dismissed/accepted. E.g., when a profile itself is saved, the focus immediately returns to main window. When the ramming settings dialog is entered, there is a notification about the setting being for experts, when you click OK, the main window regains focus, so the ramming settings window is lost and seems like it is closed by error, when it's just under the window.

This seems related to the recent focus changes targeted to help linux, but I have not confirmed that is the case.

As a side note:

I noticed that on user profiles (not system profiles), there are two settings that always have the orange unlocked icon, even though they are at the system defaults:

[bubnikv]

Yes, I see the issue. We are trying to work around a wxWidgets quirk. I am discussing at wx-users list. so 4. 12. 2021 v 21:49 odesílatel n8bot ***@***.***> napsal:

…

Version 2.4.0-beta3 stock prusaslicer build I promise I did not break it Operating system type + version Win 10 64 Behavior When using non-modal settings, the focus is returned to the main window when a dialog is dismissed/accepted. E.g., when a profile itself is saved, the focus immediately returns to main window. When the ramming settings dialog is entered, there is a notification about the setting being for experts, when you click OK, the main window regains focus, so the ramming settings window is lost and seems like it is closed by error, when it's just under the window. This seems related to the recent focus changes targeted to help linux, but I have not confirmed that is the case. As a side note: I noticed that on user profiles (not system profiles), there are two settings that always have the orange unlocked icon, even though they are at the system defaults: [image: image] <https://user-images.githubusercontent.com/22458343/144724153-3aea54f3-c2e8-47c9-9a24-c4baaab1aef7.png> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7419>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMPSIZWZE524FXKC6YL5UDUPJ5EFANCNFSM5JL6RTYA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[bubnikv]

hopefully fixed for good with bfce4f6

[n8bot]

The originally described issue is fixed. However, when the "Supports work better if..." dialog comes up, while in a modal settings menu, the same problem occurs.

[bubnikv]

However, when the "Supports work better if..." dialog comes up, the same

problem occurs. What same problem occurs? This one?

#6992

ne 5. 12. 2021 v 18:51 odesílatel n8bot ***@***.***> napsal:

…

The originally described issue is fixed. However, when the "Supports work better if..." dialog comes up, the same problem occurs. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#7419 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMPSIYCZM4FHZLE66HN6TDUPORB7ANCNFSM5JL6RTYA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[n8bot]

No, sorry, the focus is brought to the main window, when you click "no" or whatever.

The ramming settings dialog is fixed, and the save profile dialog is fixed... but when the "support work better if..." dialog comes up, the focus problem described in this issue is still there.

[n8bot]

Just to correct myself slightly: with the "Support works better..." dialog, the non-modal settings loses focus IMMEDIATELY when that dialog pops up, and then the focus is returned to the main window, not the non-modal settings window.

To illicit this dialog message, Edit some user profile that is new, save it in a state where Detect bridging perimeters is disabled, and support generation is also disabled. Once it is saved in that state, try to enable support generation, and the "Support works better..." dialog should pop up. Since this happens only once per profile (thank you!) you have to set up the scenario correctly to ensure you see it. I'm guessing you know this, but just to refresh it in your mind because the app is complex so it might be nice to have the exact steps right here.

[n8bot]

I suppose it is because this dialog is of type MessageDialog and not wxMessageDialog:

PrusaSlicer/src/slic3r/GUI/ConfigManipulation.cpp

Lines 163 to 183 in bfce4f6

	if (config->opt_bool("support_material")) {
	// Ask only once.
	if (!m_support_material_overhangs_queried) {
	m_support_material_overhangs_queried = true;
	if (!config->opt_bool("overhangs")/* != 1*/) {
	wxString msg_text = _(L("Supports work better, if the following feature is enabled:\n"
	"- Detect bridging perimeters"));
	if (is_global_config)
	msg_text += "\n\n" + _(L("Shall I adjust those settings for supports?"));
	MessageDialog dialog(nullptr, msg_text, _L("Support Generator"), wxICON_WARNING | (is_global_config ? wxYES | wxNO : wxOK));
	DynamicPrintConfig new_conf = *config;
	auto answer = dialog.ShowModal();
	if (!is_global_config || answer == wxID_YES) {
	// Enable "detect bridging perimeters".
	new_conf.set_key_value("overhangs", new ConfigOptionBool(true));
	}
	//else Do nothing, leave supports on and "detect bridging perimeters" off.
	apply(config, &new_conf);
	}
	}
	}

[Edit: can confirm, changing type to wxMessageDialog fixes the focus issue. However, the dialog is now not dark-themed.]

[n8bot]

... and now I realize that the dialog pops up EVERY TIME you enable support generation, if detect bridging perimeters is disabled...

Please... can we just NOT with these dialogs? There MUST be some better way to communicate the intended use of settings... because these dialogs are nothing but problems. Do they benefit anybody?

[Edit: the reason the message appears every time you enable supports, is because of the else statement I left off:

PrusaSlicer/src/slic3r/GUI/ConfigManipulation.cpp

Lines 183 to 186 in bfce4f6

	}
	else {
	m_support_material_overhangs_queried = false;
	}

If else statement is omitted, the dialog works correctly. It asks only once, and only under the conditions it states.

With the else statement, every time some other thing updates the config, the check is set back to false so it asks again.

[n8bot]

The "Support works better, if..." dialog also enters an endless loop...

If you are in a scenario where the dialog has asked you once already if you want to detect bridges, and you select no... then you add a modifier to a model. Then, you attempt to add the setting Fuzzy Skin, it will bring up the endless loop dialog -- only OK button, which dismisses it then it pops back up.

Sorry this is no longer directly related to this issue, but it kinda seems easiest to keep it all here.

[n8bot]

@bubnikv @YuSanka (sorry for ping, this issue is closed so I thought this might be necessary to draw attention)

We have another dialog that steals focus from non-modal settings, then returns it to the main frame:

When you click on the name of a setting, with a hyperlink: