Cruisers Forum

Go Back   Cruisers & Sailing Forums > Seamanship, Navigation & Boat Handling > OpenCPN
Cruiser Wiki

Join CruisersForum Today

Thread Tools Rate Thread Display Modes
Old 29-05-2016, 06:11   #1
Registered User

Join Date: Jun 2010
Location: St. Petersburg, Florida
Boat: Gemini 3200
Posts: 537
FS#1684 - Linux version fails to return focus following certain operations


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.

fgd3 is offline   Reply With Quote
Old 29-05-2016, 06:44   #2
Marine Service Provider
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,465
Re: FS#1684 - Linux version fails to return focus following certain operations


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.

bdbcat is offline   Reply With Quote
Old 29-05-2016, 22:54   #3
Registered User

Join Date: Jun 2010
Location: St. Petersburg, Florida
Boat: Gemini 3200
Posts: 537
Re: FS#1684 - Linux version fails to return focus following certain operations

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.

fgd3 is offline   Reply With Quote


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Keyboard focus issues under Linux nkiesel OpenCPN 2 13-10-2015 23:02
Bug: Grib plugin fails to load on beta Version 3.1.1319 Build 2013-01-19 AlainT OpenCPN 5 01-02-2013 03:09
Cessation of Major Sanding Operations Wotname Construction, Maintenance & Refit 3 26-10-2008 06:29
PDQ operations shut down for now? scotte Multihull Sailboats 16 26-03-2008 08:35
Sailing Focus - Are discussions loosing focus? jemsea Forum Tech Support & Site Help 30 06-10-2006 22:40

Our Communities

Our communities encompass many different hobbies and interests, but each one is built on friendly, intelligent membership.

» More about our Communities

Automotive Communities

Our Automotive communities encompass many different makes and models. From U.S. domestics to European Saloons.

» More about our Automotive Communities

Marine Communities

Our Marine websites focus on Cruising and Sailing Vessels, including forums and the largest cruising Wiki project on the web today.

» More about our Marine Communities

Copyright 2002-2015 Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 17:18.

Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2016, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2016, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.