I would just like to put my voice in on this one too.  One of the
reasons that I changed from click-to-focus to sloppy-focus was the
very purpose of having smaller windows on top that <b>remained</b> on
top while still being able to cut and paste from underneath larger
windows.  This especially happens with terminals.  I hope this is a
feature (default or no) that Havoc is willing to add.  IMO, windows
should be raised only when clicking on the borders and title bars.

Created attachment 9509 [details] [review]
Patch to only raise on frame clicks when no auto-raise

The above patch makes it work the way I think it should; I tried it
with all four combos of auto-raise/no auto-raise and click/sloppy and
it did what I thought was right.

Adding PATCH keyword. Havoc?

Well, it used to not raise on click in sloppy mode, but was
deliberately changed to do the raise. tigert was the main advocate of
that. ;-)

I don't much like this as a preference, too trivial/micromanagerial.
Not sure I have a strong opinion on what it should be by default, though 
I was convinced once to change it to how it is now.

I agree it's too fussy to be a preference -- just imagine how long 
the explanation would have to be in the preferences dialog.

I have two arguments that not-raising is the best choice:

1. If you want it raised, bind a key to raise_or_lower, and hit
   that key.  This isn't symmetrical, because if the policy is
   to raise, hitting raise_or_lower will send the window to the
   bottom: no way to get the desired behavior of "leave the
   stacking order alone."

2. Most focus-follows-pointer people will be migrating to 
   metacity from sawfish or dtwm/mwm, and both of them don't
   raise on click unless raise-on-focus is selected. (Well,
   there was no doubt some way to customize sawfish to 
   do so, but anybody who was that deep into it is just
   going to stay with sawfish.)

I tend to think much like Rich has enumerated.  Along with the history
of sawfish, all former window managers that I have known, do not raise
windows on clicks other than on the frame.  The only window manager I
know that does this is Windows (if you hack the registry to allow
focus follows mouse)  and because it did this I went back to
click-to-focus.  

I would be interested in Tigert's arguments for the behavior as they
were so persuasive to change your mind.  Are they just his preference,
are they based on some kind of useability studies, or are they based
on majority opinion?  

Finally, what is so "trivial/micromanagerial" about having this
option?  I have of course read your README, but this seems like a case
where there is no right or wrong, perhaps many people want it one way,
and many another, and the option could be made very clear -- "Raise on
frame click only/Raise on click anywhere in window."  It also doesn't
seem to clutter up the code any, nor provide any maintenence
headaches.  I understand the reasoning behind choosing good defaults
and limiting options, but there are legitimate reasons for options,
and you can still choose whatever default you like.  IMO if the
maintenence cost is low to zero, and the option is needed, and you set
on aspect of the option to the default, you have a complete solution.

Sorry for the ramble.  But I figure as you state, options need to be
considered long and hard, before they are added, and considered
whether a good default would solve the problem better.  I don't see a
better way -- maybe someone else has one?

How about having another user preference in metacity-properties
under "Click to Focus", which says something like "Raise window
only on Frame/Border click"? If this property is set (maybe make
it unset by default), raise the window only if the user clicks
on the frame or the border of the window.

I'm not a big fan of this as a preference.

Havoc: So, any other suggestions by which we can provide this feature 
to the user?

Well, we could change the default. Or fix the problems with the
current default.

It's one of those cases where it will never be perfect but it's just
too trivial an issue to make a pref. The problem isn't large enough 
to justify the cost of a pref.

Havoc: My line of thought was that some users may want the feature of 
raising windows only when clicked on frame or border (so that they 
can perform the copy/paste as the submitter says), but some users
may want the window to be raised on a click anywhere within the 
window (current behaviour). So, how do we make a choice between these 
two options? Or am i missing the real issue here?

Read http://pobox.com/~hp/free-software-ui.html

