Checkbox label punctuation behaving strangely

  • I have a checkbox in my app with a label like this:

    Width: [ ]

    Compiled on my debian wheezy, it displays correctly, but if I compile it on debian squeeze, it looks like this:

    :Width [ ]

    and if I shift that same binary back onto wheezy from squeeze, it again looks like the first version above. So something in the environment outside the app is causing this misplacement of the colon. I have no idea at all where to look, and cannot find anything about this anywhere in the docs. Whatever "clever" translation is happening, is there any way to turn it off completely and treat the colon like any other text character?

    Thanks in advance!

  • Curious... the checkbox always appears to the left of its label on my machine.

    This looks like a system locale issue. Is one machine set to a locale that normally processes text right to left? Have you done anything in your code with respect to right-to-left layout?

  • Thanks Chris. The layout of that widget is set rtl to make the box appear on the right, but it is rtl on both machines. But the reason for the comma is to 'point' to the box, so it should be on the right no matter what the locale, which is why I want to turn off smarts and make it treat the label text as all text, and stop being clever. Is that possible? Cheers.

  • Which Qt versions are on your two boxes?
    In the layoutDirection docs, it says:

    bq. This method no longer affects text layout direction since Qt 4.7.

    Which might have something to do with your case (text layout direction changes, too).

  • Both say they are 4.6.3, and the same binary behaves differently on the two machines, so the locale stuff must be dynamically compiled in. I've worked around it bu taking the text out of the checkbox and making it a LTR label located before a checkbox with no text of its own. Thanks for the quote, but it triggers one of my pet peeves about documentation. The writers think they are telling you how something works, but the fact is there are whole vast layers of things going on that they somehow imagine we must know about (but in fact we don't). In this case where does it say that at runtime the characters of a text string are individually examined and rearranged based on locale? I've studied the docs for hours and I can't find even the remotest clue to that behaviour anywhere. I don't think computing has quite got to the engineering stage yet - still partly a work of art! Cheers.

  • You are the one trying to subvert the purpose of RTL layout in order to obtain a cosmetic result in a LTR environment. If you use a RTL layout with RTL text the systems works as expected. The behaviour of text in a bidirectional environment is not governed by Qt, it's part of the Unicode standard and covers thing like special markers for embedded LTR ot RTL text amongst text of the opposite natural flow. See "Unicode Technical Annex #9": as referenced from "Internationalization with Qt": page in the Qt docs.

    If you want a non-standard checkbox in which the label is left of the check there are documented methods for painting the widget yourself.

  • Except that it works differently on two machines that are both set to the identical locale. That's not expected. Translating the text into Arabic, yes, maybe picking up colons and shifting them would be intuitive. But the text is English and stays English. Where does it say that individual characters will be searched for and moved, on some machines but not others in identical locales? After all, if I write English right to left (which is what you say I have claimed to do) then presumably I have already put the colon on the wrong end, and want it left there? There is nothing in the Qt docs that indicate that this flag serves any other purpose than to switch the positions of text and checkbox. The entire flavour of the docs is precisely that unicode will take care of itself in Qt. No one said one had to study unicode technical annexes to discover strange behaviour of the colon character. And from what DerManu tells us above, it seems Qt now agree.

Log in to reply