Community
Participate
Working Groups
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.
Yes, I think you're right. Doing a text search for "instanceof ISystemRegistry" gives 11 matches that potentially need to be changed into "instanceof ISystemRegistryUI" because the RegistryUI is now the input provider. I think that in the longer term, I'd like to move the ISystemViewInputProvider into non-UI but in order to do this, the getShell()/setShell(), getViewer()/setViewer() methods need to be removed from the ISystemViewInputProvider. In the shorter term, I guess we'll need to change the instanceof expressions as mentioned.
Created attachment 69541 [details] Patch fixing the issue Attached patch should fix the issue. I do not think that all occurrences of "instanceof ISystemRegistry" need to be changed, because events are typically fired with the ISystemRegistry as parent and NOT the ISystemRegistryUI. Due to the splitting, there is some confusion between the input provider and the event parent. Actually, some bugs might be buried here because of checks like if (inputProvider == event.getParent()) because since the SystemRegistryUI vs. SystemRegistry split, these are not necessarily the same any more. Therefore, I think the safest fix would be to get rid of the getShell() / getViewer() methods in ISystemViewInputProvider, and make the SystemRegistry the input provider again. Until this is done, please review the patch to fix the immediate issue.
With respect to getting rid of ISystemViewInputProvider.setShell() etc, I found this: // DY: Defect 44544, shell was not being set for Test dialogs, when they // tried to connect there was not shell for the password prompt // and an error message (expand failed) occured. inputProvider.setShell(getShell()); inputProvider.setViewer(this); // just in case. Added by Phil in V5.0 inputProvider.setShell(getShell()); // just in case. Added by Phil Dave's -- do you remember what this was for? If we cannot get rid fo the getShell() / getViewer() methods on the input provider, one option would be changing the signature to pass and return java.lang.Object such that the ISystemViewInputProvider can be moved to Core and SystemRegistry can implement it (rather than SystemRegistryUI). Which would, as I've mentioned before, be the safest fix for this category of potential problems.
Yeah, the split of the registries to ISystemRegistry and ISystemRegistryUI has caused a few regressions already. I approve the fix for the immediate issue.
I don't remember why these were used. I know historically there was a lot of code that wanted a Shell to be used for getting runnable contexts and such. I think this is problemmatic and it would be good to get rid of stuff like that if we can.
Patch committed, [190195] Cannot enable new connection prompt in system view Filed bug #190271 for tracking the move of ISystemViewInputProvider to Core.
[target cleanup] 2.0 RC2 was the original target milestone for this bug
