Bugzilla – Full Text Bug Listing
| Summary: | TVT3.1 #67 - Status line contributions not resizable | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | David W Hare <dwhare> | ||||||
| Component: | Text | Assignee: | Platform-Text-Inbox <platform-text-inbox> | ||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | camle, daniel_megert, douglas.pollock | ||||||
| Version: | 3.1 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
David W Hare
Created attachment 18898 [details]
English Screensoht
Created attachment 18899 [details]
Hungarian Screenshot
The area you are referring to is the status area in the Eclipse IDE and is not part of VE. If you open just the Java Editor you will probably get the same problem. Please reroute this bug to correct Eclipse product and component (I think JDT/UI but not sure). moved and reopening... Don't know if this is editor or Platform/UI. Moving to Editor first. The text editor's simply add contribution items to the status line manager which would have to offer resizing in this scenario. I'm not sure why this particular problem would require these items to be resizable. I would expect that the code contributing the widgets would choose an appropriate width for the widgets based on the text they contain. Dani: Can you point me to the section of code that contributes these items? >I would expect that the code contributing the widgets would choose >an appropriate width for the widgets based on the text they contain. We initially do but the string in there ('Writeable' vs. 'Read-Only') is NLSed and then it no longer fits. Of course we could compute the size up-front using the given (NLSed) strings but this might result in a long status line field, eventually hiding (or reducing) other fields since we have no clue how long the field will be in the end in a given language. >Dani: Can you point me to the section of code that contributes these items? References to StatusLineContributionItem(String, boolean, int). (In reply to comment #8) > >I would expect that the code contributing the widgets would choose > >an appropriate width for the widgets based on the text they contain. > We initially do but the string in there ('Writeable' vs. 'Read-Only') is NLSed > and then it no longer fits. Of course we could compute the size up-front using > the given (NLSed) strings but this might result in a long status line field, > eventually hiding (or reducing) other fields since we have no clue how long > the field will be in the end in a given language. This argument could be made about any GUI layout. I'm not sure what makes the status line contributions different. I feel that it is generally a bad idea to provide resizable status line items. I'm hard pressed to think of prior art for this kind of thing. It seems the user would be much happier if we just got the size right -- especially since the status items we're talking about are not interactive/editable. Moving back to Platform/Text so that they can get the size right. > >Dani: Can you point me to the section of code that contributes these items? > References to StatusLineContributionItem(String, boolean, int). I meant which plug-in. But looking at it a bit closer, it seems that Platform/Text is using their own StatusLineContributionItem -- and hence create their own widgets. If you wanted resizable items, then wouldn't you be able to do it with your own code? >This argument could be made about any GUI layout. I'm not sure what makes the >status line contributions different. Exactly what's in this bug: most other UI elements (e.g. workbench window, preference dialog, wizards,...) can be resized to "fix" that. >If you wanted resizable items, then wouldn't you be able to do it with your own >code? Mmmh, yes we create the fields/cildren which are then registered with / managed by Platform UI's status line. How would I implement the resizing? But, If feel that these text elements are really labels. They shouldn't really resize at all. My recommendation would be to choose an minimum size sufficient to fit translations. "Smart Insert" in particular, has no space left for translations that might make it longer. Alternatively, you could resize the label if it is too small to accomodate the text. You could implement user-controlled resizing by creating a drag handle, and resizing the label in response to some user event on the drag handle. > My recommendation would be to choose an minimum size sufficient to fit
> translations.
We don't know what language translations will be / are available.
There are no plans to just provide this for some status line items.
|