FS#1684 - Linux version fails to return focus following certain operations

[fgd3]

Dave,

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.

OpenCPN 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.

Fabbian

[bdbcat]

Fabbian...

Very interesting points regarding GUI "plumbing".

In OCPN, some UI dialogs are non-modal. Further, some of these dialogs are constructed as global static objects. When these dialogs are "dismissed" by the user, they are not closed and destroyed. Rather, they are simply hidden. That is, they are removed from view by wxWindow::Hide() method. They object and its message queue remain active, although invisible to the user. This allows them to be reactivated quickly by a wxWindow::Show() method. It also allows the dialogs to maintain state information even while invisible and inactive.

So, the question becomes: "What should the system do about the user focus when a non-modal dialog is hidden but not destroyed." The common solution for most desktop managers is to return the focus to the parent of the now-hidden dialog. After all, it makes no sense to leave the focus on a hidden window. Note that the decision on where to transfer the focus is up to the desktop manager functionality, wherever that is. One would expect the GUI to do the natural thing, i.e. what a "normal" user might expect. Or specifically, one expects the same behaviour as if it were a modal dialog being closed.

And sure enough, this is exactly what happens in all ports, other than the modern Ubuntu Unity desktop manager. This port appears to do nothing at all about transferring the focus. It seems to be left in limbo, possibly staying attached to a hidden window, so that it cannot be found nor moved without unnatural user actions.

Since the Ubuntu Unity desktop is the only one we have ever encountered that performs this way, from Win95 through to Android, I conclude it is a bug. And so we work around it after some hypothesis, experimentation, and test.

Hope this helps.

Dave

[fgd3]

Thanks, Dave, for your explanation. I agree the Ubuntu Unity behavior appears to be a bug. I guess the only solution to the focus issue is to explicitly transfer focus to the parent (chart) window when you hide one of the others. That way you're safe no matter what the window manager does.

What happens when a modal window (Settings or Print) is dismissed by the user? Is it closed or merely hidden? I suppose it doesn't make any difference with regard to focus--to be safe you still need to explicitly transfer focus back to the parent window.

The Windows paradigm that the active window is always on top and the top window is always active is so widely accepted that most people don't know there was ever another approach. It's unfortunate, but I guess we're stuck with it now. Everyone is accustomed to things working the Windows way.

Fabbian