Home » Eclipse Projects » Standard Widget Toolkit (SWT) » OS X Drag&Drop to Finder / InDesign
| OS X Drag&Drop to Finder / InDesign [message #451714] |
Mon, 07 March 2005 11:49  |
 Wolfgang Werner
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
For me under OS X there are two serious problems with the drag&drop
implementation that I do have to fix in a very short time frame. My
problem is that I do not have a long history in OS X native programming,
so any help is greatly appreciated.
I use the newest 3.1M5a milestone.
Task 1: The OS X DragSource implementation does query the data before
starting the drag and drop operation:
// Immediately get data for transfer. On other platforms, we wait
// until the data is requested, but on the mac, particularly in the case
of files,
// we need to know how many items are being transferred when registering.
// The only way to know this is to get the data.
int index = 0;
for (int i = 0; i < transferAgents.length; i++) {
int[] types = transferAgents[i].getTypeIds();
for (int j = 0; j < types.length; j++) {
TransferData transferData = new TransferData();
transferData.type = types[j];
event = new DNDEvent();
event.widget = this;
event.time = (int)System.currentTimeMillis();
event.dataType = transferData;
try {
notifyListeners(DND.DragSetData, event);
} catch (Throwable e) {
continue;
}
if (event.data == null) continue;
transferAgents[i].javaToNative(event.data, transferData);
if (transferData.result != OS.noErr || transferData.data == null)
continue;
for (int k = 0; k < transferData.data.length; k++) {
byte[] data = transferData.data[k];
OS.AddDragItemFlavor(theDrag[0], index++, types[j], data, data.length,
0);
}
}
}
My problem is, that I need to implement a drag and drop operation that
behaves differently in favor of the DropTarget: If it's an internal d&d, I
only need to call a function; if it's an external d&d, I need to export a
file - which takes some time - this overhead is only acceptable in the
case of the external d&d.
Would be great to get more insight - I would like to understand why this
has been implemented this way.
Task 2: In technical note TN1085 some issues with the Finder event
processing are described. The DragSource - Application is forced to do
some Finder Event Handling to make the d&d actually happen. Question: Waht
would be a good point to register / deregister the event handling routine?
Can this event handling be done in a central place (e.g. the main message
loop?) Is this event handling truely the cause of the problems - the TN is
very old and we are talking carbon here?
Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
second one enables an application to write a file on demand when asked and
provided with a filename by the DragTarget - Application. Is there any
chance that this filetransfer will be implemented?
|
|
|
| Re: OS X Drag&Drop to Finder / InDesign [message #451734 is a reply to message #451714] |
Mon, 07 March 2005 18:22  |
Veronika Irvine
Messages: 1272
Registered: July 2009 |
Senior Member |
|
|
> My problem is, that I need to implement a drag and drop operation that
> behaves differently in favor of the DropTarget: If it's an internal d&d, I
> only need to call a function; if it's an external d&d, I need to export a
> file - which takes some time - this overhead is only acceptable in the
> case of the external d&d.
I will have another look at passing null for the dataPtr in
AddDragItemFlavor. Please enter a bug report to track this.
> Task 2: In technical note TN1085 some issues with the Finder event
> processing are described. The DragSource - Application is forced to do
> some Finder Event Handling to make the d&d actually happen. Question: Waht
> would be a good point to register / deregister the event handling routine?
I would hack SWT and use the event registration that already exists (see
Display - there are many Callback objects for the different kinds of event
procs - e.g. appleEventCallback) and enter a bug report with a patch.
> Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
> second one enables an application to write a file on demand when asked and
> provided with a filename by the DragTarget - Application. Is there any
> chance that this filetransfer will be implemented?
The PromiseHFSFlavor "is used when you wish to create a new file when
dragging to the Finder". The idea of creating a new file versus moving or
copying an existing file is not supported by the FileTransfer object. More
API would probably be required to make this differentiation. I will look
into seeing if the DROP_TARGET_MOVE versus DROP_MOVE operations could be
used to accomodate this. Since I have not been able to interact with the
Finder correctly, I have not been providing capabilities that I can not
test.
"Wolfgang Werner" <wwerner@picturesafe.de> wrote in message
news:d0hf3e$9ht$1@www.eclipse.org...
> For me under OS X there are two serious problems with the drag&drop
> implementation that I do have to fix in a very short time frame. My
> problem is that I do not have a long history in OS X native programming,
> so any help is greatly appreciated.
>
> I use the newest 3.1M5a milestone.
>
> Task 1: The OS X DragSource implementation does query the data before
> starting the drag and drop operation:
>
> // Immediately get data for transfer. On other platforms, we wait
> // until the data is requested, but on the mac, particularly in the case
> of files,
> // we need to know how many items are being transferred when registering.
> // The only way to know this is to get the data.
> int index = 0;
> for (int i = 0; i < transferAgents.length; i++) {
> int[] types = transferAgents[i].getTypeIds();
> for (int j = 0; j < types.length; j++) {
> TransferData transferData = new TransferData();
> transferData.type = types[j];
> event = new DNDEvent();
> event.widget = this;
> event.time = (int)System.currentTimeMillis(); event.dataType =
> transferData; try {
> notifyListeners(DND.DragSetData, event);
> } catch (Throwable e) {
> continue;
> }
> if (event.data == null) continue;
> transferAgents[i].javaToNative(event.data, transferData);
> if (transferData.result != OS.noErr || transferData.data == null)
> continue; for (int k = 0; k < transferData.data.length; k++) {
> byte[] data = transferData.data[k];
> OS.AddDragItemFlavor(theDrag[0], index++, types[j], data, data.length,
> 0); } } }
>
> My problem is, that I need to implement a drag and drop operation that
> behaves differently in favor of the DropTarget: If it's an internal d&d, I
> only need to call a function; if it's an external d&d, I need to export a
> file - which takes some time - this overhead is only acceptable in the
> case of the external d&d.
>
> Would be great to get more insight - I would like to understand why this
> has been implemented this way.
>
> Task 2: In technical note TN1085 some issues with the Finder event
> processing are described. The DragSource - Application is forced to do
> some Finder Event Handling to make the d&d actually happen. Question: Waht
> would be a good point to register / deregister the event handling routine?
> Can this event handling be done in a central place (e.g. the main message
> loop?) Is this event handling truely the cause of the problems - the TN is
> very old and we are talking carbon here?
>
> Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
> second one enables an application to write a file on demand when asked and
> provided with a filename by the DragTarget - Application. Is there any
> chance that this filetransfer will be implemented?
|
|
|
| Re: OS X Drag&Drop to Finder / InDesign [message #451771 is a reply to message #451734] |
Tue, 08 March 2005 20:17 |
Veronika Irvine
Messages: 1272
Registered: July 2009 |
Senior Member |
|
|
I have changed DND on the Mac so that dragGetData is only called when the
specific data type is requested. No longer does it get all the data up
front. This will be in next week's integration build or tonight's nightly
build.
"Veronika Irvine" <veronika_irvine@oti.com> wrote in message
news:d0i64r$b8k$1@www.eclipse.org...
>> My problem is, that I need to implement a drag and drop operation that
>> behaves differently in favor of the DropTarget: If it's an internal d&d,
>> I only need to call a function; if it's an external d&d, I need to export
>> a file - which takes some time - this overhead is only acceptable in the
>> case of the external d&d.
>
> I will have another look at passing null for the dataPtr in
> AddDragItemFlavor. Please enter a bug report to track this.
>
>> Task 2: In technical note TN1085 some issues with the Finder event
>> processing are described. The DragSource - Application is forced to do
>> some Finder Event Handling to make the d&d actually happen. Question:
>> Waht would be a good point to register / deregister the event handling
>> routine?
>
> I would hack SWT and use the event registration that already exists (see
> Display - there are many Callback objects for the different kinds of event
> procs - e.g. appleEventCallback) and enter a bug report with a patch.
>
>> Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
>> second one enables an application to write a file on demand when asked
>> and provided with a filename by the DragTarget - Application. Is there
>> any chance that this filetransfer will be implemented?
>
> The PromiseHFSFlavor "is used when you wish to create a new file when
> dragging to the Finder". The idea of creating a new file versus moving or
> copying an existing file is not supported by the FileTransfer object.
> More API would probably be required to make this differentiation. I will
> look into seeing if the DROP_TARGET_MOVE versus DROP_MOVE operations could
> be used to accomodate this. Since I have not been able to interact with
> the Finder correctly, I have not been providing capabilities that I can
> not test.
>
>
> "Wolfgang Werner" <wwerner@picturesafe.de> wrote in message
> news:d0hf3e$9ht$1@www.eclipse.org...
>> For me under OS X there are two serious problems with the drag&drop
>> implementation that I do have to fix in a very short time frame. My
>> problem is that I do not have a long history in OS X native programming,
>> so any help is greatly appreciated.
>>
>> I use the newest 3.1M5a milestone.
>>
>> Task 1: The OS X DragSource implementation does query the data before
>> starting the drag and drop operation:
>>
>> // Immediately get data for transfer. On other platforms, we wait
>> // until the data is requested, but on the mac, particularly in the case
>> of files,
>> // we need to know how many items are being transferred when registering.
>> // The only way to know this is to get the data.
>> int index = 0;
>> for (int i = 0; i < transferAgents.length; i++) {
>> int[] types = transferAgents[i].getTypeIds();
>> for (int j = 0; j < types.length; j++) {
>> TransferData transferData = new TransferData();
>> transferData.type = types[j];
>> event = new DNDEvent();
>> event.widget = this;
>> event.time = (int)System.currentTimeMillis(); event.dataType =
>> transferData; try {
>> notifyListeners(DND.DragSetData, event);
>> } catch (Throwable e) {
>> continue;
>> }
>> if (event.data == null) continue;
>> transferAgents[i].javaToNative(event.data, transferData);
>> if (transferData.result != OS.noErr || transferData.data == null)
>> continue; for (int k = 0; k < transferData.data.length; k++) {
>> byte[] data = transferData.data[k];
>> OS.AddDragItemFlavor(theDrag[0], index++, types[j], data, data.length,
>> 0); } } }
>>
>> My problem is, that I need to implement a drag and drop operation that
>> behaves differently in favor of the DropTarget: If it's an internal d&d,
>> I only need to call a function; if it's an external d&d, I need to export
>> a file - which takes some time - this overhead is only acceptable in the
>> case of the external d&d.
>>
>> Would be great to get more insight - I would like to understand why this
>> has been implemented this way.
>>
>> Task 2: In technical note TN1085 some issues with the Finder event
>> processing are described. The DragSource - Application is forced to do
>> some Finder Event Handling to make the d&d actually happen. Question:
>> Waht would be a good point to register / deregister the event handling
>> routine? Can this event handling be done in a central place (e.g. the
>> main message loop?) Is this event handling truely the cause of the
>> problems - the TN is very old and we are talking carbon here?
>>
>> Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
>> second one enables an application to write a file on demand when asked
>> and provided with a filename by the DragTarget - Application. Is there
>> any chance that this filetransfer will be implemented?
>
>
|
|
|
| Re: OS X Drag&Drop to Finder / InDesign [message #451815 is a reply to message #451771] |
Wed, 09 March 2005 15:02 |
Wolfgang Werner
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Veronika, this helped us a lot! I just grapped your changes from cvs
(jndi-libs, OS.java,
Plattform.java, DragSource.java and gave it a try - works great, we now
have a great
responsiv UI in this area. I will now try to create the patch for the
Apple Events from
TN1085 starting in Display.java. Thanks!!
Veronika Irvine wrote:
> I have changed DND on the Mac so that dragGetData is only called when the
> specific data type is requested. No longer does it get all the data up
> front. This will be in next week's integration build or tonight's nightly
> build.
> "Veronika Irvine" <veronika_irvine@oti.com> wrote in message
> news:d0i64r$b8k$1@www.eclipse.org...
>>> My problem is, that I need to implement a drag and drop operation that
>>> behaves differently in favor of the DropTarget: If it's an internal d&d,
>>> I only need to call a function; if it's an external d&d, I need to export
>>> a file - which takes some time - this overhead is only acceptable in the
>>> case of the external d&d.
>>
>> I will have another look at passing null for the dataPtr in
>> AddDragItemFlavor. Please enter a bug report to track this.
>>
>>> Task 2: In technical note TN1085 some issues with the Finder event
>>> processing are described. The DragSource - Application is forced to do
>>> some Finder Event Handling to make the d&d actually happen. Question:
>>> Waht would be a good point to register / deregister the event handling
>>> routine?
>>
>> I would hack SWT and use the event registration that already exists (see
>> Display - there are many Callback objects for the different kinds of event
>> procs - e.g. appleEventCallback) and enter a bug report with a patch.
>>
>>> Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
>>> second one enables an application to write a file on demand when asked
>>> and provided with a filename by the DragTarget - Application. Is there
>>> any chance that this filetransfer will be implemented?
>>
>> The PromiseHFSFlavor "is used when you wish to create a new file when
>> dragging to the Finder". The idea of creating a new file versus moving or
>> copying an existing file is not supported by the FileTransfer object.
>> More API would probably be required to make this differentiation. I will
>> look into seeing if the DROP_TARGET_MOVE versus DROP_MOVE operations could
>> be used to accomodate this. Since I have not been able to interact with
>> the Finder correctly, I have not been providing capabilities that I can
>> not test.
>>
>>
>> "Wolfgang Werner" <wwerner@picturesafe.de> wrote in message
>> news:d0hf3e$9ht$1@www.eclipse.org...
>>> For me under OS X there are two serious problems with the drag&drop
>>> implementation that I do have to fix in a very short time frame. My
>>> problem is that I do not have a long history in OS X native programming,
>>> so any help is greatly appreciated.
>>>
>>> I use the newest 3.1M5a milestone.
>>>
>>> Task 1: The OS X DragSource implementation does query the data before
>>> starting the drag and drop operation:
>>>
>>> // Immediately get data for transfer. On other platforms, we wait
>>> // until the data is requested, but on the mac, particularly in the case
>>> of files,
>>> // we need to know how many items are being transferred when registering.
>>> // The only way to know this is to get the data.
>>> int index = 0;
>>> for (int i = 0; i < transferAgents.length; i++) {
>>> int[] types = transferAgents[i].getTypeIds();
>>> for (int j = 0; j < types.length; j++) {
>>> TransferData transferData = new TransferData();
>>> transferData.type = types[j];
>>> event = new DNDEvent();
>>> event.widget = this;
>>> event.time = (int)System.currentTimeMillis(); event.dataType =
>>> transferData; try {
>>> notifyListeners(DND.DragSetData, event);
>>> } catch (Throwable e) {
>>> continue;
>>> }
>>> if (event.data == null) continue;
>>> transferAgents[i].javaToNative(event.data, transferData);
>>> if (transferData.result != OS.noErr || transferData.data == null)
>>> continue; for (int k = 0; k < transferData.data.length; k++) {
>>> byte[] data = transferData.data[k];
>>> OS.AddDragItemFlavor(theDrag[0], index++, types[j], data, data.length,
>>> 0); } } }
>>>
>>> My problem is, that I need to implement a drag and drop operation that
>>> behaves differently in favor of the DropTarget: If it's an internal d&d,
>>> I only need to call a function; if it's an external d&d, I need to export
>>> a file - which takes some time - this overhead is only acceptable in the
>>> case of the external d&d.
>>>
>>> Would be great to get more insight - I would like to understand why this
>>> has been implemented this way.
>>>
>>> Task 2: In technical note TN1085 some issues with the Finder event
>>> processing are described. The DragSource - Application is forced to do
>>> some Finder Event Handling to make the d&d actually happen. Question:
>>> Waht would be a good point to register / deregister the event handling
>>> routine? Can this event handling be done in a central place (e.g. the
>>> main message loop?) Is this event handling truely the cause of the
>>> problems - the TN is very old and we are talking carbon here?
>>>
>>> Task 3: On OS X there are two FileTransfers : HFS and PromiseHFS. The
>>> second one enables an application to write a file on demand when asked
>>> and provided with a filename by the DragTarget - Application. Is there
>>> any chance that this filetransfer will be implemented?
>>
>>
|
|
|
| Re: OS X Drag&Drop to Finder / InDesign [message #451932 is a reply to message #451815] |
Fri, 11 March 2005 12:06 |
Wolfgang Werner
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Hi,
>> Task 2: In technical note TN1085 some issues with the Finder event
>> processing are described. The DragSource - Application is forced to do
>> some Finder Event Handling to make the d&d actually happen. Question:
>> What would be a good point to register / deregister the event handling
>> routine?
>
> I would hack SWT and use the event registration that already exists (see
> Display - there are many Callback objects for the different kinds of event
> procs - e.g. appleEventCallback) and enter a bug report with a patch.
I tried to do this - to keep it simple I started to change my main program
adding
a handler. Handler creation and registration works fine when using already
defined masks, however, when testing different values (guided by apple doc
and
N1085) the handler is not called at all.
[...]
Callback bogusFinderCallback;
int bogusFinderProc;
int bogusFinderProc (int nextHandler, int theEvent, int userData) {
log.info("inside Mac OS X bogus finder callback!");
return OS.noErr;
}
private void installBogusHandler() {
if (OS_IS_MACOS) {
log.info("Enable Mac OS X bogus finder callback... ");
bogusFinderCallback = new Callback(this, "bogusFinderProc", 3);
bogusFinderProc = bogusFinderCallback.getAddress();
if (bogusFinderProc == 0) {
log.error("ERROR - cannot enable Mac OS X bogus finder
callback!");
return;
}
final int kEventClassCWIN = ('c'<<24) + ('w'<<16) + ('i'<<8) +
'n';
final int kEventKindCWIN = 1; // ('*'<<24) + ('*'<<16) + ('*'<<8)
+ '*';
int [] mask = new int[] {
kEventClassCWIN, kEventKindCWIN,
};
int appTarget = OS.GetApplicationEventTarget ();
int result = OS.InstallEventHandler (appTarget, bogusFinderProc,
mask.length / 2, mask, 0, null);
if( result != OS.noErr ) {
log.error("ERROR - cannot install Mac OS X bogus finder event
handler! " + result);
}
}
}
Any idea how to set the mask values properly?
|
|
|
| Re: OS X Drag&Drop to Finder / InDesign [message #451985 is a reply to message #451932] |
Fri, 11 March 2005 22:06 |
Veronika Irvine
Messages: 1272
Registered: July 2009 |
Senior Member |
|
|
I gave this a few tries and have yet to achieve success. However, despite
the fact that I can't get my event handler to be called, I was able to drag
things from eclipse and into the Finder and vice versa. I found that the
Finder was a bit sluggish in response to key modifier changes (copy or link
rather than move) but I was able to copy, move and link files from Eclipse
into the Finder. Not sure if this is due to a fix to the Finder with one of
the latest OS X upgrades.
"Wolfgang Werner" <wwerner@picturesafe.de> wrote in message
news:d0s1jr$khc$1@www.eclipse.org...
> Hi,
>
>>> Task 2: In technical note TN1085 some issues with the Finder event
>>> processing are described. The DragSource - Application is forced to do
>>> some Finder Event Handling to make the d&d actually happen. Question:
>>> What would be a good point to register / deregister the event handling
>>> routine?
>>
>> I would hack SWT and use the event registration that already exists (see
>> Display - there are many Callback objects for the different kinds of
>> event procs - e.g. appleEventCallback) and enter a bug report with a
>> patch.
>
> I tried to do this - to keep it simple I started to change my main program
> adding
> a handler. Handler creation and registration works fine when using already
> defined masks, however, when testing different values (guided by apple doc
> and N1085) the handler is not called at all.
>
> [...]
> Callback bogusFinderCallback;
> int bogusFinderProc;
>
> int bogusFinderProc (int nextHandler, int theEvent, int userData) {
> log.info("inside Mac OS X bogus finder callback!");
> return OS.noErr;
> }
>
> private void installBogusHandler() {
> if (OS_IS_MACOS) {
> log.info("Enable Mac OS X bogus finder callback... ");
> bogusFinderCallback = new Callback(this, "bogusFinderProc", 3);
> bogusFinderProc = bogusFinderCallback.getAddress();
> if (bogusFinderProc == 0) {
> log.error("ERROR - cannot enable Mac OS X bogus finder
> callback!");
> return;
> }
>
> final int kEventClassCWIN = ('c'<<24) + ('w'<<16) + ('i'<<8) +
> 'n';
> final int kEventKindCWIN = 1; // ('*'<<24) + ('*'<<16) + ('*'<<8)
> + '*';
> int [] mask = new int[] {
> kEventClassCWIN, kEventKindCWIN,
> };
>
> int appTarget = OS.GetApplicationEventTarget ();
> int result = OS.InstallEventHandler (appTarget, bogusFinderProc,
> mask.length / 2, mask, 0, null);
>
> if( result != OS.noErr ) {
> log.error("ERROR - cannot install Mac OS X bogus finder event
> handler! " + result);
> }
> }
> }
>
> Any idea how to set the mask values properly?
>
>
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 07:52:34 GMT 2024
Powered by FUDForum. Page generated in 0.02343 seconds |
] 
Search
Help
Register
Login
Home
