| Re: [cdt-dev] Targets in the LaunchBar |
|
Just to take a step back in this thread, I just tried to install the target explorer feature in Luna into my environment. I notice that it pulls in TCF Debug. Is there a feature
I should be using that doesn't pull in TCF, or is the target explorer tied to TCF?
Thanks,
Doug.
From: Stieber, Uwe [Uwe.Stieber@xxxxxxxxxxxxx]
Sent: Saturday, July 05, 2014 3:58 AM To: Doug Schaefer; CDT General developers list. Subject: RE: [cdt-dev] Targets in the LaunchBar Well, the slides left out the Target Explorer as lightweight evolution of RSE. That’s a shame.
Just my 2 cents.
Best regards, Uwe J
From: Doug Schaefer [mailto:dschaefer@xxxxxxx]
David Cummings over here reminded me of Greg's talk at EclipseCon which covers the problem nicely. It would be even nicer if we could come up with a good solution that unified the user experience for dealing with remote systems.
Doug
From:
cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Doug Schaefer [dschaefer@xxxxxxx] Cool. Actually, I'd use the word "duplicates" rather than "aligns" but it's good to see we're headed in the same direction. My plan is to have the launchbar in the C/C++ Package in Luna SR-1/CDT 8.5. It'll be weird to have two drop downs for targets so that'll have to be figured out.
I had thoughts of using the Target Explorer as a common navigator. We really need to unify the UX around targets. Having each system show their own UI elements looks really goofy when a user has to deal with multiple of them, and at least adds to the inconsistency we have in the "tragedy of commons" state we're in.
Certainly something we should look into. Thanks! Doug
From:
cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Oberhuber, Martin [Martin.Oberhuber@xxxxxxxxxxxxx] Hi Doug, Greg –
You might consider using the TCF Target Explorer as a generic container / API to unify the various target management systems that CDT / PTP may want to support.
We recently added a toolbar dropdown to TCF Target Explorer, for creating new target connections, choosing a “current target connection”, connecting and performing operations. This is what it looks like when you install “TCF Target Explorer” from Luna Simrel into the Luna C/C++ Package – it seems nicely aligned with the toolbar you have in mind:
Right now, the only type of connections supported in Open Source are TCF connections. But we’ve already extended this for our commercial product to provide different connection types. Since target explorer is very generic and agnostic, it should be possible to implement a bridge for RSE type of connections, or JSch type of connections for PTP.
We don’t currently have support for matching the architecture of targets against the architecture of projects. But any target connection (“peer” in terms of TCF/TE) has generic attributes. Using the IPropertiesAccessService, these are easily obtained.
In terms of the code, TCF/TE follows a modern service-oriented architecture. Here is some sample code to obtain the currently selected default connection, and then query some properties like IP Address and port. Note how – thanks to the service architecture – different service implementations are possible for a “UI Driven Eclipse” versus a different configuration that might get the IDefaultContextService from a non-UI application.
1. Use the IDefaultContextService to get the currently active connection.
IDefaultContextService svc = ServiceManager.getInstance().getService(IDefaultContextService.class); IPeerNode ctx = svc.getDefaultContext(null);
2. Use the IPropertiesAccessService to get the IP address and port of the currently active connection.
IPropertiesAccessService service = ServiceManager.getInstance().getService(newLocatorNode.getPeer(), IPropertiesAccessService.class); Map<String,String> attrs = service.getTargetAddress(newLocatorNode.getPeer()); String peerHost = attrs.get(IPropertiesAccessServiceConstants.PROP_ADDRESS); String peerPort = attrs.get(IPropertiesAccessServiceConstants.PROP_PORT);
Similar Services and constants exist for FileTransfer and Terminals service – see here for the generic (non-TCF) services: And here for some basic core TCF services which I referenced above:
As you see, the dropdown and locator (target address) API’s are currently in the non-agnostic i.e. TCF-specific part. We could potentially consider pushing down some of this into the agnostic (non-TCF) part if you are interested.
HTH, let us know what you think.
Thanks, Martin -- Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Doug Schaefer
Cool. Thanks Greg. That's another great example we need to make sure works.
Right now, the middle selector assumes one launch configuration per entry. That means only one launch configuration type. Remote launches tend to have their own launch configuration types. This means the user would have to create additional launch configurations manually and select those types.
But the UX I want to achieve for CDT-based projects is that there's one launch configuration entry per executable project. And it needs to be able to handle all the types of remote launches and the local launch.
I'm not sure how to get there. We could make the middle selector map to more than one launch configuration and the correct one that runs is based on the active target. That messes up the API pretty bad and we have a lot of assumptions around that it's a one-to-one mapping.
Doug.
From:
cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Greg Watson [g.watson@xxxxxxxxxxxx] Doug,
PTP has it’s own target management system, so it would be nice to use this with the new LaunchBar. It would be difficult to do this if CDT provided a target system that everyone had to use.
We could also provide a remote launch target in the remote services plugins (org.eclipse.remote.*) which multiplex across different remote implementations (RSE and JSch). That way there would need to be one remote launcher.
Regards, Greg
On Jul 2, 2014, at 1:00 PM, Doug Schaefer <DSchaefer@xxxxxxx> wrote:
Hey gang, I'm struggling with how to model targets in the LaunchBar. (As a reminder of what the LaunchBar looks like, see here: http://cdtdoug.ca/wp-content/uploads/2014/03/Screen-Shot-2014-03-14-at-10.08.11-AM.png)
By default, there is a target called Local Machine. There's no semantics to that target, and it really means do whatever the launch configuration naturally does, which more often than not is to launch the application on the local machine.
For Momentics, targets are the QNX-y things we launch on. We have our own target management system which predates everything you see at Eclipse, so we've stuck with it. We have a target registry that maintains the list of targets and we produce that for the LaunchBar. But I don't think it would be wise to force everyone to use our target management system.
As I have it now in the CDT, targets are very simple things that only have an id and a name. The launch config descriptors provide a list of valid targets they can launch on. The default launch config descriptor simply returns an object for the local machine. The idea is that the descriptors know what it means to launch on a target so they can deal with changes in active target and feeding it to the launch delegates however they like. So it can be whatever target system makes sense.
The problem is what do we do with the CDT itself. We've never really modelled launching on targets. We do have the remote launch that uses the RSE. But there's no semantics that link it to a project. This could be done by adding a nature to the project to enable remote launches. Or it could be done by marking toolchains as cross toolchains so we can figure out what targets their build artifacts can run on. We have the cross toolchain, but it's woefully inadequate for this since it doesn't keep track of the real target platforms (os, arch).
Has anyone given this any thought or is everyone happy using their own target management system? How would we use TCF in place of RSE? Or do we want to go through the effort to support remote launching in the CDT proper at all?
Look forward to your thoughts, Doug. _______________________________________________
|
