Bug 165680

Summary:	"Show in Remote Shell View" does not work
Product:	[Tools] Target Management	Reporter:	Martin Oberhuber <mober.at+eclipse>
Component:	RSE	Assignee:	David McKnight <dmcknigh>
Status:	RESOLVED FIXED	QA Contact:	Martin Oberhuber <mober.at+eclipse>
Severity:	minor
Priority:	P3
Version:	1.0
Target Milestone:	2.0.1
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Martin Oberhuber

2006-11-23 11:41:18 EST

Create two different connections to different hosts.
Below each conneciton, open a shell.
In the Remote Shell View, select the tab for the shell of connection A.
In the RSE Tree, select the shell of connection B and choose 
  Contextmenu > Show in Remote Shell View

The Remote Shell View gets activated, but the tab that belongs to the selected connection is not selected.

-----------Enter bugs above this line-----------
RSE 1.0 Release Test
installation : eclipse-platform-I20061121-1845
RSE install  : update-site RSE M20061123-0700 core,ssh,dstore
java.runtime : Sun 1.5.0_08-b03
os.name:     : Windows XP 5.1, Service Pack 1
------------------------------------------------
systemtype   : Ssh-solaris, Dstore-solaris
targetos     : Solaris 5.9
targetuname  : szg-anar
targetvm     : Sun Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode)
------------------------------------------------

Comment 1 David McKnight

2007-06-29 10:17:28 EDT

Originally there was code that changed the tab selection on updateOutput() but the problem with that is that if multiple shells were receiving output, the tab selection would switch in an annoying way.  To solve this, I've added a separate API showPageFor(IRemoteCommandShell) that gets called by the action.

Comment 2 Martin Oberhuber

2007-06-29 11:20:53 EDT

I first stumbled over "added API" which we cannot do in 2.0.1 -- but fortunately, the change is in org.eclopse.rse.internal.shells.ui.view which we can change.

Thanks!

Comment 3 David McKnight

2007-06-29 11:42:24 EDT

BTW, regarding API, if a class is public, is it possible to "add" API (as opposed to remove or change API) provided that the use of the API is not required by consumers of the code?

Comment 4 Martin Oberhuber

2007-06-29 12:03:25 EDT

If the public class is not "internal" I do not want to add public or protected methods to it, because I'd like to remain backward API compatible with 2.0.1.

Otherwise, extenders could rely on the new public method and use it because they are developing against 2.0.1 -- but if somebody tried running the resulting code against 2.0 it would fail.

Does this answer your question? - We can also discuss this in the committer meeting.

Comment 5 David McKnight

2007-06-29 12:20:49 EDT

Yup, I just wanted to make sure I was clear on that policy.