Community
Participate
Working Groups
Type String s = new String([ctrl-space]) The resulting window uses scrollbars eventhough there is more enough screen realestate for it to open up into. Scrollbars for popups like this should rarely ... if ever.
I agree on that. I don't think we can really get rid of scrollbars, but it would makes sense to have the size of the code assist window either configurable (urgh!) or have a heuristic that makes it bigger if it thinks that I can afford it (because I have a high screen resolution)
*** This bug has been marked as a duplicate of 12238 ***
I don't think this is a duplicate of bug 12238. That bug says we should be able to resize it. This one is saying that in most cases we shouldn't even have to resize it.
Is I agree it's not a duplicate. Was too fast when comment 1 about configurability.
Some thoughts about the size of the popup. The popup should adapt to the size of the width and height. The height should not exceede a certain size (Too large a window is also not a good thing.) The width should almost always entirly reflect the text in the window. (Horizontal scrolling is MUCH worse than vertical scrolling and should be avoided at all costs. There is a good explanation of the evils of horizontal scrollings in Alan Cooper's book, About Face 2.0) In that book he says: Scrolling text horizontally is a terrible thing, and should never, ever be done. When a text list is scrolled horizontally, it hides from view on or more of the first letters of every single line of text showing. This makes *none* of the lines readable and the continuity of the text is utterly destroyed. He then states the obvious axiom from the above paragraph. NEVER SCROLL TEXT HORIZONTALLY Along those lines, I noticed that this has a priority of P4, and IMHO, this is too low. Usabiliy issues, in many respects, are just as important as defects, and in many cases are more important. Considering that this window is used so often, I think this is one of those cases.
The reason for P4 is that we think once you can resize and the size will be kept you can configure it yourself. This will be quite easy to implement while the adding auto-sizing is quite difficult and time consuming to get it right on all platforms and displays. You might want to implement this and contribute to Eclipse.
> The reason for P4 is that we think once you can resize and the size will be kept you can configure it yourself. That is not currently the behavior. If I hit ctrl-space in the case described, and resize the window. Close the window and hit ctrl-space again. The window is not the size that I expanded it to.
The behavior described in this defect, as well as the resizing the window not being persisted is in version 2.1.1. Changed version to reflect this.
The resized size is not yet stored (see bug 12238, comment 5).
Moving to M8, as not yet done.
Not fixed in M8 but you can now resize it once and then it keeps that size.
Removing mile stone. Post 3.0.