Havoc, not to belabor the point, (maybe you have made a decision that
can't be changed here) but I read all of your main statements on
design issues BEFORE posting to this thread, and I am struggling with
two specific issues that in my mind have not been answered.  

1.  Looking at the code, and the patch, I cannot envision this being a
maintence headache at all, nor does it negatively impact the speed, so
in my mind there is zero cost due to maintenence and speed impact, is
this the way you see it?

2.  If we take number 1 as true, then the main cost factor you must be
considering is the confusion/"finding pref" cost.  (From my analysis)
 Here, I submit -- I don't know the answer, and while I admire your
resistant approach, and you may be right that the preference doesn't
belong, I would love to here the why -- beyond "cost is too high." 
That way we may be able to tackle the problem better and resolve those
issues in the most beneficial manner.

One thing is that in an X world where middle-click-and-paste exists,
we expect, get used to, and enjoy the speed and ease that the system
provides.  Introducing another click to raise the window, plus, and
most egregiously, searching for the target window because it
dissappeared when you made the selection hinders the smoothness of the
process.

The main complexity I'm worried about here is "combinatorial pref
interaction complexity" by which I mean, if you don't know how things
are going to behave, you can't make things "just work" with that
behavior, and end up creating more prefs, until the user has to
configure everything before anything works.

Some concrete examples: if you have configurable keybindings for some
apps, then all apps have to have them, or you get collisions; if you
have sloppy focus then you need autoraise; if you have corner panels
then you need "let windows overlap panels"; etc. Miguel had a good
example the other day that I forget.

These things come up all the time, and lead to snowball effect on
preferences.

The other thing is that I suspect we could solve this problem more
effectively, for all users; the pref solves the (rather unimportant in
the first place IMO) cut-and-paste issue for 1% of users, but really
does nothing for the other 99%. So, I would rather we sit down and
think about how to fix it for everyone.

We need to fix essentially the same issue for drag-and-drop, and the
bug to fix that is already open in here, against the "EWMH" component
I believe.

I do believe things can be made to just work so that selecting text
and starting drags doesn't raise windows. That would be a far better
solution (though it creates more code complexity, it's probably worth it).

Here are two relevant bugs:

  http://bugzilla.gnome.org/show_bug.cgi?id=80984
  http://bugzilla.gnome.org/show_bug.cgi?id=76672

The basic fix I would experiment with is:

 - focus windows on button release not press
 - don't focus on release if the mouse has moved 
   outside the window (fixes drag and drop right away)
 - have a way for apps to send a client message prior to 
   the release indicating that the release should not result
   in focus

This is really simple and straightforward, unless the 
focus-on-release policy has unexpected side effects.

Havoc: We don't seem to be getting a ButtonRelease event (in 
event_callback) when clicking anywhere inside a window (other than 
frame and borders)? Is this expected?

You probably need to add ButtonReleaseMask to the event mask.

Havoc: I tried adding ButtonPressMask and ButtonReleaseMask to 
XSelectInput() in meta_window_new(). Still i get only a ButtonPress 
event in event_callback() when clicking inside the window. But if the 
frame or the border is clicked, both ButtonPress and ButtonRelease 
events are received.

For inside the window you have to change the XGrabButton call to
include button release (and then make sure you pass the release
through to the app if and only if you passed through the press).

Havoc: Do you plan to work on this? I haven't been able to make much 
headway in trying to get the ButtonRelease event to work, still 
trying though.

I'd like to work on it sometime, not immediately though.

Havoc: I believe we already do an XGrabButton() when the window is
created [ meta_window_new() -> meta_display_grab_focus_window_button
() -> meta_change_button_grab() ]. This XGrabButton() call has both 
ButtonPress and ButtonRelease in the event_mask. Why is this not 
resulting in the ButtonRelease event being generated?

I don't know. Perhaps we have to pass in the Button1Mask modifier to
the grab button (if it isn't grabbed with AnyModifer, maybe it already
is).

Havoc: Presently the code does XGrabButton() with the 
ignored_modifier_masks (meta_change_button_grab is called from
meta_display_grab_focus_window_button with modmask value of 0). I'm
able to get the ButtonRelease event if i change make the pointer_mode 
argument to be GrabModeAsync instead of GrabModeSync. But if that is 
done, text selection is not possible on the window. Hence i'm not 
sure what is going wrong here.

Another question here: In XGrabButton(), why is the 'confine_to'
argument being passed as False? Wouldn't a value of 'None' or the
window id make more sense?

I would have to read the docs on GrabModeSync, maybe it doesn't
support release events.

Yes confine_to should be None.

*** Bug 83304 has been marked as a duplicate of this bug. ***

I filed the bug 83304 just marked as dup of this one. Please review
the arguments there as well. I agree a pref for something like this is
bad, since it creates several combinatory settings that make no sense
at all. It would be better to fix the default.

Another datapoint (that may apply to ALL focus modes, although I
haven't tested it): it is currently difficult to drag icons between
Nautilus windows if the source window is below the target (but enough
is visible to grab the icon/selection), since Metacity brings the
focused window to top on Button1-Click, instead of Button1-Release as
it should. That causes the source window to cover the target during
the drag when the two overlap. Not only is this not optimal, it's
actually done right in both MacOS and Windows and we should clone
their behaviour in this respect.

Jayaraj,
I believe the reason we receive a ButtonRelease event on a window
frame but not inside a client window is when clicking on the window
frame we begin a move grab op.  meta_display_begin_grab_op() calls
XGrabPointer() which enables the ButtonRelease event.

Not sure what is up with XGrabButton.


 

Oh, note that clicks on the client area are reported as clicks on the
frame because of how XGrabButton() works, try "man XGrabButton()" and
note this:


       ButtonPress event is reported if
       all of the following conditions are true:
....
               o    A passive grab on the same button/key combination
            does not exist on any ancestor of grab_window.

Havoc: Reading the man page, i'm a bit confused since we are getting
a ButtonPress event but not a ButtonRelease. Going by what is
described in the man page, we shouldn't be getting any of the events,
right? Maybe Blackc has a point here that the XGrabPointer does not
take place and hence the ButtonRelease event is not enabled. But
i guess it is not possible to do a XGrabPointer when a ButtonPress
is received because, it makes selection of text within a window
not possible.

So with the current scheme of things what is the way to get the
ButtonRelease in event_callback()?

I agree with the reporter of this bug and with the reporter of #83304.
This is the most annoying thing about Metacity and the main reason
that stops me from using it instead of sawfish. 

Really, what's the point of sloppy focus if i can't use the windows
without raising them? I don't mean only using drag&drop, I mean
clicking in widgets too.

When I want to change the stacking order I can (right) click on the
window frame.

*** Bug 91165 has been marked as a duplicate of this bug. ***

Those solutions don't allow people to work on a window that isn't at
the top though. 
Simple example: I open a large editor window, then a calculator,
continue to type into the editor window while the calculator is still
on top. 
I don't think this is a very rare example, especially in an
environment where windowing is much better possible as in, for
example, Windows (sweet irony).
I like the way that is used by AtheOS and (I think but not sure) Amiga
OS. This does not bring windows to the top when they are clicked
inside (but focus them). To bring a window to the top you have to
click the titlebar. There is also a button on the titlebar to change
the stacking but that's another issue.
I wonder if this system wouldn't make more sense and please more
people although it's not very similar to Windows.
Middleclick on titlebar could be used to lower the current window
conveniently. 
This would work in almost and every situation at the cost of not
beeing able to bring a window up by clicking somewhere into it's
(large) content area. 
This just seems like a typical tradeoff between convenience (clicking
window contents to raise) and functionality (beeing able to work in
un-raised windows). This at least seems to me like a more important
choice and tradeoff than click-to-focus versus mouse-to-focus.

Another option could be to combine both. This would just make it a bit
more confusing... For example middleclick on titlebar and/or
shiftclicking into the window could focus it but not raise it. To
raise window then you would have to click the titlebar or focus
another window to raise the window to the front. This would allow for
certain windows to be permanently in the background while you work
with them but not get into your way otherwise. The big downside of
this would be that it becomes pretty ambiguous with sloppy focus
(another good reason why preferences are bad), as those would be
focused anyway, so when middleclicking the titlebar or shiftclicking,
there would be no visible change... *sigh*

I just hope that there will be a solution that doesn't sacrifice
existing functionality... Even if it does mean to get rid of sloppy
focus (:P), changing the default for sloppy forcus again not to raise
windows (this would basically combine both preferences into one) or
adding just another preference if there is no other (acceptable)
solution...
I would give my vote for the Amiga/AtheOS-way. It would be slightly
less convenient maybe but it would "just work", that's why I like it. 

Although I don't really have anything all that meaningful to add to
the discussion, I have to raise my voice as one of the people that
really likes to focus windows without raising them. Things like
keeping a text-editor open on top while browsing Usenet for binaries
(using the text editor for keeping track of things to get or what you
already have), or keeping an instant messanger window open on top
while you browse the net with Mozilla are just some of what you can do
with this that is currently impossible with Metacity. I've actually
switched back to FVWM because of this (yes, really), since it was
annoying me so much.

However, I'm not optimistic about finding a way to make this work that
doesn't require an option. Obviously, there's a lot of people that
like things the way they are, and if things change again, there'll be
more complaints about it. I don't really see this as something that's
too trivial or micromanaging, since it affects every single focus
change... Personally, I think this is something that SHOULD be an
option, perhap only via Gconf, or at least an implied setting (that
is, if you have focus-follows-mouse, then raise-on-focus is
nullified). I know that Metacity (and Gnome is general) is trying to
avoid this kind of thing, but some things can't be avoided, right?

Another choice might be to have a "Keep This Window On Top" selection
in the context menu for windows... but this seems worse than a global
option to me.

Well, I'll chip in too then... ;-)

I don't think this should be an option; the default should be fixed.
Raising a window on any click is hugely limiting for all users, and
confusing ("I clicked in Word and my calculator disappeared!").

It affects the way that people use the computer. It effectively
prevents you from using several programs at once, forcing, eg, your
word processor to have a built-in calculator because a standalone one
isn't useable.

There might be a case for an option to control whether clicking on the
titlebar raises (many WMs don't; sawfish, afterstep, etc), but not for
clicks in the main window.

The behaviour isn't confusing either, because if clicking inside a
window doesn't raise then the user will try the titlebar or frame (the
logical place to control positioning of the window anyway).

In addition to the existing WMs and systems listed above, I'll add
RISC OS (a system designed largely for use in schools) as a system
which doesn't do raise-on-click. That also had a very nice solution to
the title-bar-raising issue:

Any titlebar or frame operation performed with button-1 would also
raise the window (raise-and-move, raise-and-resize,
raise-and-maximise), but using button-2 would do the same operation
without raising. I think this is the best option; it gives the
expected behaviour for beginners, and is flexible for power users
without the need for any options.

Thanks,

Created attachment 10901 [details] [review]
Add raise_on_click configuration item.

Hi, above (rather simple minded) patch adds
/apps/metacity/general/raise_on_click configuration item. When set to
true (default), nothing changes 8), when set to false, then windows
are no more raised when clicked in client area. Alt-clicking, or
clicking on frame still raises the window. Hope that will satisfy
members of no-raise-on-click camp at least unit the issue is
completely solved 8).
Note that the windows are not raised even in "click" focus mode, it is
kinda race between focus mode and raise on click - but I did not
wanted to add new setting, and tried to keep the patch as simple as
possible (I never before worked on wm).

