Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #190195 +++ We've seen some regressions due to splitting SystemRegistry vs. SystemRegistryUI. Particularly, some views compare event.getParent() against their input provider -- which is bound to fail due to the split. The problem could be fixed by moving ISystemViewInputProvider to Core, and making SystemRegistry implement it. What's making this problematic is the getViewer() / getShell() methods on the ISystemViewInputProvider. A quick fix could be done by changing their signature to get and pass java.lang.Object, but in the longer term these should be removed. For details, see bug #190195 comment 2 and bug #190195 comment 5. Build ID: Eclipse3.3 RSE2.0rc1 Steps To Reproduce: 1. enable the "show new connection in system view" preference 2. the new connection prompt will not get visible in the system view More information: to me it looks like the UI/NonUI splitting of the system registry caused this problem. in get/hasChildren of SystemViewRootInputAdapter the new conenction prompt is only added when the provider is a ISystemRegistry. in fact, when debugging this code, the provider that is used is always a ISystemRegistryUI. changing this interface to ISystemRegistryUI re-enables the new connection prompt.
Created attachment 70182 [details] Patch moving ISystemViewInputProvider to Core Please review attached patch. It's a sizeable patch but rather simple: * Change signature of set/getViewer/Shell() to "Object" * Move it to Core * Have ISystemRegistry implement it rather than ISystemRegistryUI * Change the corresponding instanceof expressions Although it's late for such a sizeable patch, I expect RSE to be more reliable with it because the original assumption of SystemRegistry and the InputProvider being the same is restored.
Dave can you please review this ASAP? - I'd like to see it in RC2 if possible.
I'm not sure I understand why the signature for getShell() is being changed to return an Object. Could you explain that? Is that what we want in the end or are we just changing the signature to get around something?
We need to move it to Core so that ISystemRegistry can implement it. In Core, we do not know Shell or Viewer. So, the signature is changed to Object for now. All methods that have the "workaround" Object signature are deprecated so they should be removed eventually.
Dave do you think it's safe to commit this?
I didn't see the "workaround" Object signature. Are you planning on adding that? Anyway this looks safe for now.
The signature change is hard to see in the diffs, because the file was moved. It used to be setShell(Shell shell) setViewer(Viewer viewer) but now it is setShell(Object shell) setViewer(Object viewer) The corresponding getters are also changed (return value). The getters are deprecated, since I'd like to encourage clients to use other methods for getting the viewer or shell. Anyways, thanks for the review, this is the last change I'm accepting for RC2 so I can kick it off now.
Patch committed, changing org.eclipse.rse.core org.eclipse.rse.subsystems.files.core org.eclipse.rse.ui [190271][api][breaking] Move ISystemViewInputProvider to Core Migration Docs: --------------- Organize Imports. If there are compile errors on setShell() getShell(), setViewer() getViewer(), get rid of those methods since they are deprecated.
I saw the signature changes... I was just thinking there was supposed to be "workaround" keyword or something for the changed signatures.
[target cleanup] 2.0 RC2 was the original target milestone for this bug
