Community
Participate
Working Groups
Currently the core Common Navigator plugin is meant to be RCP client, but the LocalSelectionTransfer type is contained by the IDE layer, even though it has no dependencies to the IDE layer. A similar version should be available in the RCP layer.
Created attachment 34407 [details] A patch to add LocalSelectionTransfer to JFace
Reassigning to Nick to apply the patch as we discussed.
Boris or Eric, do you have any issues with this patch? It's essentially just a push-down of org.eclipse.ui.navigator.LocalSelectionTransfer.
Could the class be made final if there should be no subclassers? Also, the @since should be 3.2. Otherwise, the patch looks fine to me.
Looks good. Eric was wondering if we could reduce the number of copies even further. Although we can't delete org.eclipse.ui.views.navigator.LocalSelectionTransfer, since it's in an API package, I've made it extend the new org.eclipse.jface.util.LocalSelectionTransfer, thereby removing most of the duplicate implementation. In order to avoid clashes on the return types for the getInstance() static methods on both classes, I had to rename the one in JFace to getTransfer().
I've fixed up the @since. The new one can't be made final since org.eclipse.ui.views.navigator.LocalSelectionTransfer now extends it ;-). org.eclipse.ui.views.navigator.LocalSelectionTransfer can't be made final either since that would be a breaking API change. It's effectively final anyway because the only constructor is private.
Closing.
Nick, I think that the implementation you put into place avoids most of the 'patch' issues since we're effectively re-using what has already been a public API. That being said I'm still unclear as to what the timing related methods are there for.
Verified in I20060213-1200.
Since LocalSelectionTransfer is meant to be a singleton and both versions of LocalSelectionTransfer are effectively the same thing, couldn't the org.eclipse.ui.views.navigator.LocalSelectionTransfer have been made to delegate all its methods to the org.eclipse.jface.util.LocalSelectionTransfer instance? By doing this, whether you get your instance via LocalSelectionTransfer.getInstance() or LocalSelectionTransfer.getTransfer(), any method calls would effectively be going to the org.eclipse.jface.util.LocalSelectionTransfer instance. Otherwise because org.eclipse.ui.views.navigator.LocalSelectionTransfer is not deprecated (at least in the build i'm using it isn't), either instance could being used by dependency plugins which makes it difficult for the depender to determine which instance it should be using itself.
Interesting suggestion. With this change, it would be possible, e.g. to do a local selection transfer between the Resource Navigator and the new Common Navigator. Boris, would you be able to look into this?
> Boris, would you be able to look into this? For 3.2?
Ideally, yes, otherwise there will be incompatibilities between the two. Should also consider whether the same registration string should be used for the two (I think it should be the same). Should also deprecate LocalSelectionTransfer and change the ResourceNavigator to use the one in JFace.
Please see bug 137637 and bug 127029 . LocalSelectionTransfer is supposed to be a singleton but there is now two of them. We need to fix this for 3.2
Anthony, those bug refs don't add any new info. The first doesn't exist, and the second is a self-reference.
Lets try that again: I played around with drag and drop and raised bug 135971 which I think is the same issue. Bug 135637 is a GMF issue, I need to support the LocalSelectionTransfer singleton but there is now two of them. I think I should go ahead and use the JFace LocalSelectionTransfer.
Not sure if I will have the time to do this for RC2. Eric, Nick?
Hi again, just to confirm that we are going to do as described in comment 10 for RC2 / RC3 / next build. This is currently a big problem for GMF (my clients are complaining). GMF supports drop of LocalSelectionTransfer . If I use org.eclipse.ui.navigator.LocalSelectionTransfer then drop works from Navigator / Package Explorer but not from Project Explorer. If I use org.eclipse.jface.util.LocalSelectionTransfer then drop works from Project Explorer but not Navigator / Package Explorer . I tried but cannot hack my code to do both LocalSelectionTransfer (and should not have to anyway).
I'll have a look.
I have released a fix to org.eclipse.ui.views.navigator.LocalSelectionTransfer in HEAD, but I'm unable to test it adequately due to bug 137641. Anthony, can you try it out?
I was able to test it using a simple project (bug 137641 applies only to Java projects). The following now works: - show Navigator and Project Explorer views - create simple project with folders/files: P/ A/ Foo.txt B/ - drag Foo.txt from Project Explorer to B in Navigator - drag Foo.txt from Navigator to A in Project Explorer Anthony and Christian, I'd still appreciate it if you could verify this using the GMF scenarios.
The scenario related to bug 135637 works with your latest change Nick.
Thanks Christian. I've also verified in N20060426 using the scenario in comment 21.
