Control label positions

[FourthWorld]

The positions of the label of controls (mostly buttons, but in each of their various forms, including push buttons, tab menus, and others) do not conform with the HIG recommendations for either OS X or Windows. They're close, but off by just a pixel or two.

Will addressing this be part of the Themes task, or would it be worthwhile for someone to go into the current code and fine-tune those?

[Klaus]

Yes, and for my pet feature request http://quality.runrev.com/show_bug.cgi?id=3265
I would really like to see this implemented.

It cannot be THAT difficult, if you leave the icon, the text position is already PERFECT (textalgin = centered)

This is ideal for localisations to put he Label directly and exactly on top of the icon!
Fiddling with the MARGINS is NO option and to messy, right now we need to create
images (text on icon) for each language!

[monte]

@Klaus This is a different issue to @FourthWorld's and I think could only be resolved by adding a textVAlign property to override the default quirky label positioning when you have an icon. A pet annoyance of mine is the behavior when left and right aligning having the icon aligning opposite rather than with the text.

@FourthWorld is there an open bug report? By the looks of the code in buttondraw.cpp it will need to specify exactly which versions of which platforms and how many pixels in which direction

I'm not sure how much the drawing code is meant to change so perhaps @rurenvmark could comment on that.

Is there an issue with backwards compatibility here if people have use workarounds like margins to get it right?

[FourthWorld]

@FourthWorld is there an open bug report? By the looks of the code in buttondraw.cpp it will need to specify exactly which versions of which platforms and how many pixels in which direction

A reasonable suggestion - perhaps once Mark chimes in on how relevant this is in light of the themes work I could make a table of adjustments that need to be made. Of course if the new themes are able to pick up their metrics from the OS the problem goes away.

There's a bug report for part of this here, and there may be at least one other but I couldn't turn it up this morning:
http://quality.runrev.com/show_bug.cgi?id=3841

Is there an issue with backwards compatibility here if people have use workarounds like margins to get it right?

Good question. This is one of the few areas where I'd consider workarounds a form of enabling bugs, and therefore worth fixing in scripters' code as much as in the engine. Others may feel differently, but I hesitate to suggest introducing yet another global property to govern this (the brokenControlFontMetrics <g>).

[malte]

A pet annoyance of mine is the behavior when left and right aligning having the icon aligning opposite rather than with the text.

I share that pet annoyance.

Well, I have written a PITA workaround using margins. But as this is needed application wide it

a) is a method in a library which could easiely replaced
b) it would be well worth the time to refactor my own code if it would just work as one might expect
c) if we want to move forward and things are clearly documented (This is essential though) and is implemented early in a dp cycle, scripters have enough time to react.

But that is just me, mileage might differ.

[monte]

@FourthWorld I like the brokenControlFontMetrics syntax ... oops... last time I joked about syntax we got 'this me'

@malte I think that one at least and @Klaus's issue can be resolved in a backwards compatible way with new properties for textVAlign and label H and V align.
- unset - current quirky icon/label alignment
- top
- center
- bottom