[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.tools.gef] Re: Need meta key info
Randy Hudson wrote:
Well a Link would imply dropped instances to be linked. Thats what I am looking to imply, though linking means not necessarily what you specified in the context of my application.

Because their is the idea of 'linking' and my app uses 'linking' I want to stay consistent with the method the user would normally use when dropping something and trying to create a link.

I say the COPY set there. But the listener seems to be completely aware that the only action would be copy. So I fear the change will be more complicated.


I'm sure linking makes sense in your application. But why linking templates? Can't you use some other transfer and your own drop listener? What are you actually linking?


Yes, I can make one from scratch. I guess I didn't see the line between GEF library and the logic examples maybe.

When you drop a template, it will repsenent a component. Either a new component, or an existing component. If its an existing component, then its 'linked' to the other instance of that existing component.

What I am trying to do is allow different drop behaviors. Best way is to use existing methodologies like LINK, COPY, MOVE. These are already interpreted and understood on each platform. So I like to use these deciphered behaviors, as opposed to simply saying, "is CTRL down?" since this could mean different things to users of different OSes.

The main issue is how can I handle the meta keys on drop. With the current transfer, I can not because all meta keys info is blocked, since the drop action is always copy.

I would prefer that if someone tried to do a link, or move, but all the targeted accepted was COPY, the attempted link or move would fail. But as it stands, when you try to link or move, you get feedback indicating your attempted operation is acceptable. But upon ecexution you dont get what you thought you were getting, instead you get COPY. Don't seem right. But thats a 2nd issue really.

This is because my old implementation used the awt dnd system, and I was able to specify what I accepted and what I did not. Probably I still can if I write my own DropTargetListener.



I see. I guess I had used the awt system before and was used to it. Now I gotta get a feel for this swt one which is slightly different. Like when dropActionChanged() is called, how do I get an indication of what it was changed to? in the awt system, there is an event object passed into this method and you can tell from that. But here there is no way to know, nor reject the new action if you dont want it, AFAICT!?


Our "handle" methods are similar to the way we designed our tool implementation. You can access the last event by calling getXxxEvent(), and then look at the detail to see what the new type is.

The handle methods are slightly higher-level, and involve sending requests to target editparts. The "raw" receiving method is more low-level and does things such as resetting the timer for interpreting a mouse hover.


problem with this seems to be how to indicate that the current operation is not acceptable?



CL