*** Bug 92629 has been marked as a duplicate of this bug. ***

It seems something is being overlooked.

In other windowmanagers for example, if you have mozilla and a xterm
open at the same time, and if the xterm is on top of mozilla you can
right click on mozilla and it will focus on mozilla while the xterm is
hovering.

I tried the patch above and it allows you to do this, but its kinda
annoying because to bring the window that is behind the main to the
front you need to click on the top bar or edge of the window (or hold
alt and click on it)

I think it would be easiest to have the patch only focus on what is
behind the main window if you "right" click  that way you can left
click on the app to bring it to the front.

Does this make any sense?

A good example is Windowmaker.

Daryl, that would not solve the problem that you can't work in windows
that aren't at the top because the window would raise as soon as you
click anything in the window (unless there is a way to make the window
only raise when no control is clicked, but this might be even more
difficult to implement, especially for special cases like a
webbrowser). Also the right click would in many cases pop up a context
menu which would be unwanted.
If anyone is interested, there is also a discussion about this topic
at the GNOME user forum:
http://help.gnomesupport.org/forums/viewtopic.php?t=545 

Created attachment 10957 [details] [review]
metacity-focus.patch

Daniel, Your right,  I was playing with the metacity code last night
and I made it so you can alt right click on the window and it will
focus, but as soon as you left click it brings the window to the front.

