[prev in list] [next in list] [prev in thread] [next in thread]
List: kfm-devel
Subject: Re: Review Request: [Dolphin] Fake click for short drag and drop on same item
From: Thomas_Lübking <thomas.luebking () web ! de>
Date: 2012-12-27 21:15:44
Message-ID: 20121227211544.7019.74247 () vidsolbach ! de
[Download RAW message or body]
> On Dec. 14, 2012, 3:56 p.m., Frank Reininghaus wrote:
> > First of all, thanks for the patch! I see now that dragging items accidentally \
> > when trying to click happens a lot for some users, and I agree that fixing this \
> > would be nice.
> > I'm just wondering if there is an easier way to do it, without making \
> > DragAndDropHelper depend on KItemListController and adding the hand-made \
> > press/release events. I have two ideas at the moment:
> > 1. Make KItemListController finally respect \
> > http://qt-project.org/doc/qt-4.8/qapplication.html#startDragTime-prop, and only \
> > start a drag in KItemListController::mouseMoveEvent() if the time since the mouse \
> > press event is larger than that, or
> > 2. Check in KItemListController::mouseMoveEvent() if the mouse cursor is still \
> > above the item where the press happened, and do not start a drag if that is the \
> > case.
> > Both approaches would prevent that the drag is started, whereas your idea was to \
> > sort of cancel the drag after it happened. Not starting the drag in the first \
> > place might be a bit cleaner and require less code from my point of view. But \
> > maybe there is a good reason why you chose to do it in a different way?
>
> Thomas Lübking wrote:
> Supporting the dragtimeout is even simpler, but the default of 500ms makes it \
> appear quite laggy on inteded DnD ops (you press, hold, drag and for the first half \
> second nothing happens) - esp. since apparently no Q/KItemView seems to care much \
> about it.
> If you'd advice ppl. to shorten the timeout to sth. "reasonable" (below 150ms), \
> they'll again run into the accidental drags.
> I'll update the patch later on to simply respect the timeout so that you can try \
> for yourself.
> Christoph Feck wrote:
> > you press, hold, drag and for the first half second nothing happens
>
> Unless you drag it far enough (= startDragDistance), this is the expected (and \
> correct) behaviour. Try window dragging by click-move on the title bar.
> Thomas Lübking wrote:
> Ok, thanks (never waited so log ;-)
> Just that the expected "autodrag w/o move" won't help on the particular issue \
> (since the drag distance is respected and effectively the problem)
> @Frank: we could simply keep the dragTime in the DragAndDropHelper instead to avoid \
> deps. on the controller.
> Kai Uwe Broulik wrote:
> If we'd just turn off that "A folder cannot be dropped onto itself" message, a huge \
> annoyance would be already gone ;) *scnr*
> Frank Reininghaus wrote:
> Thanks Thomas for the new patch and everyone else for the comments, in particular \
> Christoph - I somehow thought the idea was to start a drag when "distance > \
> startDragDistance" && "time since press > startDragTime", but with && replaced by \
> ||, it makes much more sense indeed :-)
> @Kai: "If we'd just turn off that "A folder cannot be dropped onto itself" message, \
> a huge annoyance would be already gone":
> No, in that case, we would get bug reports like "Clicking items fails randomly".
>
> @Thomas: I see that it's getting better :-) But I still think that this is a lot \
> more complex than it needs to be. Why not just put the timer into \
> KItemListController, start it when the mouse button is pressed, and in \
> mouseMoveEvent, if the drag distance is too small, check if the time since the \
> press is larger than startDragTime and do not start a drag if that is not the case. \
> This should mostly yield the same result and require a lot less code and no \
> dependencies between KItemListController and DragAndDropHelper, or am I overlooking \
> anything?
> Thomas Lübking wrote:
> This will effectively increase the QApplication::startDragDistance(), because for \
> the first 500ms -assuming default value in place- the drag distance is increased to \
> not "too small" and 500ms is much time in this context.
> You can try the outcome by increasing it legally in "kcmshell4 mouse" - it's capped \
> @ 20px, though, while a quick judder (the typical movement is down and up) can be \
> much more (esp. depending on screen resolution and mouse acceleration)
> I'm willing add an update, but notice that the approach omits the best variable for \
> the heuristic (button release, ie. drag time) and trap us between false positives \
> (dialog/notification) and laggy DnD behavior (even with 20px it's rather "strange" \
> when the DnD suddenly starts)
> If you just don't like the interdependency, it would be possible to (from the \
> controller) store the msecsSinceReference (kinda "current time", but monotic) as \
> dynamic property "DolphinDragStartTime" on the QApplication object and fetch and \
> compare it from there DnDHelper.
> Frank Reininghaus wrote:
> Well, I'm not a usability expert, but IMHO, not starting the drag if we think that \
> the user does not want to drag might be better and less distracting than starting \
> the drag, changing the mouse cursor for that, and then reverting the drag after the \
> drop.
> Code-wise, I also think that not starting the drag is better. It requires a lot \
> less code. Moreover, I'm worried that the hand-made press and release events might \
> lead to strange bugs in the future. They are delivered inside the nested event loop \
> of the drag, and I've really had a lot of unpleasant experiences with nested event \
> loops in the past.
> I see that replacing the check "distance > startDragDistance" by "distance > \
> startDragDistance || time > startDragTime" would not resolve the "accidental drag" \
> problem (it might make our behaviour more 'correct' though, but I just checked the \
> source of QAbstractItemView and found that it does not care about the startDragTime \
> either).
> What about the following idea: I guess that users never drag an item to drop it on \
> itself. We could (in KItemListController::mouseMoveEvent) determine the 'index' \
> which belongs to the position of the event and just not start the drag if this \
> index is equal to m_pressedIndex. I've suggested that earlier, but nobody commented \
> on that idea. Am I overlooking anything which is obviously wrong with that idea?
>
> Thomas Lübking wrote:
> > not starting the drag if we think that the user does not want to drag might be \
> > better
> Yes, of course. The tricky part is to figure what the user wants.
> The pre-action information is the drag distance, which you intend to increase (by \
> tests in the former and last comments) what's (given the misclick isn't a dolphin \
> only phenomenon) equal to telling the user to do so in the settings. This is oc. \
> the best solution to prefer clicks, but comes with a pubishment to DnD.
> If you simply increase it internally, be better prepared for "dolpin doen not \
> respect dnd startdistance" bugs.
> The startdistance actually exists for this purpose (smoothing away dirty clicks) \
> and if usually sufficient, it's not reasonable to increase the setting, nor \
> hardcode a higher value (just think of 128px icons...)
> What is special about dolphin and source of the bug reports is its treatment of \
> user failure. Usually, if a DnD cannot take place, the action silently quits \
> (previously hinted by the "forbidden" cursor) but dolphin currently "annoys" the \
> user with a (ui re-layouting) message (in this case false positive hint) to \
> "punish" his failure (thus Kais scnr)
> So my focus would not be on blocking the drag in the first place (there's a setting \
> for this and dolphin does not differ from any other client in that regard) but on \
> failure treatment.
> This could also be a timeout on just showing the dialog - i just thought that since \
> we pretty much (now!) know what the user intended, we could just do that for him.
> Frank Reininghaus wrote:
> Well, either I don't understand you, or you don't understand me, but the result is \
> the same either way ;-)
> I did not say that I intend to increase the 'start drag disctance'. Therefore, I \
> don't see why we would get "dolpin does not respect dnd startdistance" bugs. I \
> probably wasn't clear enough the first two times, so I will just try to say again \
> what my idea to resolve this is:
> 1. When the mouse moves, we check if the mouse cursor is still above the item where \
> the button was pressed. If that is the case, we don't start a drag (just like if \
> the distance between the press and move events is less than the 'start drag \
> distance').
> 2. Because no drag was started, mouseReleaseEvent will behave just like after a \
> click, and will trigger the item.
> This means: a drag is only started when the cursor moves out of the bounds of the \
> item where the mouse was pressed AND if the distance between press and release is \
> larger than the 'start drag distance', whatever the user chose for it.
> Before we continue the discussion, could please anyone tell me what is wrong with \
> this approach?
> About the 'folder cannot be dropped on itself' message: I didn't invent it, and \
> from my point of view it's fine to replace it with something else, or even to show \
> a 'forbidden cursor' (unless there was a good reason why the message has been added \
> in the first place, which I don't know at the moment).
> Thomas Lübking wrote:
> Sorry, i was abroad (need to move reviewboard to gmail)
>
> > 1. When the mouse moves, we check if the mouse cursor is still above the item \
> > where the button was pressed. If that is the case, we don't start a drag
>
> What effectively increases the startDragDistance.
>
> The default value here is 4px while the minimum icon size is 16px, many users will \
> use up to 64px (or even more, eventually plus 2-3 lines of text) what means a \
> startDragDistance of 8px - 32px (if you click the center and move straight out).
> I do not discuss in terms of wrong or right (outside math ;-) but there's a notable \
> difference in the behavior if you enforce to leave an item to start the DnD which \
> grows with the icon size. Assumption that there'll be a bug report about it is just \
> "bugzilla experience gut feeling" - i've no proof for that =)
> Frank Reininghaus wrote:
> Thanks for the clarification and sorry for the late reply (real life kept me busy \
> around Christmas)!
> You are right - I had only considered the fact that users probably never want to \
> start a drag and then drop on the same item. But if the "drag pixmap" is only shown \
> after the mouse cursor has left the item, then this does feel different, and there \
> is indeed the possibility that some people might consider this annoying.
> I think the best way to improve the user experience might be to show a "drop \
> forbidden" cursor while hovering the item where the drag started, rather than \
> accepting the drop and then showing the annoying error message.
> I see that accepting the drop and then "canceling" the drag after it happened might \
> also help to reduce the effects of the annoying message, but I think that the \
> "fake" events are likely to cause trouble at some point in the future :-(
Nevermind the lag.
You could still show the dialog after a longer drag (to hint that this is illegal by \
intent) but silently fail on a short term judder (assuming that ppl. won't be able to \
coordinate the perception of the started drag and then drop the item within less then \
500ms while nobody will hold the button that long for a click) That includes no \
sythetic events at all.
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107708/#review23469
-----------------------------------------------------------
On Dec. 14, 2012, 9:25 p.m., Thomas Lübking wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107708/
> -----------------------------------------------------------
>
> (Updated Dec. 14, 2012, 9:25 p.m.)
>
>
> Review request for Dolphin and Frank Reininghaus.
>
>
> Description
> -------
>
> When there's a relatively short click (i picked 500ms) and the item is moved to DnD \
> and released on itself, this is now assumed a "dirty click" (ie. the user actually \
> wanted to click, but juddered) instead of presenting a warning that an item cannot \
> be dragged on itself.
> Notes:
> - 500ms are quite some time. I can drag the icon out, back in and drop it in place.
> - due to the high abstraction level in the DnD processing and the application \
> window being the drag source, it is technically possible to split the view and DnD \
> an icon onto its other self within 500ms
> I'm however willing to state that if you manage to do either of that, you should \
> not have major issues on performing a regular click either. I picked the 500ms on \
> personal test (started with 1500, what seems far too much)
> - the reason for having the timeout in the first place is the assumption, that \
> users may actually intentionally try to drag an item on itself. Either because they \
> intend to link it there (link recursion can be dangerous, but is a legal action) or \
> for "ummm... i didn't want to copy that folder. errr... how do i stop this ... ok, \
> let's just put it back from where it came and hope for the best". Because of the \
> latter i think this should be hinted after the message freeze.
> - one might want to add a "don't ask again" checkbox to the hint and account that \
> by dropping the timeout
>
> This addresses bugs 283646, 297414, 307747, and 311483.
> http://bugs.kde.org/show_bug.cgi?id=283646
> http://bugs.kde.org/show_bug.cgi?id=297414
> http://bugs.kde.org/show_bug.cgi?id=307747
> http://bugs.kde.org/show_bug.cgi?id=311483
>
>
> Diffs
> -----
>
> dolphin/src/kitemviews/kitemlistcontroller.cpp 697e04f
> dolphin/src/views/draganddrophelper.h ac16f7c
> dolphin/src/views/draganddrophelper.cpp f81d4d0
>
> Diff: http://git.reviewboard.kde.org/r/107708/diff/
>
>
> Testing
> -------
>
> clickdragged a folder in both view (w/ and w/o scroll offset)
>
>
> Thanks,
>
> Thomas Lübking
>
>
[Attachment #3 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/107708/">http://git.reviewboard.kde.org/r/107708/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On December 14th, 2012, 3:56 p.m., <b>Frank \
Reininghaus</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px \
solid #d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">First of all, thanks for the patch! I see now that dragging items \
accidentally when trying to click happens a lot for some users, and I agree that \
fixing this would be nice.
I'm just wondering if there is an easier way to do it, without making \
DragAndDropHelper depend on KItemListController and adding the hand-made \
press/release events. I have two ideas at the moment:
1. Make KItemListController finally respect \
http://qt-project.org/doc/qt-4.8/qapplication.html#startDragTime-prop, and only start \
a drag in KItemListController::mouseMoveEvent() if the time since the mouse press \
event is larger than that, or
2. Check in KItemListController::mouseMoveEvent() if the mouse cursor is still above \
the item where the press happened, and do not start a drag if that is the case.
Both approaches would prevent that the drag is started, whereas your idea was to sort \
of cancel the drag after it happened. Not starting the drag in the first place might \
be a bit cleaner and require less code from my point of view. But maybe there is a \
good reason why you chose to do it in a different way?</pre> </blockquote>
<p>On December 14th, 2012, 5:22 p.m., <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Supporting the \
dragtimeout is even simpler, but the default of 500ms makes it appear quite laggy on \
inteded DnD ops (you press, hold, drag and for the first half second nothing happens) \
- esp. since apparently no Q/KItemView seems to care much about it.
If you'd advice ppl. to shorten the timeout to sth. "reasonable" (below \
150ms), they'll again run into the accidental drags.
I'll update the patch later on to simply respect the timeout so that you can try \
for yourself.</pre> </blockquote>
<p>On December 14th, 2012, 5:44 p.m., <b>Christoph Feck</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> you press, hold, \
drag and for the first half second nothing happens
Unless you drag it far enough (= startDragDistance), this is the expected (and \
correct) behaviour. Try window dragging by click-move on the title bar.</pre> \
</blockquote>
<p>On December 14th, 2012, 5:58 p.m., <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Ok, thanks (never waited \
so log ;-) Just that the expected "autodrag w/o move" won't help on the \
particular issue (since the drag distance is respected and effectively the problem)
@Frank: we could simply keep the dragTime in the DragAndDropHelper instead to avoid \
deps. on the controller.</pre> </blockquote>
<p>On December 14th, 2012, 6:52 p.m., <b>Kai Uwe Broulik</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">If we'd just turn \
off that "A folder cannot be dropped onto itself" message, a huge annoyance \
would be already gone ;) *scnr*</pre> </blockquote>
<p>On December 16th, 2012, 7:12 p.m., <b>Frank Reininghaus</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Thanks Thomas for the \
new patch and everyone else for the comments, in particular Christoph - I somehow \
thought the idea was to start a drag when "distance > startDragDistance" \
&& "time since press > startDragTime", but with && \
replaced by ||, it makes much more sense indeed :-)
@Kai: "If we'd just turn off that "A folder cannot be dropped onto \
itself" message, a huge annoyance would be already gone":
No, in that case, we would get bug reports like "Clicking items fails \
randomly".
@Thomas: I see that it's getting better :-) But I still think that this is a lot \
more complex than it needs to be. Why not just put the timer into \
KItemListController, start it when the mouse button is pressed, and in \
mouseMoveEvent, if the drag distance is too small, check if the time since the press \
is larger than startDragTime and do not start a drag if that is not the case.
This should mostly yield the same result and require a lot less code and no \
dependencies between KItemListController and DragAndDropHelper, or am I overlooking \
anything?</pre> </blockquote>
<p>On December 16th, 2012, 8:19 p.m., <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This will effectively \
increase the QApplication::startDragDistance(), because for the first 500ms -assuming \
default value in place- the drag distance is increased to not "too small" \
and 500ms is much time in this context.
You can try the outcome by increasing it legally in "kcmshell4 mouse" - \
it's capped @ 20px, though, while a quick judder (the typical movement is down \
and up) can be much more (esp. depending on screen resolution and mouse \
acceleration)
I'm willing add an update, but notice that the approach omits the best variable \
for the heuristic (button release, ie. drag time) and trap us between false positives \
(dialog/notification) and laggy DnD behavior (even with 20px it's rather \
"strange" when the DnD suddenly starts)
If you just don't like the interdependency, it would be possible to (from the \
controller) store the msecsSinceReference (kinda "current time", but \
monotic) as dynamic property "DolphinDragStartTime" on the QApplication \
object and fetch and compare it from there DnDHelper.</pre> </blockquote>
<p>On December 18th, 2012, 7:29 a.m., <b>Frank Reininghaus</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Well, I'm not a \
usability expert, but IMHO, not starting the drag if we think that the user does not \
want to drag might be better and less distracting than starting the drag, changing \
the mouse cursor for that, and then reverting the drag after the drop.
Code-wise, I also think that not starting the drag is better. It requires a lot less \
code. Moreover, I'm worried that the hand-made press and release events might \
lead to strange bugs in the future. They are delivered inside the nested event loop \
of the drag, and I've really had a lot of unpleasant experiences with nested \
event loops in the past.
I see that replacing the check "distance > startDragDistance" by \
"distance > startDragDistance || time > startDragTime" would not \
resolve the "accidental drag" problem (it might make our behaviour more \
'correct' though, but I just checked the source of QAbstractItemView and \
found that it does not care about the startDragTime either).
What about the following idea: I guess that users never drag an item to drop it on \
itself. We could (in KItemListController::mouseMoveEvent) determine the \
'index' which belongs to the position of the event and just not start the \
drag if this index is equal to m_pressedIndex. I've suggested that earlier, but \
nobody commented on that idea. Am I overlooking anything which is obviously wrong \
with that idea? </pre>
</blockquote>
<p>On December 18th, 2012, 2:42 p.m., <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> not starting the \
drag if we think that the user does not want to drag might be better Yes, of course. \
The tricky part is to figure what the user wants. The pre-action information is the \
drag distance, which you intend to increase (by tests in the former and last \
comments) what's (given the misclick isn't a dolphin only phenomenon) equal \
to telling the user to do so in the settings. This is oc. the best solution to prefer \
clicks, but comes with a pubishment to DnD.
If you simply increase it internally, be better prepared for "dolpin doen not \
respect dnd startdistance" bugs.
The startdistance actually exists for this purpose (smoothing away dirty clicks) and \
if usually sufficient, it's not reasonable to increase the setting, nor hardcode \
a higher value (just think of 128px icons...)
What is special about dolphin and source of the bug reports is its treatment of user \
failure. Usually, if a DnD cannot take place, the action silently quits (previously \
hinted by the "forbidden" cursor) but dolphin currently "annoys" \
the user with a (ui re-layouting) message (in this case false positive hint) to \
"punish" his failure (thus Kais scnr)
So my focus would not be on blocking the drag in the first place (there's a \
setting for this and dolphin does not differ from any other client in that regard) \
but on failure treatment.
This could also be a timeout on just showing the dialog - i just thought that since \
we pretty much (now!) know what the user intended, we could just do that for \
him.</pre> </blockquote>
<p>On December 18th, 2012, 5:32 p.m., <b>Frank Reininghaus</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Well, either I don't \
understand you, or you don't understand me, but the result is the same either way \
;-)
I did not say that I intend to increase the 'start drag disctance'. \
Therefore, I don't see why we would get "dolpin does not respect dnd \
startdistance" bugs. I probably wasn't clear enough the first two times, so \
I will just try to say again what my idea to resolve this is:
1. When the mouse moves, we check if the mouse cursor is still above the item where \
the button was pressed. If that is the case, we don't start a drag (just like if \
the distance between the press and move events is less than the 'start drag \
distance').
2. Because no drag was started, mouseReleaseEvent will behave just like after a \
click, and will trigger the item.
This means: a drag is only started when the cursor moves out of the bounds of the \
item where the mouse was pressed AND if the distance between press and release is \
larger than the 'start drag distance', whatever the user chose for it.
Before we continue the discussion, could please anyone tell me what is wrong with \
this approach?
About the 'folder cannot be dropped on itself' message: I didn't invent \
it, and from my point of view it's fine to replace it with something else, or \
even to show a 'forbidden cursor' (unless there was a good reason why the \
message has been added in the first place, which I don't know at the \
moment).</pre> </blockquote>
<p>On December 21st, 2012, 9:23 p.m., <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Sorry, i was abroad \
(need to move reviewboard to gmail)
> 1. When the mouse moves, we check if the mouse cursor is still above the item \
where the button was pressed. If that is the case, we don't start a drag
What effectively increases the startDragDistance.
The default value here is 4px while the minimum icon size is 16px, many users will \
use up to 64px (or even more, eventually plus 2-3 lines of text) what means a \
startDragDistance of 8px - 32px (if you click the center and move straight out).
I do not discuss in terms of wrong or right (outside math ;-) but there's a \
notable difference in the behavior if you enforce to leave an item to start the DnD \
which grows with the icon size. Assumption that there'll be a bug report about it \
is just "bugzilla experience gut feeling" - i've no proof for that \
=)</pre> </blockquote>
<p>On December 27th, 2012, 9:04 p.m., <b>Frank Reininghaus</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Thanks for the \
clarification and sorry for the late reply (real life kept me busy around Christmas)!
You are right - I had only considered the fact that users probably never want to \
start a drag and then drop on the same item. But if the "drag pixmap" is \
only shown after the mouse cursor has left the item, then this does feel different, \
and there is indeed the possibility that some people might consider this annoying.
I think the best way to improve the user experience might be to show a "drop \
forbidden" cursor while hovering the item where the drag started, rather than \
accepting the drop and then showing the annoying error message.
I see that accepting the drop and then "canceling" the drag after it \
happened might also help to reduce the effects of the annoying message, but I think \
that the "fake" events are likely to cause trouble at some point in the \
future :-(</pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Nevermind the lag. You \
could still show the dialog after a longer drag (to hint that this is illegal by \
intent) but silently fail on a short term judder (assuming that ppl. won't be \
able to coordinate the perception of the started drag and then drop the item within \
less then 500ms while nobody will hold the button that long for a click) That \
includes no sythetic events at all.</pre> <br />
<p>- Thomas</p>
<br />
<p>On December 14th, 2012, 9:25 p.m., Thomas Lübking wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for Dolphin and Frank Reininghaus.</div>
<div>By Thomas Lübking.</div>
<p style="color: grey;"><i>Updated Dec. 14, 2012, 9:25 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">When there's a relatively short click (i picked 500ms) and the item \
is moved to DnD and released on itself, this is now assumed a "dirty click" \
(ie. the user actually wanted to click, but juddered) instead of presenting a warning \
that an item cannot be dragged on itself.
Notes:
- 500ms are quite some time. I can drag the icon out, back in and drop it in place.
- due to the high abstraction level in the DnD processing and the application window \
being the drag source, it is technically possible to split the view and DnD an icon \
onto its other self within 500ms
I'm however willing to state that if you manage to do either of that, you should \
not have major issues on performing a regular click either. I picked the 500ms on \
personal test (started with 1500, what seems far too much)
- the reason for having the timeout in the first place is the assumption, that users \
may actually intentionally try to drag an item on itself. Either because they intend \
to link it there (link recursion can be dangerous, but is a legal action) or for \
"ummm... i didn't want to copy that folder. errr... how do i stop this ... \
ok, let's just put it back from where it came and hope for the best". \
Because of the latter i think this should be hinted after the message freeze.
- one might want to add a "don't ask again" checkbox to the hint and \
account that by dropping the timeout</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">clickdragged a folder in both view (w/ and w/o scroll offset)</pre> \
</td> </tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="http://bugs.kde.org/show_bug.cgi?id=283646">283646</a>,
<a href="http://bugs.kde.org/show_bug.cgi?id=297414">297414</a>,
<a href="http://bugs.kde.org/show_bug.cgi?id=307747">307747</a>,
<a href="http://bugs.kde.org/show_bug.cgi?id=311483">311483</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>dolphin/src/kitemviews/kitemlistcontroller.cpp <span style="color: \
grey">(697e04f)</span></li>
<li>dolphin/src/views/draganddrophelper.h <span style="color: \
grey">(ac16f7c)</span></li>
<li>dolphin/src/views/draganddrophelper.cpp <span style="color: \
grey">(f81d4d0)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/107708/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic