Clicking on an inactive window should work like the Finder and Tracker does -
only brings it to front if your click couldn't start a drag. In other words, if
during your click you hit an icon, you just start a drag of that icon without
activating the window.

Not sure if the window manager can be fooled to do this. If not, we need to
lobby to add the support for windows that decide on their own if they want to be
activated during a click or not.



------- Additional Comments From sullivan@eazel.com 2000-07-24 12:54:34 ----

To me this sounds like something we can't possibly do for 1.0, no matter how
much we'd like to. Or is there still some hope that a simple solution is
currently available? If no solution is currently available, we should mark this
deferred since we can't possibly change other window managers before our first
release.



------- Additional Comments From pavel@eazel.com 2000-07-26 02:44:25 ----

We need to jump through hoops to fix things like this. If we don't, we are
loosers and we might as well quit. 



------- Additional Comments From sullivan@eazel.com 2000-07-26 18:09:41 ----

Just clarified the title.



------- Additional Comments From bud@eazel.com 2000-08-25 01:20:59 ----

I am using sawfish, and this seems to work ok for me.
Or maybe it is just too late at night. Moving to required so
it gets looked at. I agree with Pavel, we want to go the
extra mile to get this right.



------- Additional Comments From gzr@eazel.com 2000-10-02 09:57:40 ----

I am going to look at tweaking sawfish WM parameters on the fly to get the 
behavior we want.  I will try for two days to get this right. We should do 
this.  It would be very weak if we ship without this ability.



------- Additional Comments From sullivan@eazel.com 2000-10-13 11:45:53 ----

I agree that it would be much better if we could get this to work. But it
boggles my mind that this is considered a PR2-worthy bug. I'm moving it back to
"undecided" to give Bud a chance to rethink this.



------- Additional Comments From eli@eazel.com 2000-10-16 20:13:36 ----

Batch-assigning QA ownership of remaining bugs to eli@eazel.com



------- Additional Comments From bud@eazel.com 2000-10-17 12:27:26 ----

Given current PR2 buglist, moving this to Release.



------- Additional Comments From sullivan@eazel.com 2000-11-30 08:31:49 ----

I would just defer this but I think Pavel and Gene would kill me.



------- Additional Comments From don@eazel.com 2000-12-15 09:32:53 ----

Batch move all 254 PR3 P5 bugs to 1.0.1.




------- Additional Comments From gzr@eazel.com 2000-12-28 16:05:20 ----

This is just the type of bug you love.



------- Additional Comments From jsh@pixelslut.com 2000-12-31 08:30:30 ----

I've just drafted a patch to fix this, together with an extra sawfish feature
that allows windows to control whether they get raised or not in certain
situations.

(my patch doesn't work for drags from components in external processes, I have
no idea how to communicate the drag being started back to the main process..?)

I'll test this stuff when I get back to the US in a few days time..




------- Additional Comments From jsh@pixelslut.com 2001-01-03 11:31:44 ----

My patch (currently: ~jsh/nautilus-dnd-focus-patch) almost works, but the method
of detecting drags (emission hook on `drag_start' signal) is sub-optimal.

This is because the code only starts drags on motion events, not button presses.
So if I click an icon, pause for >1/10 second (the timeout), then start
dragging, the window will have already been focused before the drag starts..




------- Additional Comments From jsh@pixelslut.com 2001-01-03 18:04:13 ----

This should work now. The `don't raise' part currently requires a cvs sawfish
(will work with 0.35 when that is available in the near future)



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:33 -------

The original reporter (pavel@eazel.com) of this bug does not have an account here.
Reassigning to the exporter, unknown@bugzilla.gnome.org.