gcmd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gcmd-dev] d&d stuff


From: Michael
Subject: Re: [gcmd-dev] d&d stuff
Date: Fri, 12 Aug 2011 23:42:18 +0200
User-agent: claws-mail.org

Not that. It's this: When you drag some stuff with touchpad (or flakey mouse) 
and drop it 'upon' a folder. Then, before you release release the mouse (or 
toucpad) the folder still is marked by a light frame (in gcmd). But immediately 
when you release, the frame disappears. Some touchpads do 'jump' when you 
release (it's inevitable, depends on sensitivity) and optical mouse can also 
jump (tiny hand movement).

Now pops up the confirmation, but you can not verify the target. After copy / 
move is done, you can not see where it went. You would have to check manually 
by opening the folder.

If the frame would not disappear, even after the operation, then it would be 
rather clear and no check would be necessary.

>         `file1` is selected, but dragging is started from unselected
>         `file2` ?


> What gcmd should do here ? Move/copy `file1` ? Select additionally
> `file2` and drag 2 files ? Deselect `file1` and move/copy `file2` ?

uff. I don't know !

KDE avoids that problem - there is just no way to have the selection 
persistent; when you click on another file (without Ctrl modifier) then the 
previous selection is revoked.

But if we want to maintain the persistent selection in gcmd (and not just copy 
anything KDE does), then what ? 

With key F5 / F6, the actual behavior is safest (move only the selected) and 
most usable. If you went down a list and selected some files, and now at the 
end of the list, do you want to navigate back to some of the selected files to 
do the move / copy ? No. 

Perhaps it would be convenient if the 'actual file' highlight would temporarily 
disappear, when there is a different selection, to make clear you would operate 
on that selection and not on the actual file.

Now, with d&d, that's somehow not the same, because the whole idea of mouse is 
to be intuitively like 'your hand'. You grip something, and move it.

When i explicitly 'grip' one file then i'd expect this file to be moved / 
copied and not any other ! 

But should it be added to any already existing selection ? I'd say, no: If i 
want to d&d the selection, then i need to 'grip' that explicitly. For example, 
KDE changes mouse icon into an 'image' snapshot of the selected files, so you 
really have the feeling to drag the selection in 'one piece'.
That's straightforward with the above logic.

Now how does it feel to have different behavior with F keys and mouse ? I'd ask 
the other way round, why should they be equal ? F key is a tool, and mouse is 
just another, different tool. As long as you can accomplish anything with 
either one, it's totally ok when they are different.

That's how i would sort it out. YMMV.















reply via email to

[Prev in Thread] Current Thread [Next in Thread]