Qtbugs
محتويات
QT bugs list
This is a list of bugs present in latest QT. These are mainly Arabic/RTL related bugs, but not only. There's no specific order.
The exchanges on this topic can be found in May 2004 'developer' archives (issue N49191). The issue N16335 cited below can be found in February 2003 'developer' archives. Please refer to the threads there in order to get more details.
RTL bugs
- After a call to QApplication::setReverseLayout(true), the QLine``Edit and QText``Edit children objects have a default LTR alignment and the developer has to change the alignment to RTL by hand. The expected behaviour is to have the alignment of any newly created QLine``Edit/QText``Edit objects to RTL by default after a call to QApplication::setReverseLayout(true).
- Almost the same as the point above. The editor of a QSpin``Box is aligned LTR by default, even after a call to QApplication::setReverseLayout(true). The developer has to:
- Create a derived class (the editor is a protected variable...).
- Set the alignment by hand.
This is not the expected behaviour.
- The text (Arabic or English) of a QCombo``Box is not aligned on the right in RTL mode (after a call to QApplication::setReverseLayout(true)), and in that case there isn't even a way to do that by hand. The same goes for QTable __cells__ alignment.
- In RTL mode (after a call to QApplication::setReverseLayout(true)), the status bar messages are not shown, wether they are written in English or Arabic characters. In LTR the status bar messages are shown fine in any character set.
- QTable has a mirroring bug: columns are not shown properly. This bug was signalled more than a year ago (issue N16335) and we were told that this is a known problem (due to QScroll``View) and that its resolution won't happen in the next few releases. However, since then there have been a good deal of releases and that was not fixed yet. Using tables in RTL mode is simply almost useless if this bug persists.
- QList``View``(s) are not mirrored properly. Is this related somehow to the point above ?
- When using the QT Arabic translation, the OK button text is displayed in English. We checked that the 'ts' (translation) file contains indeed the proper translation for that button. The texts of other buttons (Apply, Cancel, Defaults) are displayed in Arabic correctly.
- The different QMessage``Box(es) (question, warning, etc) are not mirrored in RTL mode... ie icons are on the left, buttons are LTR. Everything should be RTL wether the text displayed is Arabic or English (that's we we mean by reversedLayout after all).
- The translation of the 'No' button (in QMessage``Box) in Arabic is 'لا'. This is the correct translation that is indeed in the 'ts' file used. However, the display shows this word doubled, ie 'لا لا'... Is that an accelerator problem ?
- In a QLine``Edit: brackets, braces, parenthesis, greater and less than signs, ... are always reversed if a line begins with one of these characters and an Arabic text is inserted following it.
Misc
- The method QWidget::sizeHint() does not take account of the widget caption. Is that done on purpose ?
Answer from Trolltech: It's not necessarily on purpose, but since there is no defined way to find out the actual size of the window caption (esp. on X11) it is impossible to solve. QFont``Metrics would give you the size of the title, assuming that you know the font that is used (which on X11 is not really possible). And then you still don't know how big the various buttons are (system menu, minimize, maximize, close etc), so the using QFont``Metrics to calculate the size of the title bar contents give you an educated guess, at best.
Enhancements suggestions
- In RTL mode, all alignments should be by default set to right, even if there is only English text displayed (for example in QLabel, QLine``Edit, statusBar etc). However, the developer should be able to change the alignment after the object's creation. The same goes for LTR mode: Arabic should be aligned on the left and the developer (and thus the user) should be able to change the alignment by an easy method.
- What about adding to the library some new dialogs (like QFile``Dialog, QColor``Dialog...) in order to select the Pen``Style and the Brush``Style (and even the Pen``Join``Style and Pen``Cap``Style) ?
Answer from Trolltech: We don't see the generic use for this. Most applications would probably rather have a QCombo``Box or some other quick solution. We don't say it's useless in general, but we think it's not useful enough to make its way into a library with general-purpose solutions. We'll bring it up with our Qt Solutions team though.
Note
Is the 'ts' file shipped with QT updated with the library strings ?
Answer from Trolltech: It should be at least.
To be reported
Text Rendering bugs
- If a LAM ALEF is typed with one or more separate haraka for LAM and one or more separate haraka for ALEF, LAM ALEF is drawn with all the harakat stacked on top of a middle position between LAM and ALEF.
The expected behavior is that the harakat set associated with the ALEF is drawn on top of the ALEF and the harakat set associated with the LAM is drawn on top of the LAM.
- The set of "Waqf" Qur'anic characters (from U+06D6 to U+06DA) are drawn like any other haraka on a Y-Axis position depending on the height of the base letter and the number of harakat on it in addition to the "Waqf" character.
This causes, for instance, a "Waqf" sign to be drawn high and another "Waqf" (maybe even in the same verse of the Qur'an) to be drawn low causing the text to look very bad and makes it harder to track these "Waqf" signs. (see 
for a sample)
The sample on the shot is from (2) Surat Al-Baqara verse number 2:
" رَيۡبَۛ فِيهِۛ"
The expected behavior is that all "Waqf" signs are drawn on the highest possible position regardless of the height of the base character and/or the number of the harakat applied to it.
- ZERO WIDTH NON-JOINER (0x200C) is not displayed properly in Qt applications. [Munzir Taha]
