Community
Participate
Working Groups
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
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.
(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?
(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.
(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.
