Re: [Usability] Auto-raise windows while drag-drop engaged?

[Rob Adams <readams gnome org>]

Work is currently ongoing to allow windows to not be raised on drag 
start, so that you can drag from a window behind another window.  We are 
working with KDE developers and others to make this part of the 
freedesktop.org EWMH 1.3 draft specification.

I don't see us implementing "select behind" any time soon in metacity at 
least.  We would like to implement alt-tab switching and raising of drag 
target windows as well, including window switcher and workspace 
switcher, but technical issues* currently preclude this.  It is on the 
drawing board however and will likely require modification to the drag 
and drop specification.

You can follow the ongoing standardization discussion on the wm-spec 
mailing list:
http://mail.gnome.org/archives/wm-spec-list/

-Rob

* Basically the window handling the drag and drop has a mouse grab, so 
the WM doesn't know what's going on during the process.  We need a way 
for the apps participating in the drag and drop to communicate with the WM.

Máirín Duffy wrote:
> On Mon, 11 Oct 2004 20:13:17 +0300, Kalle Vahlman
> <kalle vahlman gmail com> wrote:
>
> > Consider a smaller window on top (and fully inside the frame) of a
> > larger window. You drag from a third window or even from the bigger
> > window, if the only criteria is the position of the mouse.  Now what
> > happens is that the small window is fully visible at the moment you
> > start the drag, but there's no way you are going to get a chance to
> > drop to that small window if the big one always pops over it. A
> > waiting time of x milliseconds is not going to erase that problem,
> > although it probably would lower the change of that happening. But it
> > can still happen, and at least personally I would shoot the programmer
> > after just one incident if I got the chance ;)
>
>
> This reminds me of an interaction from a drawing/graphic editing
> program, Macromedia Fireworks. Let me make an analogy - let's say the
> windows are rectangles on the canvas in Fireworks. There is a tool in
> Fireworks called the "Select Behind Tool," and it allows you to focus
> objects that are on the canvas but are hidden/partially hidden behind
> other objects.
>
> The way the tool works in the scenario that you described is that when
> the mouse is over the smaller rectangle that is enveloped by the
> bigger rectangle, the smaller rectangle will always get focus (even if
> it is hidden behind the larger rectangle.) You can select the bigger
> rectangle by mousing over the parts of its area that the smaller
> rectangle does not overlap.
>
> However, I think it would be annoying to have full windows popping out
> in front of each other - I think this would confuse users who would
> conclude that the windows are physically moving out of the order they
> left them in and potentially be upset / thrown off. It's a bad idea to
> move things from where users left them or even give off the appearance
> of doing so because they feel a loss of control and may panic. I think
> it would be better to show the outline/frame of each window as it's
> being "focused" (the same way that window outlines/frames are shown in
> Gnome as you alt-tab between windows.)
>
> It *is* important that people know more information about the window
> they are dragging into than just the approximate area and position of
> the window on the screen. Solutions to this could be a little tooltip
> thing that reads off the titlebar of the window, or maybe a little
> picture-in-picture-like preview window in one set place on the screen
> that shows a screenshot of the window (the PiP would probably have to
> be either really tiny or perhaps transparent so it wouldnt block the
> things under it.)
>
> Would all of this be worth the effort? I'm not quite sure; if the
> drag-to-the-taskbar behavior is implemented, then I'm not sure
> something like this would have a place, although it has two things
> going for it: (1) As far as I know, no other desktop implements such a
> feature, so it's kind of a flashy sort of a
> hey-look-at-this-Gnome-rocks sort of thing; (2) it's more visual than
> dragging things to a taskbar - it seem to fit the desktop metaphor
> better than dragging things to the taskbar, because in reality the
> papers on your desk are not anchored to anything.
>
> If this doesn't make much sense and you're curious I could make a
> mockup of what I mean; just email me.
>
> Raising the window under the mouse pointer on the click of the second
> mouse button or any other button is also a good solution, I think, but
> less easily discoverable.
>
> ~Máirín
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability