[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Mac OS 10.4 Finder drag and drop development
|
Eric, if the slowdown happens to you, you'll understand why it's a
blocker. In any case, it's the _severity_ that is set to blocker. This
value is managed by the person who entered the bug; it indicates how much
of a problem it is for *you*. The _priority_ of the bug is what indicates
how serious it is thought to be by the developers.
McQ.
Eric Zimmerman <eric@xxxxxxxxxxx>
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx
05/17/05 20:31
Please respond to
"Eclipse Platform SWT component developers list."
To
"Eclipse Platform SWT component developers list."
<platform-swt-dev@xxxxxxxxxxx>
cc
Subject
Re: [platform-swt-dev] Mac OS 10.4 Finder drag and drop development
Veronika Irvine wrote:
>You might want to check out this thread in the eclipse.platform.swt
>newsgroup:
>
>"OS X Drag&Drop to Finder / InDesign" from Wolfgang Werner
>
>http://dev.eclipse.org/newslists/news.eclipse.platform.swt/msg18484.html
>
>
>
Ok...I spent today messing around with the latest build and your new
data promise implementation....it did not solve anything for me but made
me understand the problem with drag source. When you add drag flavors
in DragSource.java you cannot just index the item reference every time
you add a drag flavor. This item reference should ONLY be changed for
each unique item being dragged. So if you change drag source (Working
of the R3.0 tree) to reset the index right before you cycle through the
flavors then each drag item DOES get a single unique reference
identifier and drags from an SWT application to the finder work great.
My guess is that this bug has been in the DND on Mac since the beginning
since there has always been inconsistent behavior.
My guess on the furl source was correct also...this needed to be
implemented for the finder to accept a drop.
I am not sure how you can reconcile this issue with your new DND code
that has promised flavors since you have no idea how many items are
being dragged (funny...there is even a comment in the code about that :-).
Anyway...I am going to get my code cleaned up, test against 10.3 and
then submit the code under bug #93619
Not exactly sure why this bug has normal priority while an intermittent
slowdown bug on tiger has blocker priority??? Seems like random
priorities to me....guess it's who you know ;-)
Thanks,
Eric*
*
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
