Community
Participate
Working Groups
When disconnecting from a connection the Remote System Details view should return to the connection list if a folder from that connection was being shown. Since Local doesn't require you to disconnect first before Deleting we also need to do the same thing for Delete. Currently nothing happens in the Remote System Details view. -----------Enter bugs above this line----------- TM 2.0RC3 Testing installation : eclipse-SDK-3.3RC4 RSE install : RSE 2.0 RC3 java.runtime : Sun 1.5.0_11-b03 os.name: : Windows XP, Service Pack 2 ------------------------------------------------
See also bug #193381 which is similar for the Scratchpad. Listening to the events should not be too much of an issue, can you come up with a patch?
*** Bug 193394 has been marked as a duplicate of this bug. ***
Same for folders deleted, see bug #193394. After deleting the folder that is shown in the Remote System Details view the contents of the view shows: "Folder PATH_TO_FOLDER is not readable. Cannot Expand". Instead the view should display the parents contents of the deleted folder or go back to the list of connections.
Martin, if I'm not mistaken there is no proper event that is fired when we do a disconnect. I believe it fires an EVENT_MUST_COLLAPSE. Thats why I had them separate. Though is EVENT_MUST_COLLAPSE used for anything else? Doesn't look like the table or scratchpad handle that event, so I guess it could be used.
SshConnectorService does fireCommunicationsEvent(CommunicationsEvent.BEFORE_DISCONNECT); Dave - would that be a good event to listen to for doing things like removing an item from the details view if it's disconnected?
Since it appears that all the services are firing this event, it's probably a good idea.
Actually, it appears FTP is not firing this event. FTPConnectorService should be firing the communications events as well.
Martin, to implement this we will need to make SystemTableViewPart implement ICommunicationsListener which would be an API change, so we should assign this to Future?
oops nevermind Martin. Was thinking SystemTableView, but SystemTableViewPart is internal so we can make API changes to it.
Are you sure that SystemTableViewPart needs to implement ICommunicationsListener itself? I think that in its constructor, it could also create an anonymous nested class that's the communications listener: bla.addCommunicationsListener(new ICommunicationsListener() { public void onCommunicationsEven() { doWhatYouNeedToDoInTableViewPart(); } });
We could do something like that as well. I was just looking at how the SystemResourceChangeListener and SystemRemoteChangeListener were done. registry.addSystemResourceChangeListener(this); registry.addSystemRemoteChangeListener(this); Just to be consistent shouldn't it be done the same way?
Not necessarily. I'm personally often more in favor of keeping listeners in small anonymous classes -- this makes it more evident what's going on. If your class just implements ISystemCommunicationsListener, finding those methods that actually get called in case of a communications event are much harder to find than if you have a local anonymous class. Having the TableViewPart implement ISystemCommunicationsListener makes sense if we think that being a communicationsListener is a property of the TableViewPart, and anybody can send it communications events regardless of whether it registered as listener or not. If we think this is the case, it MUST implement the interface; otherwise, it CAN implement the interface and it boils down to a personal matter of preference. I'll leave it up to you what you prefer -- but don't argue just with "it should look like it is now for consistency". What we have now is not necessarily the best implementation. My personal preference is the local anonymous class, do it according to your personal preference.
Thanks Martin. I wasn't trying to argue for one way over the other. I was just wondering if we were trying to be consistent in all case's, but I understand the way things are implemented is not always the best.
Changed summary as deleting of folder shown in table, displaying an error is fixed in bug #193394.
I just came across this with RSE 3.0 Create a new dstore connection, connect and browse into it. Activate the Remote Systems Details View -- it shows "Local" and "New_Dstore". In RSE Tree, disconnect then delete the dstore connection. --> Deleting is EXTREMELY slow, and when done the tableview still shows the stale "New_DStore" connection.
