Triggering Set Number dialog causes Configure Page Labels dialog to prematurely close (Windows)

[chenzw95]

On Windows, while cycling through the "Number" column in the Configure Page Labels dialog, when the Set Number / Enter Page Number dialog is triggered, the parent Configure Page Labels dialog closes prematurely.

This leads to a situation where the user enters a custom page number, clicks Ok, and ends up needing to re-open the Configure Page Labels dialog again.

This bug happens even if the user clicks Cancel on the Set Number dialog (parent Configure Page Labels closes first prematurely), and does not happen on macOS.

I am not 100% sure if is the correct fix, but I managed to solve this in my tests by modifying L1535 of src/guiguts/widgets.py, originally self.transient(root()), to point towards the widget's parent window instead:

self.transient(parent)

[chenzw95]

I just realised I should have checked the obvious first - the Configure Page Labels dialog (PageDetailsDialog) doesn't close prematurely - my mistake. The dialog moves backwards in z-order relative to the main guiguts window. I forgot to check my taskbar to look for the missing window.

This shouldn't affect the fix, regardless.

[srjfoo]

I just realised I should have checked the obvious first - the Configure Page Labels dialog (PageDetailsDialog) doesn't close prematurely - my mistake. The dialog moves backwards in z-order relative to the main guiguts window. I forgot to check my taskbar to look for the missing window.

This shouldn't affect the fix, regardless.

If you right-click on the title bar, you should be able to pin the dialog to the top. That is, as long as you don't cancel out of the dialog or press the enter button to apply changes (both of which will close the dialog), it'll stay visible above the main text window.

[chenzw95]

Yeah, I could do that, but there is an inconsistency in the behavior across platforms. This behavior (of PageDetailsDialog moving behind the main window) happens only on Windows, and not macOS.

I would expect the windows' z-orders to be:

1. Main window
2. PageDetailsDialog
3. askinteger (Set Number)

But this happens instead:

1. PageDetailsDialog
2. Main window
3. askinteger (Set Number)

[srjfoo]

I'm obviously not understanding what you mean. The point of being able to pin dialogs is to keep them in front of the main window. Even on macOS, if I don't have a dialog pinned, it will disappear behind the main window in z-order if the x-y coordinates are completely within the main window. So with this configuration (that is, with the dialog pinned), I can not pull the main window in front of the dialog:

[chenzw95]

The issue is that the Configure Page Labels dialog fails to return to the front of the main window after the Set Number dialog has been dismissed (be it OK or Cancel).

The workflow is:

1. File -> Project -> Configure Page Labels
2. Configure Page Labels (PageDetailsDialog) opens
3. I toggle the number of a page such that I am prompted for a user-defined page number ("Set Number", the AskStringDialog)
4. I enter a page number, close this dialog
5. (problem arises here) I expect to be seeing the Configure Page Labels dialog in front of the main window, and not need to invoke the taskbar again to bring it back to view.

(edit: I never interacted with nor clicked on any part of the root window during the above steps)

Here is a recording of the issue on Windows: https://www.dropbox.com/scl/fi/o787wl4jkq0arhdac1nar/2026-02-21_18-06-15.gif?rlkey=hs0hhov01sto3ef5qpavdl7tx&dl=0

And now that I look carefully at my instance of guiguts on macOS, even on macOS the bug manifests in a subtly different way: the Configure Page Labels dialog disappears behind the main program window while the Set Number dialog is open, and returns to view after the Set Number dialog is dismissed. If you were to invoke App Expose / Mission Control while the Set Number dialog is open, you can see that the Set Number dialog belongs to the same window group as the root program window (instead of the same window group as the invoking Configure Page Labels dialog).

More importantly, I tested a local patched copy with transient(parent), and that does resolve the issue on Windows.

[windymilla]

Sorry for the (timezone-related) delay in responding.

@chenzw95 - I haven't yet attempted to reproduce what you are describing, but I'm not surprised by it. The AskString dialog was added relatively recently to GG2 because the built-in simpledialog.askstring method does not respect dark mode on Windows, and it also interprets "010" as "8" instead of "10" (causing user reports). The error you have found is the only place that such a dialog is popped from another dialog (as opposed to directly from the main window, like "Goto Page Number"). As you've said, when being popped from a dialog, it should make itself "transient" with respect to its parent, which I expect the built-in one did automatically. I definitely omitted that from my implementation.

I'll test out your fix on my system, and also ask @srjfoo to test it on her Mac, and if all is OK, I'll get it merged in. Many thanks for reporting the problem, and even more thanks for fixing it 😄

[windymilla]

@chenzw95 - I've confirmed the bad behavior on Windows, and that your fix corrects it (implemented in PR #1737), and that there is nowhere else in the code that does transient(root()) where the "parent" may not be the root window. Thanks again