In your last Tracker comment you used some terms I didn't understand and I need a little clarification. I didn't think I should clutter up the Tracker comments with this discussion.
You wrote "Specifically, focus should return to the parent window when a non-modal child window is hidden."
I had to Google
"non-modal child window" and do a little studying. The Settings and Print windows are modal. The Route
Manager and Object Query windows are non-modal. The Change Color Scheme button doesn't open a window at all.
I am confused by your use of "hidden". You seem to be using "hiding" as synonymous with "closing". I thought a window was hidden when it remained open but was obscured from view by another window on top of it. In Windows when I click on another window it becomes active and (with rare exceptions) comes to the front. Focus is transferred to the active window by the mouse click so the child window has nothing to do with where focus is transferred.
is one of those rare exceptions. In OpenCPN
the non-modal windows are not hidden (using my understanding of the term) when I click in the chart window. The chart is centered around the point of the mouse click, focus is transferred to the chart window, but the child window remains on top. To close the child window I have to click on a button or the close gadget, which restores focus to the child window.
Am I right that hiding and closing windows are different actions that require different responses? Why are some OpenCPN windows modal and others non-modal? Why do we need to access the chart window when the Object Query window is open?
I think I understand why the Route
Manager window is non-modal. When I open the Properties window for a route and click on a route point the chart moves that point to the center. It's actually not very useful unless I close the Route Manager window and resize and move the Properties window out of the way, because the window normally obscures the central area of the chart window, but at least I understand why it works that way, I think.
If you can take the time a little discussion about these issues would help me understand why the program was designed as it was.
The first GUI that I worked with, AmigaDOS, didn't always make the window on top active. Instead of minimize, maximize, and close gadgets it had gadgets for move to front, move to back, and close. One problem that eliminated was focus stealing by alerts. If you were typing on a document and the system posted a notification the alert appeared in front of everything else but the text you were typing continued going to the active window. Once you noticed the alert you could choose to respond to it as you wished. Often enough the alert warned of an impending crash and it could be pushed to the back so you could finish the other tasks you had open before the system went down.
Another effect I found useful was the ability to keep one document on top while typing into another document that was partially visible beneath it. It saved a lot of effort resizing windows so the relevant portions of both windows could be visible at the same time. With a lot of Windows applications giving up valuable screen
space to toolbars and such it can be impossible to keep the relevant parts
of two windows in view at the same time.
The main advantage to the AmigaDOS approach was the user had exclusive control over focus. When a window closed the user had to click in another window to make it active. Occasionally it required extra steps to bring the active window to the front. If the upper right corner of the window were not visible you might have to push a lot of other windows to the back until the one you wanted appeared on top. Then you had to remember to click in that window to make it active. The last window pushed to the back was active until you transferred focus to the one in front.