I made a patch.  I did reversed the button 2 and button 3 for it to work.

The RISC OS option mentioned above looks great to me. And option
raise_on_click. Combining these two would solve it for everyone.

I personaly like also click on frame and move the window around while
not raising it. Using the middle button for this would be ok.

Are we going to have to make this a GEP? ;)

A GEP doesn't help, we need a patch. And I mean patches to make it
work right by default, not adding cop-out workaround preferences.

We are talking about to completely differnt behaviors:

current: always aise windows when clicked anywhere.
desired: only raise windows when clicked on their frame.

The first behavior is very inconvenient. It makes sloppy focus totally
useless. But I guess that it is what people used to click-to-focus
expect. I don't see how you want to solve this without a pref.

Maybe patches #1 or #2 would be enough for 90% of people. I would
prefer patch #2, but it adds a pref (oh no!)

If the first behavior truly makes sloppy focus totally useless, then 
we should just change it by default. Clearly there's some discussion
of that point though, as others felt click to raise mode sloppy behave
more intuitively.

Created attachment 11301 [details] [review]
Clean simple patch ;) None of that preferences lark

I agree with Havoc that this cannot be a preference - the above 
(CVS)patch very simply removes the behavior.

Granted there will be people who want gnome to act just like windows
does, but i think that this is the corect behavior and will be just
like workspaces - weird at first but in the end one of those things 
you just cant live without.

