While any type of dialog window is opened (except for the find and replace, and about dialog) from a Mousepad window, all other Mousepad windows will be blocked from any inputs. Regardless of whether they were already opened, or are newly opened.
I guess it's kind of on purpose, although I agree it feels wrong when multiple windows are open. FWIW, in the HIG on the wiki[1] if you interpret "system modal" as "application modal" I guess this part is related: "Do not use system modal windows (blocking interaction with *all* windows)" And this is sort of related: "Make windows modal only if interaction with other parts of the application could cause problems" But I think Mousepad interprets "could cause problems" as "would make any sense", at least when only considering a single window. [1]: http://wiki.xfce.org/dev/hig/general
(In reply to Matthew Brush from comment #1) > I guess it's kind of on purpose, although I agree it feels wrong when > multiple windows are open. I had a mousepad window with an opened modal in the background somewhere (not visible), which I had forgot about. And then when I opened a new one, I was wondering what's the deal, whether the process is stopped, or some error occured, or what. It was a few minutes until I discovered the cause. So the other side of the problem is that the blocked window doesn't make it clear what is really happening, there is no indication whatsoever. As I remember, in Windows there is a sound, and the parent window flashes a few times. I suppose however this aspect is more relevant to the window manager itself.
FWIW I work around this by starting mousepad with the --disable-server option. I don't know what the point of the server is anyway... hopefully I'm not missing out on too much ;)
Created attachment 8465 proposed patch Adding the application window to its own window group resolves the bug. Mousepad runs as a single application that can handle multiple document windows. This behavior can be disabled by starting Mousepad with the --disable-server option or by compiling it without D-Bus support. As mentioned in the previous comment, the bug is specific to the single application case.
What is the effect, if any, on the normal single-instance case where `--disable-server` isn't used? The reason I ask is because I'm not familiar with GTK+ window groups and I noticed the new code isn't guarded for the usual case. Stylistically, IMO, it would be nicer to store the window group in its own variable and using that rather than hiding the constructor in the function call arguments and pulling it back out with another function embedded in arguments. ```c GtkWindowGroup *window_group = gtk_window_group_new (); gtk_window_group_add_window (window_group, GTK_WINDOW (window)); g_object_unref (window_group); ``` This just seems easier to read to me, but I could be wrong. Maybe it's just because I've been burned by the undefined order of argument evaluation in C, not that it applies here.
"A GtkWindowGroup restricts the effect of grabs to windows in the same group, thereby making window groups almost behave like separate applications." Based on that description it should not have any negative effect. Maybe it is still worth to make the part conditional, or at least clarify with a comment that the window group is only needed when using the server feature. For the code styling, it makes sense to pick your variant.
Theo Linkspfeifer referenced this bugreport in commit c0cc9c74041b1c6c281461f5b18cf2dd4011d039 Make dialog windows modal only for parent window (Bug #10488) https://git.xfce.org/apps/mousepad/commit?id=c0cc9c74041b1c6c281461f5b18cf2dd4011d039
Merged with the updated code styling, thanks.