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 ?
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 ?
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.