That patch applies against 2.4.1 but seems to have no effect on HEAD -
i dont have a clue why.

Oh, please :/

Click to focus requiring to click on the frame to rise is one of the
most annoying things I ever encountered when first migrating from
windows to linux. It would still be very annoying for me nowdays.

I am pretty sure the idea of a window in the background getting the
focus but not rising to front when clicked inside would be
incomprehensible and a "obvious bug" to most of the uninitiated
computer newbies.

So, please dont make hasty decisions on this one.

What I'm wanting here are patches that experiment with raising on
button release, or not raising when doing selection/DND, or that kind
of thing. There may also be GTK+ patching involved in fixing this.

See this thread for discussion:
http://mail.gnome.org/archives/wm-spec-list/2002-August/msg00032.html

There's no need to keep adding comments back-and-forth; someone needs
to start trying to genuinely fix the problem. And neither "always
raise" nor "never raise" are genuine fixes. ;-)

That would not allow me to click a button without raising the window,
right?

*** Bug 94848 has been marked as a duplicate of this bug. ***

Another special case I just added handling for: if an app has utility
windows, like all the gimp "dialogs", metacity will now keep them 
above the main windows for the app. The gimp does need a small
modification to mark its utility windows as such, though.
(This mod will also let themes treat the utility windows specially.)

I assume that that will apply to the evolution send and recieve
window. That will make focus behavior a lot nicer ;)

One thing i was thinking of was this: would it be possible to add "the
ability" (not an option, no no) to tell a certain window to keep focus
even if you are working in a window below it? I'm not sure about other
people but i think that that would solve my focus issues.

*** Bug 95943 has been marked as a duplicate of this bug. ***

As its author, I'm not 100% sure 95943 is a duplicate, but it's
certainly related.  If moving or resizing a window (mouse down, move,
release) doesn't count as a `click', then it's a duplicate, else
a related feature.  Although the behaviour I desire isn't necessarily
synonymous with sloppy focus, they go well together.

To get that without adding any new options, I'd propose the following:

"click to focus": any mouse gesture (click, move, resize, drag'n'drop)
on a window or it's frame raises the window and gives focus.

"sloppy focus": moving the mouse over a window or frame gives focus.
Clicking the frame raises the window.  Move & resize gestures (press,
move, release) on the frame does NOT count as a 'click' for raising
purposes.

Does that scenario satisfy anyone besides me?

I realize that distinguising a proper click from a move/resize gesture
involves some timing issues...

How about any a `quirks` mode for point to focus, where no click ever
raises a window unless it's the middle button on the title area or the
frame itself??


The thing is you will never get everone to be happy with what you
decide, and I can see that making things too configuarable make's
everthing harder to maintain (not the code but the configuration for
business desktops) so having your're current defaults is'nt a bad
idea, but a `quirks` mode to disable raising unless sepecifically
actioned a reasonable alternative.

Just adding my voice to those who wish the default to be changed. 

Metacity's current behaviour of raising on click in sloppy-focus mode
is at odds with every WM I have tried and therefore violates the
principle of least suprise. 

I would propose:

