Hi,
Let me try to response to a few questions/comments from the several email threads here.
First of all, we are on the same page wishing to have only one terminal view implementation and to bundle the resources willing to work on the terminal
view. Having multiple terminal views creates confusion, as we can see from many comments. However, what we are talking about here is basically the planning for a TM (Terminal) 4.0 release. There are cleanups to do, API’s to change in the o.e.tm.terminal plugin’s
etc. And it should be clear that all work towards a common terminal view, wherever it will live, should be done on base of the TCF Terminals view. The TCF Terminals view provides the most features the users asked for in the past, like the local terminal handling
and the integration of the terminal view in Eclipse (project explorer, short cuts, theme support, etc). Also, the TCF Terminal code is much more maintainable than everything we have in TM Terminal.
+1 to have a common, TCF Terminals view based, view implementation.
+0 to where it shall live. If you guys prefer to have the widget and the view living in the TM project, fine with me.
-
We should talk about some Releng improvements in this case than. I want to have TM Terminal releases done independent from RSE.
Doug’s comments:
>The real issue is when you open the Terminals View, there isn’t a connection defined yet. The users needs to be guided towards opening a connection. The lack
of tabs is
>much more obvious than in the TM terminal which more subtly says No Connection in pretty small text.
It should be pretty easy to understand for a user to click on the “Open Terminal” button either in the global toolbar or in the view toolbar. If you
say that it will be even better to have a text in the “Terminals” view once it is empty that explains how to open a new terminal, that’s pretty easy to implement.
>Also if we’re going to put multiple terminals into a view, then the tabs are a better way of doing that. But I do wish these tabs had the same behaviour as
View tabs. I’d like to
>be able to re-order them, and to easily pop them out of the View and into a new View either in the same page or into their own window. If you have multiple
monitors, it
>might be nice to be able to pop terminals into their own shell.
+1.
Would like to see all this too, but time and resources are limited.
There exist enhancement requests to allow the re-ordering of the tabs inside the view. Whoever feels comfortable with Eclipse DND is welcome to contribute.
Also if you have improvements to the DND handling of the tabs while moving around in the Eclipse shell, we would be happy to hear them and see contributions.
>One problem though is that the tabs have a different look and feel than the View and Editor tabs. Are you using CTabFolder to implement them? It would be
better if they >were consistent.
Yes, CTabFolder/CTabItem is what we use.
>And hopefully we can clean up the architecture along the way (it was double the work to add a connection type to TCF than it is to TM) since you still need
to deal with two >settings systems. It really only should be one.
I agree. The history of this is that we had the objective to keep the TM Terminal widget and connector implementations unchanged, but the view needs
to store different things and even needs to pass on custom transient data. With a TM Terminal widget 4.0, all this can be unified.
Greg’s comments:
>Looking at the TCF Terminals view implementation, I think it would be a lot of work to move it to TM as there are many TCF dependencies that you would need
to fix. If all you >wanted was the tabs, it would be much easier to add them to the existing TM Terminal view.
The existing, old, deprecated TM Terminal view is dead code. There is no value in trying to resurrect this view and trying to bring it to the level
of the TCF Terminals view. This would a waste of time and resources. This view is dead and as earlier we remove the code from the repository as better it will be to channel the limited resources to the right place.
>TM Terminal view uses one view per session and allows the view name and encoding to be changed.
The TCF Terminal view also supports changing the encoding.
>There are probably other features that TCF Terminals provides that I’m not aware of. If anyone knows what they are, please comment.
There is the local terminal support, there is the “pin & clone” support, there is the better integration into Eclipse if we talk about user visible
features. There is so much more in the implementation that a user does not see but is necessary for product builders.
>Looking at the TCF Terminals view implementation, I think it would be a lot of work to move it to TM as there are many TCF dependencies that you would need
to fix. If all you >wanted was the tabs, it would be much easier to add them to the existing TM Terminal view.
You over estimate the effort to get rid of dependencies and you under estimate the work which would be necessary to resurrect the deprecated TM Terminal
view implementation. I always said it is possible to have a TCF terminals view implementation without the dependencies to the other plug-in’s, but as long as there is no demand for this, it does not make sense to spend time on it. Cleaning up the dependencies
is less than a week work.
Let me repeat, resurrecting the deprecated TM Terminal view to implement all the features that the TCF Terminals view have … again … especially the
local terminal support … is not the way to go and it is not a wise use of resources. There is no reason to fear the dependencies of the TCF Terminals view implementation, the coupling is less heavy than you assume. If you want me to come up with a TCF Terminals
view implementation that can live in the TM project without referencing other TCF infrastructure plugins, let’s get the planning started and do it!
Best regards, Uwe
J
Hey gang, to get the conversation rolling towards technical solutions, I’d like to bring up the use of tabs as done by the TCF Terminal.
After a lot of though about it, I think I’m warming up to the idea. It does solve one problem well, but leads to others that I hope we can solve.
The real issue is when you open the Terminals View, there isn’t a connection defined yet. The users needs to be guided towards opening a connection. The lack
of tabs is much more obvious than in the TM terminal which more subtly says No Connection in pretty small text.
Also if we’re going to put multiple terminals into a view, then the tabs are a better way of doing that. But I do wish these tabs had the same behaviour as
View tabs. I’d like to be able to re-order them, and to easily pop them out of the View and into a new View either in the same page or into their own window. If you have multiple monitors, it might be nice to be able to pop terminals into their own shell.
Love to hear other’s opinions on the two views what the like or don’t like about each.
