Bug 106847 - Double-click in window does not raise window when using sloppy focus
Double-click in window does not raise window when using sloppy focus
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: metacity (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Havoc Pennington
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-11 17:43 EDT by Ben Steeves
Modified: 2007-11-30 17:10 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-25 15:52:01 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 Ben Steeves 2003-10-11 17:43:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030728
Mozilla Firebird/0.6.1

Description of problem:
When using sloppy focus (i.e., "Select windows when the mouse moves over them"
is checked in Window Preferences), Metacity used to respond (correctly) to a
double-click inside a window by raising the window to the top.  It no longer
does this -- one must click on the window border or titlebar for the desired
behavior.

Click-to-focus still works as expected, and raises the window with a single click.

Version-Release number of selected component (if applicable):
metacity-2.6.2-1

How reproducible:
Always

Steps to Reproduce:
1. Turn on sloppy focus
2. Open two semi-overlapping windows 
3. Shift focus from the top window to the bottom window
4. Double-click in the bottom window
    

Actual Results:  Double-click is passed to bottom window

Expected Results:  Window should raise, double-click should be swollowed by
metacity.

Additional info:
Comment 1 David Aspinall 2003-11-12 13:26:31 EST
I've just found this problem after upgrading from RH9 to FC1.

Actually, my expected (previous) behaviour was for a single click 
to raise the window -- maybe because I use single click to select.  

This is a very frustrating change/bug --- it is much harder to click
on the title bar (or narrow frame) of a window than anywhere in
the window itself.  It really slows down interaction with the
window system!!

Comment 2 Ben Steeves 2003-11-12 13:33:12 EST
This problem persists with Fedora Core 1, metacity-2.6.3-1 .
Comment 3 Tom Morton 2003-11-22 17:32:15 EST
This change in behavior from RH9 is also driving me crazy.  Apparently
it's also an issue in RHE (see bug #110264). 
Comment 4 Ben Steeves 2003-11-24 20:54:35 EST
I've just been informed this new behavior is "expected".  At the very
least it ought to be an option.  Click-to-focus is not an appropriate
alternative, because it's very common (at least for me) to want to
have the rear-window to have focus.
Comment 5 Shantanu Goel 2003-11-24 22:50:25 EST
I'd like to request restoration of RH9 behaviour and suggest that this
be available as an option at the least.
Comment 6 Ittai Balaban 2003-12-03 20:49:41 EST
Please, *please* restore the old standard behavior regarding sloppy
focus. I find this new "feature" completely unintuitive (and somewhat
evil to be honest). Might as well just remove sloppy focus altogether.
Comment 7 Christopher Blunck 2003-12-09 00:06:48 EST
I second this.  Please please please restore the old behavior.  This
interface is absolutely killing me!
Comment 8 Guy Streeter 2003-12-29 16:27:29 EST
If you hold Alt (or whatever you configured for click-to-grab) and
single-click, the window is raised.
I'd still rather see the old behavior.
Comment 9 Adam Back 2004-02-03 23:12:36 EST
This is a crazy change.  If someone did that intentionally they're
flat out wrong.  I've been using sloppy focus (mouse over to get
focus) since 1994 on irix, then slackware, then redhat, and up.

Dudes: sloppy focus is supposed to have a convenient way to raise a
lower window with cursor.

Adam
Comment 10 Mark Brady 2004-02-23 15:51:18 EST
It is silly not to allow a config option for this.

"Use ALT-click to raise your window" - I'd rather not.  You may as
well suggest that I stand-up-and-click to raise.  I don't think an
efficient user will waste time with ALT-click to raise.

"Go use a different WM with more config options" - yes, I do now.  But
there is some pleasure in using the standard redhat/fedora apps in
reduction of bumps with themes, fonts, updates, etc.  And there is
some displeasure in being forced out of an app. so basic as the wm for
reasons so basic as the config.

"The 'Window Preferences' window needs to be simple" - fine, put an
'Advanced' button or make use of a config file I can edit by hand.  I
would bet there are more people wanting sloppy-focus with
click-anywhere-to-raise than wanting auto-raise (auto-raise takes a
large chunk of the Pref window).

"We can't please everyone all the time" - sure, but by restricting
choice to a few styles you fall into the misguided trap of assuming
you know what people want (infamous MS e.g.).  With a few simple
config additions I'd be long on the Metacity pleasure index.
Comment 11 Rei Shinozuka 2004-03-09 08:42:12 EST
I agree that click to raise NEEDS to be an option, it has been the way
i have been using window managers for years. i have to use mixes of
various flavors of linux boxen and solaris gnome/fvwm machines and
they  are all set to click to raise. please, please!! patch this.

-rei
Comment 12 Ittai Balaban 2004-03-09 09:46:28 EST
This all seems to be falling on very deaf ears.
Anyone know a similar, usable, gnome-friendly window manager? I tried
sawfish again a few weeks ago, but it had some funny glitches (e.g.
window positions changing spontaneously when switching between
workspaces).

It's so annoying that an arbitrary decision by a developer about such
a minor issue, made after he got us hooked on his window manager, is
driving us away..
Comment 13 Ben Steeves 2004-03-09 19:10:44 EST
This behavior has changed in Fedora Core 2 Test 1.  Now, a single
click will raise the bottom window.  The click is not swallowed by
Metacity; it is passed to the application.  This is accepatble to me :)

Thanks for listening!
Comment 14 Ben Steeves 2004-03-09 19:14:18 EST
Oh, by the way, the version of Metacity exhibiting "good" behavior is
"metacity-2.7.0-1".
Comment 15 Elijah Newren 2004-04-14 20:01:26 EDT
This was bug number 115072 on Gnome bugzilla
(http://bugzilla.gnome.org/show_bug.cgi?id=115072).  This should be
resolved as fixed upstream.
Comment 16 David Maxey 2005-02-14 14:27:30 EST
It just so happens that the clients I represent are in need of the
capability to cut and paste into a window, which is below another
window, and NOT have it raised.  But, as a result of going with
popular opinion, you have convinced the "author" to change the
behavior of the window manager.  What you need is an option (not "at
least", you need options, period!), to allow more control of focus
behavior.  To put your windows interface in a locked up mode where
things can only be done one way, with not user control, is to become
like Microsoft Windows (and I can't think of a worse fate than that).

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