All features are upreved to 4.3 along with the Parent POM for the
upcoming Terminal 4.3 / Oxygen release. Plugin versions remain
unchanged, keeping them as semantic versions. Along the lines, also
- Introduce a Maven Profile -Pcdtserial, which is active by default
to build the cdtserial plug-ins. This can be de-activated by property
-Dnocdtserial on the mvn command-line. This is necessary to build /
validate Terminal against older streams (juno,mars,...,neon) which
did not have the necessary cdt native serial dependency.
- Update the update site to
http://download.eclipse.org/tm/terminal/updates/4.3
- Update Copyright Year in all features to 2017
- Update p2 repo URLs of Oxygen and Orbit dependencies.
- Update the terminals.psf project-set file adding the new cdtserial.
Change-Id: I8992fe4bb8ac08abe783d33fbb8b00b4e864fd73
Signed-off-by: Martin Oberhuber <martin.oberhuber@windriver.com>
A few short cuts taken but it's usable. There's no memento for this
connector since it's usually not a good idea to always connect to the
serial port on startup since there can only be one client at a time.
Change-Id: If8ea1c770597068346bb44a6444a6d231d38bca9
Signed-off-by: Doug Schaefer <dschaefer@blackberry.com>
The Terminal used to "re-use" icons from org.eclipse.ui.console -
this did not work any more when that plugin changed .gif icons
to .png for better HiDPI support. Copying icons into the terminal
view plugin resolves the problem for all Eclipse versions.
Collect the list of connection types that support the command shell
service and pass that to the RemoteConnectionWidget so that you can
select which one you want.
Also adds a fix to the connection manager that was closing the
terminal of read returned 0 bytes. That's generally not an end of
file condition, especially with Serial Ports. There ugliness to them
where you can't close the port while it's blocked on the read, which
means it needs to return once in a while.
Fix setting of title and force new to match the other delegates.
Change-Id: I6b78d789ca28284379d8f1136062ec180e1a8f5c
Signed-off-by: Doug Schaefer <dschaefer@blackberry.com>
Added the menu contributions to
popup:org.eclipse.jdt.ui.PackageExplorer?before=group.edit additionally
to the ProjectExplorer contributions.
Change-Id: I1438057d82389c332c3678a3568bf0706497b49f
Signed-off-by: Dirk Fauth <dirk.fauth@googlemail.com>
There are two versions of RSEInitJob.waitForCompletion:
waitForCompletion()
waitForCompletion(int phase)
The waitForCompletion() version ensures that the job has been scheduled
before waiting for it, but not the waitForCompletion(int phase)
version. Therefore, if the waitForCompletion(int phase) version is
called first, the calling thread can end up waiting for the completion
of a job that has never been started.
I got in this situation by disabling the auto-start of the RSE UI plugin
(in Window, Preferences, General, Startup and Shutdown). Trying to
create a remote launch in CDT calls waitForCompletion(int phase),
therefore freezing the entire Eclipse. When the auto-start of the RSE
UI plugin is enabled, the waitForCompletion() version is called during
the initialization of that plugin, so the problem did not appear.
The suggested fix is simple, just move the code that ensures the job has
been scheduled from waitForCompletion() to waitForCompletion(int phase),
so that the job can be scheduled by both versions (since the former is
implemented by calling the later).
Change-Id: I9f6e5f948c3dbf1be60ddf04af5adbdfcaf3a7eb
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Added auto-detection of Git installations on Windows
Change-Id: I42702126ffb550dd8b289a45ee552d5095a1a615
Signed-off-by: Dirk Fauth <dirk.fauth@googlemail.com>
Added external executables to the terminal combobox on the Open Terminal
Dialog (Ctrl+Alt+Shift+T)
Change-Id: Ia9d9a3959fd95b666c4a1ad4474b519103297920
Signed-off-by: Dirk Fauth <dirk.fauth@googlemail.com>
Moved the code and all related configurations regarding showin from
o.e.tm.terminal.connector.local to o.e.tm.terminal.view.ui
Change-Id: If548ae729173c6127f7cf918aa2f783cd6cb3961
Signed-off-by: Dirk Fauth <dirk.fauth@googlemail.com>
Introduced an ISourceProvider to check if external executables are
configured. Renamed the Terminal context menu "Show In" to "Show in
Local Terminal". Extended the visibleWhen check so that the "Show in
Local Terminal" menu is only visible in the context menu if an external
executable is configured. Otherwise it is possible to open the Terminal
via the inclusion of the command in the default "Show In" menu.
Change-Id: I618b2352a8973d6591cf9e673dc4eb01aeec072e
Signed-off-by: Dirk Fauth <dirk.fauth@googlemail.com>
When TM Terminal sees this:
ESC [ 5 n
It replies indicating that the terminal is OK:
ESC [ 0 n
This escape sequence is documented here:
8.3.35 DSR - DEVICE STATUS REPORT. Page 40.
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf
Motivation: I'd like to switch winpty from using DSR(6) to DSR(5) as its
ESC flushing command. When winpty sees a bare ESC, it can either
synthesize a VK_ESCAPE keypress or wait to see if the ESC was part of some
other escape sequence. It tries to deal with this by generating a DSR(6),
which should flush out the remaining bytes of the sequence, if there are
any. DSR(6) is suboptimal, though, because the reply collides with the
sequence some terminals use for F3 with a modifier:
ESC [ nn ; nn R
DSR(5) generates a DSR(0) reply, which does not have the same problem.
DSR(5) is supported by all the terminal emulators I tested, including
xterm, rxvt, rxvt-unicode, gnome-terminal, konsole, putty, mintty,
OS X's Terminal.app, and IntelliJ/jediterm.
Signed-off-by: Ryan Prichard <ryan.prichard@gmail.com>
