Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #204796 +++ As per bug 204796, the Terminal Encoding can be specified programmatically or by RSE. We should add a UI Control for also setting the Encoding of the Terminal Widget when running stand-alone. Two options are possible: (a) The Encoding could be set in the connection properties dialog, but not associated with a specific Connector - similar to the "View Name" property. (b) Or, it could be associated with a Terminal View but not a specific connection (see also bug 205390). I'm more in favor of option (a).
Is there any progress about this bug If not , I can work on the bug.
Thanks Ahmet, your help would be most appreciated!
Created attachment 184599 [details] UI control for setting the encoding. I implemented option (a) .Can you check my patch?
I tested this for inclusion in 3.3m6, but it's lacking a couple essential criteria: - MUST be persistent across sessions. Example: Make an SSH UTF-8 connection. Quit Eclipse and restart. Reconnecting the connection, it is ISO-8859-1. Expected: Should be UTF-8 again after restart. - MUST give access to all possible encodings. On my Win7, it only gives me 5 options to choose from. The combo must be writable similar to the Resource Properties, to provide access for encodings such as Shift-JIS. - SHOULD display the active encoding in the Terminal view, where the other connection settings are visible. Encoding is important, it should be made visible. - SHOULD allow changing the encoding without disconnect/reconnect of the session. Similar to how the Temrinal's name can be changed via Properties while connected. - COSMETIC choose "Serial" terminal connector, the settings dialog is quite tall. Switch to telnet or ssh, it remains tall with much empty space between telnet settings and encoding dropdown. The dialog should resize. I really wanted to release this into the milestone, but with issues 1 and 2 above I'm afraid that people would get very frustrated and we'd set wrong expectations. Note that as a workaround you can use the RSE Terminals subsystem which supports encodings. Also note that we use the host Platform's default encoding in the TM Terminal today, which you also have some influence on through Java Properties (ie we assume the remote host encoding to be the same as the local encoding). I'll be happy to review another improved patch (shouldn't take so long this time). Please add an EPL Legal notice with your patch according to http://eclipse.org/tm/development/committer_howto.php#external_contrib Thanks!
Created attachment 191676 [details] proposed patch Hi Martin, I have attached the patch that provides this criteria.Can you check it ?
I've had a quick review of the new patch: - The new dependency from o.e.tm.terminal.view onto o.e.ui.ide is not acceptable. The terminal.view is made to have minimal dependencies, and it must run in an RCP style program without core.resources. org.eclipse.ui.ide requires core.resources -- adding that dependency is not acceptable. - I don't understand the change made in VT100TerminalControl. What's wrong with setting a default encoding? - The VT100TerminalControl may be used by other clients (eg RSE terminals) and I can't see why behavior is being changed?
- The dependency is essential.I have defined the encodings in combo like RSE Terminals subsystem. "IDEEncoding.getIDEEncodings()". If the dependency is not acceptable ,how can we define the encodings in combo? - The Encoding set with null in VT100TerminalControl's constructor. Because setEncoding is called nowhere . // Use Default Encoding as start, until setEncoding() is called setEncoding(null); As start the encoding set with selected encoding in this patch.
(In reply to comment #7) > - The dependency is essential.I have defined the encodings IMO there is no need to pre-fill the encodings combo... getIDEEncodings() gives you a list of encodings used somewhere in Preferences or Workspace. The encoding used by your remote terminal may be completely different. I think it should be sufficient for the combo to: 1. Be editable and allow entering any custom encoding 2. Remember any encoding previously entered in that combo 3. Add the current host Platform's default encoding (known to Terminal) 4. Add the most common standard encodings "UTF-8" and "iso-8859-1" If you want to walk an extra step you could try to read the Preferences store yourself to get more encodigns previously used... but IMO there's not much value in doing so since it's a convenience only anyways. Again, we cannot accept a dependency into IDE at this point .. I would be tempted to allow an optional dependency, but due to bug 247099 that's also not adviseable. > - The Encoding set with null in VT100TerminalControl's constructor. > Because setEncoding is called nowhere . > As start the encoding set with selected encoding in this patch. Your patch will set the encoding only when tm.terminal.view plugin is used. But there's many adopters who use the tm.terminal plugin without the view. In that case your patch will not be active, so you can't change the behavior of tm.terminal .
Created attachment 205582 [details] new Patch I've added a new patch. Properties: -The combo was done editable. And it allows entering any custom encoding.But , if it entered the unacceptable encoding, it throws UnsupportedEncodingException. -It saves any encoding previously entered in that combo. -I added the default encoding from Terminal.And I didn't any changes org.eclipse.tm.terminal.Only, org.eclipse.tm.terminal.view. -I added the most common standard encodings("UTF-8" ,"iso-8859-1"). Thanks!
The new patch looks pretty good already - I like it ! Thanks for addressing the dependency issue, that was the major blocker so far. - The main issue I found with the current patch was, that it didn't save the selected encoding for me... neither the "active" encoding was saved nor any additional non-default encodings. Testcase: In Eclipse 4.1, Connect with ISO-8859-1; then while connected, switch to shift-jis; quit and restart eclipse; reconnect; connects as ISO-8859-1, SHOULD connect as shift-jis. See also comment #4: MUST be persistent across sessions. The other issues were a bit more cosmetic: - The extra encoding group in the settings dialog is too large. Suggestion: Put the "encoding" combo into the "View Settings", then it's a single line. - Re-using the externalized String "Encoding:" for both the label in the dialog and the display in the view is not clean. Suggestion: For the display in the view, externalize the parentheses too, since different kinds of parentheses may apply in different languages. - The file copyright comments didn't all include your name. - The encoding dropdown should also offer the current hosts's default encoding (see VT100TerminalControl#defaultEncoding for how to get it) - I didn't test how older connections from an old workspace are migrated (expectation: Since terminal only did ISO-8859-1 in the past, they should all be migrated to an ISO-8859-1 setting Finally, such that I can apply your patch please add a comment here on bugzilla indicting that you have the right to contribute this - see here for a template: http://eclipse.org/tm/development/committer_howto.php#external_contrib Thanks again! We're getting close...
I have a question about fifth issue in other issues. Terminal did ISO-8859-1 in the past .According to the issue, when the view setting's dialog is opened, the dropdown offer the host's encoding. I think, the encoding dropdown should offer the VT100TerminalControl' encoding.
(In reply to comment #11) Hi Ahmet, I agree that the dialog should show the current VT100TerminalControl' encoding as the selected one. I expect that when migrating an old workspace, that will always be ISO-8859-1. The host encoding should be available in the list of encodings to choose, but not necessarily be the selected one. Does that answer your question ?
Created attachment 208766 [details] default encoding and other Thanks for your guidance and valuable helps. I wrote the code and have the right to contribute. Ahmet Alptekin (Tubitak) - [244405] Add a UI Control for setting the Terminal's encoding
Comment on attachment 208766 [details] default encoding and other So... I finally got to reviewing this, and after fixing 2 more defects I was able to commit: - TerminalSettingsDlg: Charset.defaultCharset().displayName() is a J2SE-1.5 API which we cannot use in the Terminals's J2SE-1.4 Execution Environment, so I replaced it with a different way obtaining the default charset. - TerminalView#onTerminalConnect(), added a setEncoding() since otherwise after re-launching a preexisting workspace and just connecting, the correct encoding would have been displayed in the title bar but the wrong encoding would have connected. There are two more cosmetic issues that would be nice to fix, I'm going to file separate bugs for these ... would be great if you could have a look at those. Many thanks for this contribution !
released for 3.4m5.
Follow-up Bugs: bug 370225 - enhancement: Encoding combo should offer previous settings as choice bug 370226 - bug: On Eclipse 4.2m5, the view's Summary line appears in Status Please have a look, thanks!
