Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 365381

Summary:	Remote tool launchers need more flexibility
Product:	[Tools] Linux Tools	Reporter:	Corey Ashford <cjashfor>
Component:	Project	Assignee:	Linux Distros Inbox <linux.distros-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	akurtakov, jjohnstn
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Bug Depends on:	364426, 364433
Bug Blocks:

Description Corey Ashford

2011-12-01 20:16:31 EST

Build Identifier: M20110909-1335


Here's what I think, ideally, what I want as a user to be able to do using a remote launch:

* The source location of an executable should be selectable via a file browser that allows selection a file using all of the methods supported by the Remote Proxy (e.g. RSE, Remote Tools, Local). This file browser should look very similar to the "Location" browser in the New->C/C++ project wizard, where you can select the filesystem, and the path of the file or directory.
* The destination location for the executable should be selectable in the same way, but this should be grayed out and the download checkbox turned off by default.

* The working directory should be selectable in the same way, but there should be a check to make sure that the same scheme and remote machine are used for the [destination] executable and the working directory.

* All of these settings should default to reasonable assumed locations when the user creates a new launch configuration, based on the executable he has chosen from a project.

Maybe the browser code is already available in the CDT as an independent widget? (I'll look into this possibility)  If not, perhaps there should be a new package which adds this browser (and possible other future remote UI widgets), something like org.linuxtools.profiling.launch.ui.  Maybe the new class could be named RemoteProxyFileBrowser, and instances would be constructed with an initial URI of current/default file location.  To be clear, this is an embeddable widget for a launch configuration tab, which can pop up a dialog to browse the remote filesystem, if desired by the user.


Reproducible: Always

Steps to Reproduce:
N/A

Comment 1 Corey Ashford

2011-12-02 15:20:22 EST

I found the code that allows specifying a remote project not in the CDT, but in the Eclipse core.  This is because any sort of project (not just C/C++ projects) can use non-local filesystems.

The code is in org.eclipse.ui.internal.ide.dialogs.ProjectContentsLocationArea which uses org.eclipse.ui.internal.ide.dialogs.FileSystemConfiguration.  This ProjectContentsLocationArea is not reusable, even if it were exported, which it isn't.

However, we could use it as a guide to create a new widget implementation.

Comment 2 Corey Ashford

2011-12-02 19:36:35 EST

(In reply to comment #1)
> However, we could use it as a guide to create a new widget implementation.

This isn't looking very good.  Ideally, I'd like to leverage off of the code that's already in Eclipse for obtaining a list of registered filesystems, and classes to access these filesystems.  However, I'm finding that nearly all of this code is in contained in internal packages (i.e. not exported).

After discovering this, I thought maybe that the best route would be to duplicate a subset of the code from org.eclipse.ui.internal.ide which implements the filesystem extension point.  That way we have access to the same exact data that Eclipse does.  The downside is that we would now have duplicated code in Eclipse, which would need to track its twin in the main Eclipse.

Anyone have a better idea about how to deal with this?

Comment 3 Corey Ashford

2011-12-02 21:30:44 EST

(In reply to comment #2)
> (In reply to comment #1)
> > However, we could use it as a guide to create a new widget implementation.
> 
> This isn't looking very good.  Ideally, I'd like to leverage off of the code
> that's already in Eclipse for obtaining a list of registered filesystems, and
> classes to access these filesystems.  However, I'm finding that nearly all of
> this code is in contained in internal packages (i.e. not exported).
> 
> After discovering this, I thought maybe that the best route would be to
> duplicate a subset of the code from org.eclipse.ui.internal.ide which
> implements the filesystem extension point.  That way we have access to the same
> exact data that Eclipse does.  The downside is that we would now have
> duplicated code in Eclipse, which would need to track its twin in the main
> Eclipse.
> 
> Anyone have a better idea about how to deal with this?

Well, I have a little good news.  While the packages we need are exported as "internal", we can still use them it turns out.  I get a yellow underline in the code editor telling me that access is discouraged, but I think we can live with that.

Comment 4 Andrew Overholt

2011-12-04 14:36:27 EST

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > However, we could use it as a guide to create a new widget implementation.
> >
> > This isn't looking very good.  Ideally, I'd like to leverage off of the code
> > that's already in Eclipse for obtaining a list of registered filesystems, and
> > classes to access these filesystems.  However, I'm finding that nearly all of
> > this code is in contained in internal packages (i.e. not exported).
> >
> > After discovering this, I thought maybe that the best route would be to
> > duplicate a subset of the code from org.eclipse.ui.internal.ide which
> > implements the filesystem extension point.  That way we have access to the
> same
> > exact data that Eclipse does.  The downside is that we would now have
> > duplicated code in Eclipse, which would need to track its twin in the main
> > Eclipse.
> >
> > Anyone have a better idea about how to deal with this?
> 
> Well, I have a little good news.  While the packages we need are exported as
> "internal", we can still use them it turns out.  I get a yellow underline in the
> code editor telling me that access is discouraged, but I think we can live with
> that.

We can petition the platform to make them API if you'd like.