For click-to-focus: a click in the window or the frame will focus
_and_ raise the window.

For sloppy-focus: a click on the frame will raise the window. Clicks
within the window do _not_ result in a raise.

This would be a sane default, consistent with the way these two focus
models have been traditionally implemented.

Created attachment 11969 [details]
suggested focus option modification

Raise is already an option for sloppy focus mode so why not just make
it a sepporate/universal option.

Guys, I have said what I want:

> What I'm wanting here are patches that experiment with raising on
> button release, or not raising when doing selection/DND, or that kind
> of thing. There may also be GTK+ patching involved in fixing this.

> See this thread for discussion:
> 
>http://mail.gnome.org/archives/wm-spec-list/2002-August/msg00032.html

I want at least some effort toward a real fix before I'm willing to
consider an option. If everyone is too lazy to make the effort, I'm
too lazy to add the option. OK? Them's the rules.

I wrote this just now: http://pobox.com/~hp/features.html

Have fun. Give me real fixes to root problems. We shouldn't push a
stupid tradeoff that shouldn't exist onto the user, and I don't think
people will fix it for real if I accept the lame option.

Hmm, the referenced discussion claims that one "normally wants"
a window raised on click.  In fact what many here are saying
is that they _dont_ want it raised at all (at least not on the
window); it doesn't fit well with sloppy focus mode. In July, 
you said that not raising _was_ it's original behavior, but 
Tigert wanted it changed (Why?). 

So, if I've understood the lecture on opensource development, 
the "fix" you're looking for is for someone who isn't too lazy
to submit a patch that would revert the behaviour back 
to what it was before without knowing why it was changed in the
first place?

There are comments on this bug with ideas on what to try, links to
other bugs and mailing list threads, and so on. There are more choices
than 
"always raise" or "always don't raise," we need to try smart behavior
in between. (And don't post about how you don't want an intermediate
option, you want "always don't raise"; I don't care, I'm not willing
to consider "always don't raise" until we've experimented with some
intermediate "smart" behaviors that help all users instead of 1% of
users. That's the point.)

Preface: I really like metacity and completely agree with its guiding
principles.

That said, I have to agree with the originator of this bug. With
sloppy focus, I would prefer to allow unfocused windows to stay on
top, even when I click. Would it be too crazy for sloppy focus to only
raise windows explicitly (alt-click), but for click-to-focus to raise
windows on focus switch? (Isn't Metacity's real target audience going
to use click to focus anyway?)

Could someone (Tigert?) explain the use of raise-on-click with sloppy
focus? To me it feels broken to be able to use a window all I want
with a keyboard, but if I want to click on anything, I am forced to
have the window raised.

*** Bug 98323 has been marked as a duplicate of this bug. ***

I'm the originator of the bug 98323 and then I would prefer to not
have a raise on click in sloppy mode.

But, since the discussion on this topic is stalled, what could be
sufficient is an "Allways on top" entry in the window menus.

Then you'll be able to put a small window on top and do drag and drop
or cut and paste to and from a maximized window.

  Emmanuel.

Some X applications are designed for a WM that does not raise 
windows (ever tried gimp with 'raise on click' mode?). 
Changing the application like you did for Gimp is not always 
an option. If a company is paying 100000$ for a program 
then they are not going to change it because metacity makes it 
unusable (guess which one is going to be kicked out).

Metacity has to provide a mode that does not raise windows.

Havoc, your idea of looking for a smart behavior is good but 
I doubt that anyone could design a 'smart' behavior that 
would work with all X applications (because X applications 
do not give any feedbacks to the WM about the nature of 
mouse clicks). 

Asking for peoples to study a hypothetical smart behavior 
when there is a simple solution to most their problems is 
a bad idea. 
Your top priority should be to implement the few simple 
features that make metacity usable. When those features 
are implemented then start adding 'smart' features.

The same hold for other bugs such as 95273 (wireframe 
move/resize). Peoples provide a known and simple 
solution but you dismiss it because you want a 'smart' 
implementation. 

I didn't say I wouldn't consider the pref to work around legacy apps,
but *after* we have the problem solved in a better way, or have made a
good effort. Not before. Sorry. That is the way it is.

Arguing with this just clutters the bug report so people can't see 
the comments/discussion on what needs to be done.

When someone finally decides to really address the issue, it probably
won't even take them that much time. And then we'll all be embarassed
that we spent so much time arguing instead of just addressing it.

I'm not going to budge on this, I've seen the same thing happen 
for many other issues, and it's always the same; if you take 
some dumbass pref, no one ever fixes it; if you don't take the 
pref, it gets fixed eventually. Fix it. Why aren't you fixing the
problem instead of adding bugzilla comments?

> ... but *after* we have the problem solved in a better way, 
> or have made a good effort

So you are telling me  that I have to make a good effort 
looking for a better solution (which probably does not exist)
when there is a known, simple, efficient and standard solution 
without any real disadvantages.
 
You are right!!!! Why make simple things when you can make them 
complex!!!


> I'm not going to budge on this, I've seen the same thing happen 
> for many other issues, and it's always the same; if you take 
> some dumbass pref, no one ever fixes it; if you don't take the 
> pref, it gets fixed eventually.

Ok but this attitude does not work when the problem cannot be fixed
without a pref. That what I am telling you: You cannot expect to get 
enough information from the applications so there are no 'smart' 
solutions. 

> When someone finally decides to really address the 
> issue, it probably won't even take them that much time. 
> And then we'll all be embarassed  that we spent so much 
> time arguing instead of just addressing it.
> ...
> Fix it. Why aren't you fixing the problem instead of 
> adding bugzilla comments?

That is exactly what I am trying to do. I propose to fix the 
problem with a simple solution: disable 'raise on click' in sloppy
mode or make a pref.

People - However you feel about Havoc's choices, attitude, and so on,
Bugzilla is *not* the place to discuss it.

Please take the flamewar to IRC, a mailing list, or anyplace but here.
 Okay? :)

