Simply put, Calum, there are already plenty of semantics available for raising a window: - Clicking on titlebar - Front key binding
We don't need the additional semantics of "click anywhere in window", and those additional semantics get in the way of using other mouse-based semantics such as copy/paste, click&drag, etc etc when you use partially-obscured windows. -Bob Calum Benson wrote: > > On 15 Sep 2009, at 13:39, Bob Doolittle wrote: > >> Frank Middleton wrote: >>> Maybe I missed a configuration option, but how about not bringing >>> windows to the front unless you hit the front key or click on the >>> title bar? If you are copying and pasting from one window to another >>> it used to be easier because you could keep the source window on top. >> >> +1 * 1000 >> >> It's *so* annoying trying to drag a message from thunderbird inbox >> window (which I normally have maximized in its own workspace) into a >> compose window attachment when every time I click the inbox window it >> jumps to the front and obscures my compose window. > > See > <http://blogs.gnome.org/metacity/2009/03/09/yes-dragon-drop-its-a-pun/> > for some background to this long-standing issue. > >> Also, why isn't "Lower" an available titlebar right-click menu option? > > I'd guess simply because not enough people (in the wider GNOME > community) use Raise and Lower to merit inclusion on the menu... if > enough people complain, there's more chance of it appearing. We could > also consider doing a local patch just for OpenSolaris, if there's > sufficient demand (but we prefer not to do that kind of thing). > > You can at least set up separate keyboard shortcuts for Raise and > Lower in the Keyboard Shortcuts dialog, if you wish -- by default, we > only set one for "Raise if obscured, otherwise Lower", which is bound > to the Front (F15) key. > > Cheeri, > Calum. >
