Hi,
>Having tabs within tabs is problematic.
That might be your opinion. Our feedback from the users is different.
>The first thing I tried was to drag one of the terminals out of the View so I could have multiple visible at once. No dice. Not sure how it’s better.
You can drag terminals from one “Terminals” view to another. If you pin the original “Terminals” view, you’ll get a new “Terminals” view the next time you open
an new terminal. The terminals can now be dragged from one to the other.
>Having part in TCF and part in TM seems really messy
That’s why we are cleaning up things, do we?
And btw … I don’t care if we move the “Terminals” view to the o.e.tm project or if we move the widget to the o.e.tcf project.
>not to mention the ton of dependencies TCF terminal has on the rest of TCF as well as com.google.gson
Ever tried to install the TCF Terminal from the Eclipse marketplace as a user? I guess not, because the user will never notice the few dependencies we have. The
Eclipse P2 provisioning system is fully capable of dealing with those. Com.google.gson is available from Orbit and can be used in every project who wants to persist settings in JSON. And yes, the TCF project decided to do so. And the few other dependencies
to some of our core infrastructure plug-in’s … every project, including CDT and PTP, has dependencies to its own infrastructure plug-in’s, and there is nothing wrong with that. Why on earth do we need to implement everything tens of times just because we fear
some dependencies to some thin infrastructure plug-in’s? Nevermind.
@Greg: Not sure if you have updated the TM 3.7 drop in the meanwhile again. There had been another fix on the master branch before the Christmas vacations.
Best regards, Uwe
From: tm-dev-bounces@xxxxxxxxxxx [mailto:tm-dev-bounces@xxxxxxxxxxx]
On Behalf Of Doug Schaefer
Sent: Dienstag, 06. Jänner 2015 17:31
To: TM project developer discussions
Subject: Re: [tm-dev] Terminal (was Re: Master branch is TM 3.7?)
Agreed. I did some digging into the TCF Terminal code and it really is just a replacement for the View and some fancier UI for adjusting the settings. It seems
to use the VT100 widget unchanged. I also couldn’t see what was in the Local terminal (actually the Process terminal) that couldn’t be done with TM. Most of that functionality is what you’d put in the command shell service anyway.
And one can argue whether the TCF View has better UX than the TM one. Having tabs within tabs is problematic. The first thing I tried was to drag one of the terminals
out of the View so I could have multiple visible at once. No dice. Not sure how it’s better.
I think the best approach would be to bring the best from the TCF terminal and bring it into the TM terminal. And if we bring org.eclipse.remote and the LaunchBar
into TM as well, I think we’d have a pretty good target management system to serve both server-side and embedded.
I hooked up TCF terminal to the PTP TM terminal support that uses o.e.remote and it seems to work (launching a shell process rather than using getCommandShell).
Having part in TCF and part in TM seems really messy, not to mention the ton of dependencies TCF terminal has on the rest of TCF as well as com.google.gson. It
seems weird that all this is needed just to provide a terminal emulator which uses TM anyway.
I don’t understand the Local issue either, since there already is a org.eclipse.tm.terminal.local, which seems to work fine, or you could use the o.e.remote which
supports local connections. If the issue is the quality of the terminal emulation, then maybe we could just make this work with TM without having to bring in the whole of TCF?
Greg
From what I’ve seen the TCF terminal is built on top of the TM terminal. It seems TCF just replaces the View and has a different settings setup. I still need
to take a deeper look at why all this was necessary, especially for the Local terminal which apparently wasn’t possible with the TM terminal on it’s own.
On a related note, I’m about to try and hook up the TM terminal to the o.e.remote command shell service to see if it works. I have my Arduino C++ IDE using the
new o.e.remote-ized launchbar and will bring my serial port implementation over as the command shell. Interesting to see where it takes me.
BTW, you can see the o.e.remote-ized launch bar in the cdt/org.eclipse.launchbar git repo on the oeremote branch. Also in there is the current state of my thinking
for the o.e.remote 2.0 API. They’ll be released with the preview of the launchbar in Luna SR-2 next month. LaunchBar 2.0 will release with Remote 2.0 with Mars to complete the work. So the theory goes :).
I’ve been looking at TCF terminal and it seems that there is a dependency on org.eclipse.tm.terminal. I though it was supposed to be independent of TM? Can someone
clarify this?
Greg
Well, I can speak only for Terminal and the Terminal is definitely under active development. There might be just 2 active committers left, myself and Martin
Oberhuber from time to time, but we still do changes and we still need releases. I would be OK to move out the Terminal from the TM project but the proposed common project where things like the Terminal could live does not exist yet. I’m also fine with moving
the Terminal widget to the TCF project container, but that’s something Martin Oberhuber needs to decide.
For the Terminal, the main complains are not necessarily bugs at this point of time, the main complains are about the fact that you do have multiple Terminal
views in Eclipse once RSE is installed. 2 views are at least deprecated and only the “Terminals” view provided from the TCF project is maintained and where new features requested by the users are added. We have to get the 2 other Terminal views out of Eclipse
to stop the user confusion. The plan for doing this is outlined below, but this work does have some effect on EPP packages. I can do everything outlined below, but I don’t know how to get the EPP packages updated to include the correct features.
The cleanup of the multiple Terminal views should happen for the Mars release.
Regarding the committer meetings, at least for me time is limited and discussing things here instead of a shared conference call is easier to manage.
Thanks, Best regards, Uwe J
I’m not sure of the plans at this point. I’ve asked this list about the 3.6 version a couple of times but received no reply. I’ve also invited everyone to the PTP developers conference call to discuss plans, but
no one from TM ever attended. At this point, I’m assuming that the current release is the final release for TM.
I’m not a developer on the project, so I don’t know what anyone’s plans are unless they let me know. Also, developer’s will need to step up and update the project plan, documentation, and anything else that needs
to be done. I can fix the outline of the plan, but someone else will need to fill in the details. Finally, we need people to test the builds before they are released, or we can’t say we’re meeting Eclipse quality. This didn’t seem to be happening for the SR1
release.
Can you confirm that I’m right in assuming that the master branch is leading to the TM 3.7 release? When will it be released? I’ve checked the TM project pages
under eclipse.org/tm, but this pages are not up to date.
If master is leading to the 3.7 release, I would like to change at least the TM Terminal feature version numbers accordingly. Also I want to tackle a few Terminal
related releasing issues we keep pushing ahead of us for a long time now. Not sure if you need to announce them in some project lead meeting.
1. Deprecation
of unused or no longer supported features
a. Take
out the o.e.tm.terminal.view and the o.e.tm.terminal.local from the build and repositories
b. Move
the source of this features to terminal/deprecated folder to keep the source around for reference
c. Remove
the o.e.tm.terminal.core.sdk feature as without the terminal.view feature, the usual SDK feature is the same as the core.sdk feature
2. Work
on replacement for org.eclipse.rse.terminal feature
a. Remove
this feature from the org.eclipse.rse feature
b. Create
an replacement providing the same entry points from the RSE System Explorer as the org.eclipse.rse.terminal plug-in does but use the newer and maintained TCF Terminals view. The new RSE terminal feature will be provided by the TCF project like the TCF based
file system and process RSE contributions.
All effort is related to address the many complains about having up to 3 different terminals views available in Eclipse. Final goal is to bundle all terminal
related effort, bugfixing and feature development, into the superior TCF Terminals view.
_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev
_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev
|