I'm almost 100% positive that there is already an option when in
sloppy focus mode. Just run metacity-properties. The issue here is in
normal click-to-give-focus mode.

If havoc is willing we could start afresh and discuss this on the gnome
user's board. Or we could start another discussion on gnome-desktop.

Havoc: I do agree that drag and drop needs some work - but wasnt
that a sepporate bug. The one related to windows needing to be given
focus on release instead of press IIRC.

The way I see this bug - it is not only to do with drag and drop.
It's about having control over the stacking order of windows and being
about to "work" in an un-raised window.

>However you feel about Havoc's choices, attitude, and so on,
> Bugzilla is *not* the place to discuss it.

I disagree because Havoc's choices & requirements are simply 
stalling the bug. 
Bad choices and requirements are part of a bug's life and the 
only way to progress is to explain to the developper that he 
his wrong. The place to do that is the bug tracking system and 
not a mailing list or a IRC channel.

Developpers should realize that they are part of the projects 
and like any other parts they can have their own bugs. Eventually, 
each developper should have its own bugzilla category :-) 

> The issue here is in normal click-to-give-focus mode.

No! The issue is also in sloppy focus. The default sloppy 
behavior is to raise on click and there is currently no 
option to prevent that. The only option associated to sloppy 
focus is autoraise.

If this bug continues discussion about anything except purely
technical issues, I'm going to close it for public comment. Period.
Havoc has been flamed enough; bugzilla is not the forum for further
commentary. If you have further problems, fork metacity and provide
your own code, discuss it in a more appropriate forum, or keep them to
yourself.

Forgot to actually close this.

*** Bug 104835 has been marked as a duplicate of this bug. ***

To avoid any more people complaining about this, I'll point out here
that xfwm4 now supports this feature. Like metacity, it fully supports
the freedesktop.org window manager standard, and is just a window
manager -- no other nonsense. In fact, it actually includes some of
the metacity code, and is generally very similar.

It also now implements the button-1/button-3 dragging behaviour I
described above. Instructions for installing it are here:

http://members.home.nl/jbhuijsmans/xfce4-cvs.html

*** Bug 114994 has been marked as a duplicate of this bug. ***

*** Bug 123513 has been marked as a duplicate of this bug. ***

*** Bug 132543 has been marked as a duplicate of this bug. ***

*** Bug 136068 has been marked as a duplicate of this bug. ***

Created attachment 25710 [details] [review]
Updated the previous patch to the current release.

I like the metacity philosophy, but when defaults change and old
behavior is not even an option anymore... c'mon, get real.

