Re: Drag and drop creates some kind of self referential loop

I know now emelfm2 conforms to the dnd standard, but as recent as
0.0.9-r1 if you dragged the mouse downward you would select files (this
is the only e2 build currently available in portage).  Now, with 0.1.2,
you pick up the first file you start clicking on.  So for me and a few
people I know, its a change in how to use emelfm2.  I personally enjoy
the former behavior better, and I was just suggesting having a
configuration option about this, where the default was to allow drag and
drop, but the user could deselect it if it suited them.  Or, even better
probably, let the user select which mouse button activated the
pick-up-item action (I think it was the middle click previously).  So
letting people swap which mouse press did what (activating dnd or just
plain selecting files) would be something I'd like to see.  I don't want
to remove dnd from the app, I just want to have more options to use it
:P

About the bug I mentioned, I know that the standard action when you drop
onto a folder is to put it inside the folder, but if you drag a folder
*to itself*, shouldn't it do nothing, prompt you, or do something
similar?  Here it creates some kind of copy loop (not really infinite,
but it goes down quite a few levels), which is hardly something I'd
think people want to happen, especially if the folder you're dragging to
yourself has some pretty large files.  Copying to other folders is fine,
that's what I'd expect to happen.  But self copying loops (or whatever
you would call this) doesn't seem like very good behavior.  Its very
easy to reproduce in the current tarball from the main site, but if you
don't see this behavior maybe its a gtk bug?  In any case I think
dragging to yourself should be some kind of special case.  Just to test
it out in other drag n drop applications, I started rox-filer up and
made a new dir and tried to drag to itself, and it wouldn't let me.  I
don't have nautilus installed but I don't think you can do it there
either.

In any case, I'd just want to suggest what I said before about maybe
having the dnd be configurable.  Also, another thing I just thought of
was an option to select whether drag and drop would copy or move the
files, as someone might want to just copy, others might want to
completely move the items (like myself).  You could add a couple dnd
options to the general preferences or something, and default the options
to the dnd standard or something.  Just a thought.

Sorry for the long spiel anyway :P  I love emelfm and I really
appreciate all the hard work that everyone puts into it.  Thanks!

On Sun, 18 Sep 2005 18:10:54 +1000, "TomPh" <tpgww@xxxxxxxxxxx> said:
> On Sat, 17 Sep 2005 12:28:17 -0400
> alaterale@xxxxxxxxxxxxx wrote:
> 
> > I noticed that the default for clicking and dragging the mouse in
> > emelfm2 has changed to the drag and drop functionality.
> DnD conforms to what seem to be gtk-default arrangements, or at least,
> the arrangements reflected in the dnd cursor-overlays (none for move, +
> for copy, ? for menu) which are instigated by gtk, not e2.
> 
>   While this is
> > fine (and I wanted to suggest having a configuration option that could
> > default to dnd but could also disable it if the user wanted to, as I'd
> > like to be able to disable it myself :P)
> Not sure what you mean here ... default what to dnd ?
> 
> , I noticed a very annoying
> > bug I thought I should report in the latest emelfm2 (0.1.2).
> > 
> > If you click on a folder and drag it, even accidentally, and then drop
> > it back on itself, it makes embedded folder hierarchies within that
> > folder that match the one you started at.
> That's the way dropping is designed to work. It assumes that a drop
> ONto a dir is, in effect, a deliberate instruction to drop INto it,
> and will process all the selected items, if there are more than one.
> It's a quick way to bypass opening the dir in the other pane.
> 
> Usually we see a 'target' dir highlighted, as a hint about what will
> happen, but when dropping onto a selected item, gtk's selection-coloring
> prevails, of course. We still see the dnd cursor. We can cancel the
> drop by moving the cursor to somewhere in the same pane that's not a
> directory, before releasing the button.
> 
> 'on-selection' dropping could readily be blocked, at the expense of
> anyone who wants to do it deliberately, from inside or outside e2.
> I suppose, UI consistency takes a hit too.
> 
> That said, it could be that, on balance, such protection would be a
> better choice than current arrangements ...
> 
> All views welcome.
> 
> > I'm not sure if this bug has already been reported, I've tried
> > searching for it, but can't come up with anything.
> This is the first report on the matter. And thanks for taking the time
> to do so. All feedback is most welcome.
> 
> Regards
> Tom
> 
> 
> -- 
> Users can unsubscribe from the list by sending email to
> emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or
> by logging into the web interface.


-- 
Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: