Bug 45025 - Key and front window handling is naive and wrong...
Key and front window handling is naive and wrong...
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: sawfish (Show other bugs)
7.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Mason
David Lawrence
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-19 15:14 EDT by John Nelson
Modified: 2007-04-18 12:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-19 15:14:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Nelson 2001-06-19 15:14:16 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9)
Gecko/20010505

Description of problem:
This bug covers one of the major gripes I have with just about every
window-based GUI ever made (except NeXTStep which got it right)...

Both KDE and Gnome under every version of Linux I've used assume that the
"key window" and the "front window" are the same.  Because of this
assumption, when windows are created (such as launching a program), the
first document window is created as the front window.  The problem with
this is that the user may be typing into another window... when the new
window pops up it brings itself forward, steals all input from the user,
buries the previous window and makes itself both front and key.

This pretty much makes life miserable becase now the user has to go hunting
for the window he or she was interacting with.  Of course the interaction
and keystrokes typed into the old window are lost and productivity and user
enjoyment are drastically reduced.

Windows does this as do all of the Linux desktops I've used and its really
very annoying and naive.  Just because I run a program or create a new
document DOES NOT mean I necessarily want it forced into my face since I
may be doing work someplace else.

NeXTStep got it right because this OS had a very good model for separating
key and front windows as well as tiering its windows.  You could type in
one window and create windows without disturbing your work. New windows
could even be made front without disturbing the key window.

Similar chaos insues when a GUI uses too many modal dialog panels. 
Microsoft Windows is particularly dialog happy.  Linux less so but there
are times when modal dialogs pop up at inconvenient times, stealing user
input and performing actions not intended.

Although this isn't a "bug" as such, I consider this to be a major defect
in any UI.  I'm assuming this is a Sawfish issue.  Reassign as appropriate.

-- John


How reproducible:
Always

Steps to Reproduce:
1.Run the text editor and start typing.
2.Launch Mozilla.
3.Return to the text editor and keep typing.
4.Mozilla windows come up and say goodbye to your important keystrokes.
	

Actual Results:  Data loss

Expected Results:  I should be able to type UNINTERRUPTED.

Additional info:
Comment 1 David Mason 2001-06-19 15:36:00 EDT
I am afraid you are in the minority for this behavior. I can understand it if
the new window in question is a transient window... and sawfish does allow you
to set it up where those will stay only with their parents and will not steal
focus. I suspect that you should be able to write some lisp code that would
allow new windows to not grab focus - you might want to ask on the sawfish
mailing list (http://sawmill.sourceforge.net/)

Otherwise I am going to close this because I believe for most people it is the
expected behavior when opening a new application. Thanks for the report.

Note You need to log in before you can comment on or make changes to this bug.