There's just as many valid arguments for either style of behavior, and
there are people on both sides who just can't live on the other side.
We don't want preferences for stupid cushy crap, we want preferences
for situations when there are two valid points, and those ascribing to
either one cannot live with the other. Sound familiar?

I patched my source, and although you guys seem to be adamantly
opposed to including any such option in the mainline distribution,
there are sure to be others out there looking for a patch like this.
And here it is. Enjoy, all enlightened ones!

There's also a patch in bug 115753 (which you could also find by
looking through the blocking/dependent bugs) that does the same thing.

Aaron: Can I point out Luis' most recent comments above?  Trying to
refer to the maintainers as unreasonable doesn't help.  Please avoid
it.  Providing a patch for others is great, but you could leave it at
that.  Note that I too prefer do-not-raise-on-click behavior, but I
think the best way to go about obtaining it is to try the things Havoc
requested (i.e. rationale--see bug 131135 for my stab at it; and more
importantly, patches for not raising on drag-and-drop operations). 
They still might not accept such an option (adding options always adds
more configurations that need to be tested and can cause maintenance
to be more difficult), but that is fine as it's their software.

If you want to respond, please email me outside bugzilla.

*** Bug 144827 has been marked as a duplicate of this bug. ***

I've been thinking about this problem a bit, and the intermediate solutions that
Havoc has proposed.  There's a case I just can't figure out how to deal with,
though:

Consider having an emacs (or gedit, abiword, gnumeric, etc) window partially
obscured by another window, and then clicking in it to change the cursor
location.  The "raise only on release" solution, which helps with drag-and-drop,
won't be of any help here.  I don't think there's any algorithm which can avoid
the unintentional raise, other than never raising-on-click.

I think this restriction in the user's multitasking options is going to be a
more serious issue as metacity develops into a compositing window manager. 
Working with background windows could become even more natural if obscuring
foreground windows become fairly transparent, and I suspect that having an
unmodified click raise a window is probably not the right behavior in such an
environment.  (Not that I would claim that with certainty, of course.)

*** Bug 302820 has been marked as a duplicate of this bug. ***

We aren't going to get a "read your mind" perfect solution, no.

You can always use the "On top" feature if you have a couple apps and are going
back and forth between them, and want to keep one on top regardless of clicking
the other.

I was wondering where the whole raise-om-_release_ thing went? To me it sounded
like a really good idea, that would solve -some- of the issues discussed in this
thread.

I was actually about to try implementing it myself, when I just thought I'd
better check bugzy first, and voila :-)

** Not trying to enflame old sparks here. - Just want to know if the idea had
been abandoned, forgotten or just turned down. I really tried hard skimming the
thread for results, but found none.

Cheers!

I don't think anyone ever tried out the raise on release concept. It may turn
out to be hard to implement, or not work well (or we might need some
communication with the toolkit) - it's hard to know without trying it.

I and at least one other person independently tried it; unless I made some big
mistake in understanding something somewhere, this is not possible to do this
without toolkit support because the application gets a grab and the WM doesn't
know about the ButtonRelease.  So, _NET_WM_TAKE_ACTIVITY/_NET_WM_MOUSE_ACTION
are needed.  Anyway, the former of those two is easy to implement (in a basic
manner) but results in all apps deciding WM behavior, while the latter is much
more involved and _NET_WM_USER_TIME bugs and stuff has taken a lot more of my
time than expected[1]--so I haven't gotten around to it.  See bug 154260 if
you'd like to help.

[1] Actually lots of other factors played a role recently as well.  Like
bugsquad work, the fact that CVS gnome wouldn't build easily without a newer
kernel thanks to HAL (and I had various issues on different machines with
upgrading the kernel), the fact that my free time in general plummeted recently,
the fact that some of my desktops are having stability issues (freeze often
during compiling stuff), and the fact that I'm not allowed to run both my wife
and I's computer at home anymore at the same time (crappy wiring/electrical
setup for the apartment means that even something that small is too much of a
power draw and thus a fire hazard).  All kinds of stuff conspiring against me
getting any useful gnome stuff done.  I've got a big backlog before stuff like
154260 will ever come up.  I'm guessing it's gtk+-2.12 (NOT gnome 2.12)
material, unless someone else steps up.