|
Hi Doug,
What you describe sounds like your various connection types are configured elsewhere (outside the Terminal), so in the context of the Terminal View, no “new wizard UI” would be necessary
at all. “Something” creates a Terminal as part of a Launch, and you can interact through it (or close it) but not reconfigure it.
I think that the Terminal already supports this as-is. We’re using this mode of operation for TCF, and I think to some extent it’s the same for the o.e.tm.terminal.remote for PTP/Remote
kind of connections. I don’t quite see what kind of duplication you see here – the Terminal is only used for displaying an existing Stream of data in this case.
Does that help you in any way, or am I missing a point ?
I’m not sure that’s what I was trying to say. If you try and create a new Remote Terminal with my latest change request and a number of different remote connection types installed, you’re presented with a pretty similar list as the terminal type list.
In fact all of the Terminal types that are in the base TM project are also implemented as remote connections. And, in fact, a number of the remote connection command shell services are clones of the core terminal connectors.
I was just wondering if it made sense to remove the duplication and have the core terminal types just use the IRemoteConnection equivalents so we only have one code base to maintain going forward.
Regarding RXTX, I’m reluctant obsoleting it in favor of the new CDT Serial. We have seen many subtle issues with various USB/Serial adapters over the years and I’d hate seeing any regression
in products. This serial stuff seems to be highly timing dependent (and hardware dependent), making it hard or impossible to get any good test coverage. RXTX isn’t perfect either, and I’d love to be proven wrong by lots of successful adopters of CDT Serial
… but until that happens, I’m afraid we need to at least support RXTX in parallel. Do you have any data regarding the quality / hardware support matrix of the new CDT Serial ?
It’s all POSIX and Windows, so not really. CDT Serial is being used by all Arduino C++ boards and my experience is that a huge number of them are used in practice. I’ve never had bugs raised about timing issues.
And yes, we can support them in parallel for those who are able to actually find RXTX out on the internets and are happy with it’s license. This is more an issue of consolidation with o.e.remote I mention above.
Anyway, all this can wait until Oxygen. For now, I just want to make sure the Remote Terminal actually works. :)
Doug.
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind
River
direct +43.662.457915.85 fax +43.662.457915.6
I have experimented with opening command shells in the Console view using the Terminal control. It works OK, but it really overloads the Console View. We’re already moving towards removing the Debug Console into it’s own view to help alleviate
the problem. At the end of the day, the Console is good for showing messages, but not good as a View where user input is also required.
What I’d like to do instead is come back to the Terminal View and do some work on it to bring it forward. I see a couple of issues that will need some work and would like your thoughts.
First, we represent the Remote Terminal as a single terminal launch delegate. And, in fact, it only has support for the SSH connection type. I have been adding new connection types for different types of Serial connections and would like
them supported as well. My thinking is that each connection type that has a command shell service should have it’s own delegate. There’s lots of code they could share since it’s a common API, but have them listed separately with their new wizard content available
for each.
This also brings up another point. There is obviously a lot of duplication between the terminal types and the remote connection types. Do you think it makes sense to consolidate them? I don’t see why they have to be different.
In particular, the Serial terminal uses rxtx still. CDT now has serial port support and the org.eclipse.remote Serial connection type is using it. It doesn’t make that much sense to duplicate it in the terminal plug-in.
|
