Bugzilla – Full Text Bug Listing
| Summary: | [terminal] The optional terminal input line should be resizeable | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] Target Management | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||||||
| Component: | Terminal | Assignee: | Michael Scharf <eclipse> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Martin Oberhuber <mober.at+eclipse> | ||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | mober.at+eclipse, wb-rel, wbprio | ||||||||
| Version: | 2.0 | ||||||||||
| Target Milestone: | 3.0 M6 | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 220969, 220971 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Martin Oberhuber
You can enter very long text now, it will scroll vertically. Why would you want a multi-line text input for a single line input? In IM clients, you can often use ctrl-Enter to create newlines within the text. This does not make sense here. Therefore I lowered the priority. When configuring bootloaders (e.g. U-Boot), the single line command tends to be very long and is copied&pasted from somewhere. It's much more user-friendly to be able and see all of the input line rather than having to scroll. If you work in an xterm for instance, the input line is also wrapped to the next line when reaching the right border of the terminal so you see the entire contents of the line. I'm not talking about embedding newlines here (agree that Ctrl+Enter does not make sense), but just about making a long line of 80+ characters visible to the user. Bulk update target milestone 2.0.1 -> 3.0 There is a small problem: When using multi line input, then cursor up/down should navigate in the input field. Therefore Ctrl-Up and Ctrl-Down (or something else more or less intuitive) has to be used to navigate the history. Instead of making the field resizable, we could add a little icon to open a big input field for multi line text (like the rind river search). The advantage is: the user would not have to mess around with the size of the input field (it will always be to big (taking to much space) or to small (not enough space to input a long line)).... With this solution the key binding for history navigation would not have to change.... What do you think? I'd prefer a resizeable input line like in AIM clients (Trillian, ...) We are talking about an interactive application here, i.e. repeated input/output behavior. I think it's likely that after one long input line multiple other long input lines could be needed. Having to walk to an extra dialog for each long line would break the workflow, whereas I'd consider pulling a handle to enlarge the input line very intuitive. Also consider the case where a long input line is buggy the first try so you want to try several times (using the history). Opening / closing the "long line dialog" would not be user-friendly. Ctrl+Cursor up/down walks the history in GAIM. We could assist the user finding the history by putting little "history" buttons to the right of the input line, with a tooltip reading Ctrl+up -- similar to what the RSE Command View is doing. Targeting M5 so we can backport to 2.0.3 in time. Created attachment 89609 [details]
A patch to fix the problem
Here is a patch that fixes the problem. However there are a few limitations:
- the terminal does not remember the position of the sash
- after a font change the input field is not resized
- I did not change the action on the up/down arrow key. I think navigaing in the history is much more common than navigating in a long command line. I wanted to use ctrl up/down to navigate in the wrapped line, but I did not figure out how to do that
- not (yet) tested on linux
Comment on attachment 89609 [details]
A patch to fix the problem
This patch has problems when starting eclipse with open terminal views....
Created attachment 89637 [details]
A better patch but not perfect
this patch does not crash but the position of the input filed is wrong when eclipse starts with an open terminal
Bulk reassign missed M5 tasks to M6 I think SashForm is not the right solution, because it knows only about relative positions. Ideally, the input should not resize when the terminal view resizes. Maybe using a Sash directly could be the solution and adding a selection listener that does the magic..... I spend some more hours on this bug using Sash directly to resize the field. I could not come up with solution that works on windows and gtk. I tried to adopt http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet107.java but I was not able to change it so that the lower pane does not get resized when the container size changes. Then I did some experiments with GridLaout and a selection listener on the Sash. It works to somehow, but it has some redraw problems (there are some parts not updated). Maybe I will try it on another day with a fresh mind..... Created attachment 90823 [details]
A patch for a better resizable input field
This patch essentially works but it sometimes has some redrawing problems.
Thanks for the patch - knowing how much work it was to come up with, It's cool that it's not too much of code :-) Unfortunately, I cannot apply the patch to my workspace to test it, due to conflicts in CommandInputFieldWithHistory. Could you update to HEAD and resubmit? Just reviewing the patch, I'm wondering whether this is really necessary: // make sure the input filed hight is a multiple of the line height Looking at my AIM client miranda, for instance, I see that resizing the window does resize the input line also to heights that are not a multiple of the line height. It may happen in this case that some unused white area remains in the input line, but that doesn't hurt. It's basically a similar situation to what we've had with the Terminal widget itself. For the resizing, I was wondering whether it could help to use a SashForm, but for the InputLine use a GridData constructed with grabExcessVerticalSpace==false. Then, I'd think that when resizing the whole view, the Terminal Widget above the Sash should grab excess space but the Input Line below should be unmodified. I did not try this idea out, though... I did a merge with head and the patch is against head. I wonder what went wrong. > Just reviewing the patch, I'm wondering whether this is really necessary: > // make sure the input filed hight is a multiple of the line height this is not the cause of the update problems.... One could use fSash = new Sash(parent,SWT.HORIZONTAL|SWT.SMOOTH); then the dodded line would not be shown but there are still some (but less) update problems. > For the resizing, I was wondering whether it could help to use a SashForm, but for the InputLine > use a GridData constructed with grabExcessVerticalSpace==false. SashForm uses its own Layout (SashFormLayout) and SashForm.setLayout() does nothing. And therefore setting GridData for any of its children has no effect. (SashForm ignores any LayoutData) Ok, I found the problem: Trying to apply the patch from the Clipboard failed, but first saving the patch to a file and then applying it from the file worked. The reason seems to be that in line 12->13 of CommandInputFieldWithHistory, a CR-Only line ending was in the original file - I have no idea why. I filed bug 220821 against Platform/Compare for that issue. Thanks for your explanations regarding the Layout, Sash and Form. I hope we can find the reason for the display update issues. Ok so I tried the patch, and the one problem that I have with it is that I have no chance navigating up and down in a multi-line input field with the keyboard. Neither Ctrl+up/down nor plain up/down works. I did not see any display update problems on Windows. Since this seems technically the right way to go, it's the beginning of a Milestone period, there was a merge problem, and the observed behavior is not worse than the previous behavior (i.e. no problems at all as long the user doesn't try resizing the field) -- I'm all in favor of committing this patch to CVS. We can then close this bug and make a new low-priority one for any remaining display update issues (on Linux-GTK, you were saying?) Ah OK, when resizing the input field to make it smaller, the grey bar that's used as the handle when dragging is not repainted in the Terminal Widget. Workaround: type anything in the Terminal widget to force it redraw the last line. (In reply to comment #17) > Ok so I tried the patch, and the one problem that I have with it is that I have > no chance navigating up and down in a multi-line input field with the keyboard. > Neither Ctrl+up/down nor plain up/down works. We have to make a decision here: 1: we map the UP/DOWN key to navigate inside the input line(s) and use Ctl-Up/Down to navigate in the history. I am sure many users will simply miss the fact that Ctrl-UP/Down moves in the history. (Ok we could add a field tip). 2. we use UP/DOWN to navigate the history and Ctrl-UP/DOWN to navigate inside the field (I tried this but I could not find a solution how to do this) 3. use UP/DOWN for both (navigate inside the line and a down at the bottom gos to the next line and a up at the top goes to the previous line) 4. keep is as it is.... solution 1 should be relatively simple to implement, although I see some problems to add the message to the field tip..... Here's my favorite:
(1) up/down to navigate the inputline
ctrl+up/down to navigate the history
add some indication telling people how to navigate the history
- could be tooltip or an extra control/icon for showing the history
Given that there is Ctrl+Space field assist now, navigating the history is probably slightly less important. We also have the little lightbulb indicator for field assist. Could the text hover for that lightbulb be customized to say "use Ctrl+up/down to access the history"?
What about little up/down buttons right to the scroll buttons for navigating the history with the mouse? Text hover over it could indicate that Ctrl+up/down can also be used for navigating the history.
Checked in the current patch for Michael. Will create new defects for the redrawing problem as well as the cursor navigation / history problem. Created bug 220969 for the keyboard navigation in the input line, and bug 220971 for the redraw issues. |