In my original reply of suggestions to try, I was working on the
assumption that the user had inadvertently raised focus while the
controlling window was generated. The only way around that is to not
touch anything till all windows load.
But if a window that demands control is not also 'sticky' to the top of
the window stack, I'd think that is a bug. It might be a GTK bug, but
this might be a GnuCash bug if GC is using the wrong window type for
that 'controlling' window which is demanding user action before giving
up focus to other windows for the app.
Personally, I don't use full screen and *none* of the non-main windows
*ever* steal focus/control or demand user interaction before I can click
anywhere else. So perhaps there is something else at play.
Regards,
Adrien
On 5/18/22 8:40 AM, Tommy Trussell wrote:
Yes, it's probably true I could use the keyboard to navigate to whichever
GnuCash window is blocking the startup. However it is impossible to tell by
sight which window is the culprit. So I find myself clicking around until I
find the one that responds. And as previously mentioned, for some reason it's
not always the one on top, as it should be.
_______________________________________________
gnucash-user mailing list
[email protected]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
