Re: DragNDrop to an unopened folder (without springs) and a nice accessibility side-effect

["Kevin C. Krinke" <kckrinke opendoorsoftware com>]

On Tue, 2005-04-05 at 00:35 +0900, Ryan McDougall wrote:
> On Mon, 2005-04-04 at 10:11 -0400, Kevin C. Krinke wrote:
> > On Mon, 2005-04-04 at 20:19 +0900, Ryan McDougall wrote:
> > > On Mon, 2005-04-04 at 12:48 +0300, Kalle Vahlman wrote:
> > > > On Apr 4, 2005 12:55 PM, Ryan McDougall <NQG24419 nifty com> wrote:
> > > > > On Mon, 2005-04-04 at 10:19 +0300, Kalle Vahlman wrote:
> 
> > 
> > I feel this is fundamentally wrong. The user should never get into a
> > situation where they are dragging around "a selection they never
> > dropped". See my suggestions below.
> 
> Why? Do you have more than a feeling?

Ok, the reason I feel this is fundamentally wrong is that the user
should not be allowed to become confused about something as simple as
copying/moving a file and that with your proposed solution would do just
that; allow for greater opportunity to confuse people.

Not that I'm saying the idea is all bad or anything, just that what
Nautilus needs is to behave in as natural and obvious a way as possible.

> > This solves the problem of
> > deciding whether or not the user used CTRL+C or CTRL+X to start the
> 
> There is no problem. The DnD becomes a cut/paste just as if you used the
> menu.

Ok, so I grab a file and begin to drag it somewhere, how does Nautilus
know that I want to copy it instead of moving it?

> > process and they get the benefit of being able to symlink the file or
> > cancel the operation. 
> 
> Poping up the context menu is interesting, but that adds another step
> that would make regular DnD more difficult, which I don't think should
> be allowed. Better to ditch the whole thing than muck up the main use
> case.

I'm not referring to "the" context menu, but rather the little one used
when middle-click-dragging and I see no reason why that code could not
be reused as-is (probably with minor adjustments for code exposure).
 
> > Now if all this is patented in some way and thing are implemented as you
> > suggest, I'd offer up another alternative...
> 
> All those examples include spring-loaded folders which won't be included
> so long as they're patented.

Yeah I thought that's what you meant by spring-loaded though I've never
really paid attention to that term before.

> >     1) left-click on a file, 3sec, icon added to "clipboard"
> >     2) find the desired folder for the operation
> >     3) right-click|middle-click to have the drag-menu pop-up
> > 
> > Doing it this way ensures that the user isn't dragging around an icon
> > all the time. Eventually they will want to right-click something and the
> > drag-menu would pop up. (Perhaps the name of the file in the clipboard
> > should appear in the list.)
> 
> If you replace right|middle with left that that is exactly what I
> suggested in my first email.

Well I don't see how you could replace the left-click instance with
anything as how is the user supposed to open up another folder?

>  The popup should be avoided since it slows down the normal DnD operation.

This is not a normal DnD operation. While I agree that if you DnD an
image from Nautilus into a Gimp window, then yes any popup would just be
silly however, this is not a normal DnD operation and so needs a
flexible and natural solution. Unless you can explain to me how Nautilus
will know whether the operation is a cut or a paste, I fail to see how
this whole operation is possible without the simple middle-click-drag
menu. Perhaps there is something I missed in your proposal.

> > As one final suggestion... if the mouse is inactive for more than a
> > minute (or some such gconf-set timeout) the clipboard is automatically
> > cleared.
> 
> I thought so too, but I don't know the performance characteristics of
> long lasting g_timeouts.

I honestly don't think there is too much overhead with this as it's a
very simple operation and in my Gtk2-Perl experience long lasting
g_timeouts (when used with moderation and specifically for simple tasks)
the overhead was negligible. I'll stand corrected if I'm wrong though.

> Thanks for the input.

Not a problem. I really like the overall idea as I tend to use the
middle-click drag for just about everything and know all too well the
pains of "click-drag... dang I need to open up another folder... drag
back to origin and release... blah blah blah"

-- 
Kevin C. Krinke <kckrinke opendoorsoftware com>
Open Door Software Inc.