Bugzilla – Full Text Bug Listing
| Summary: | Splash screen build # does not line up | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kevin McGuire <Kevin_McGuire> | ||||||
| Component: | UI | Assignee: | Kevin McGuire <Kevin_McGuire> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | bokowski, remy.suen | ||||||
| Version: | 3.5 | ||||||||
| Target Milestone: | 3.5 M7 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Kevin McGuire
Fix released to HEAD.
The old implementation was a bit curious as it provided a start location for the build ID string. However, that string is right justified, so as the build id string changes length it would again not line up.
I changed the code in the EclipseSplashHandler to check the string extent and now interpret the org.eclipse.sdk/plugin.xml property value buildIdLocation as the right justification location (it was the build id string start draw location).
This changes the meaning of buildIdLocation but I don't see any documentation or API aspect to this, in fact the code in EclipseSplashHandler says,
// find the specified location. Not currently API
// hardcoded to be sensible with our current Europa Graphic
@Boris let me know if you see a problem with this.
If we revert to the interpretation of buildIdLocation to be the string start location, then we should use the values:
<property
name="buildIdLocation"
value="285,190">
</property>
So much for being clever, on Vista I get a build id printed in some odd location (far left). Possibly the text extent is bogus on Vista but should probably just revert this to the better hard coded value. Hmmm, it's not vista, I think it's graphics card DPI setting. (In reply to comment #1) > This changes the meaning of buildIdLocation but I don't see any documentation > or API aspect to this, in fact the code in EclipseSplashHandler says, Would it be safer to introduce a new (non-API) property with a different name? We could honor the old property if available but use the new property (with right-justfied semantics) ourselves. (In reply to comment #4) > Would it be safer to introduce a new (non-API) property with a different name? > We could honor the old property if available but use the new property (with > right-justfied semantics) ourselves. Isn't ignoring a property a kind of breakage too? Those who were relying on the old property to do something would find it no longer did. Since I don't know how people might be depending on the current property I'm finding it hard to guess the effect of change. In the future we should see if there's a different approach: trying to right justify drawn text with a static graphic seems problematic given differences in fonts, platforms, etc., and of course change in graphic. I suppose then it'd be worth introducing a new property. Going with left justify and no change to meaning of property. Released to HEAD Created attachment 133606 [details] Screenshot depicting the problem in question. (In reply to comment #6) > Going with left justify and no change to meaning of property. > Released to HEAD This is still broken on Linux/gtk+ with I20090428-0100 or did I misunderstand the fix in some way? I'm getting the wrong behaviour on XP too. Created attachment 133609 [details]
same problem on the Mac.
Looks like the change to org.eclipse.sdk/plugin.xml 1.53 didn't go into the build (not tagged and not in the drop source). Boris, this is in the sdk project which I don't think we load with the platform-ui module. Was there something special I was supposed to do to get it into the build? It's part of feature.map. If you were able to commit to org.eclipse.sdk the you should be able to tag and update the map file as well. Change in build Verified in in 0429-0800 |