[Top][All Lists]
[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.