Re: [platform-swt-dev] Drag and drop update

[Steve Northover <Steve_Northover@xxxxxxxxxx>]

Thanks Scott.  I looked through
the code quicky for leaks etc. and it looked good.  I'm getting Duong
to run it and test it a bit.  I'm very happy!

A couple of very small style points.
 As we are on the bottom of the tool stack, we import * rather than
each individual class (Eclipse preferences can be set to do this).  Also,
in a comment, we would never use the word "snarf" (although there
is nothing really wrong with it as far as I can see).

Here's the story:  Years ago, I
used to have fun writing comments in code.  If you've ever heard of
the term "cheese" for pixel corruption, that's mine.  In
any case, each time before we shipped, my source was grep'd and some person
who didn't share my sense of humour made me take things out and reword
stuff.  After a few iterations of this (and the time that it wasted,
both mine and the reviewer), I vowed "never again".  The
result was ... well, boring software, but all software is boring in some
sense.  The upside was that I never had to ask the question, "Is
there anything bad in the comments in the code".

So, what do you think?  Like many
things, it's defacto SWT policy to be really formal in comments, even avoiding
the word "I".

P.S.  Now I am the guy grep'ing
the code.

Scott Kovatch <skovatch@xxxxxxxxx>
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx

09/24/2008 05:05 PM

Please respond to
"Eclipse Platform SWT component developers list."        <platform-swt-dev@xxxxxxxxxxx>

To	"Eclipse Platform SWT component developers list." <platform-swt-dev@xxxxxxxxxxx>
cc
Subject	[platform-swt-dev] Drag and drop update

Hi there,

Once CVS starts cooperating a bit more, I plan to check in the DND work
for Cocoa. Here’s where it stands:

-- I compared against the Carbon version and verified that the identical
stream of events and data are generated in the DNDExample for all controls
in the example.
-- HTML, RTF, Text, and URLTransfers continue to work as they did before.
I cleaned up URLTransfer a bit so it encodes the string in javaToNative
to be something that URLWithString will accept.
-- Key modifiers change the cursor image as discussed earlier on the list,
and follow Cocoa conventions. It’s only in the 32-bit version; not sure
what we will do in 64-bit yet, but we’re not the only ones in this situation.
-- Caller-provided images for the drag should be working; I had to fake
this a bit to test it. When I have some time I’ll modify the DND example
to allow for testing a custom image in the drag.

At this point I’m aware of only one known problem. Cocoa apps don’t have
a way to provide a list of files to the Finder using HFSFlavors like you
have in Carbon. Instead, you place an NSArray of file names on the dragging
clipboard with a flavor of NSFilenamesPboardType. Other Cocoa-based apps
can understand that format, and I verified it works, but the Finder and
other Carbon apps do not, so they don’t recognize the drag data. I don’t
know what functionality is expected of FileTransfer across platforms, so
I don’t know if the Carbon behavior was accidental or deliberate. Cocoa
lets you do HFS promise file drags, but I don’t think that’s the same
thing. I’ll do what I can to follow up with folks at Apple.

I have to tend to some problems on my main project, so it may be a day
or two before I move on to something new. Unless you want me to look at
something else, I can start trying to understand accessibility.

Scott

--------------- 
Scott Kovatch
Flex Engineering
Adobe Systems, Inc.
skovatch@xxxxxxxxx

I am Scott Kovatch, and I approved this message._______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev