 |
RTL support in Swing - part II
Posted by kirillcool on March 28, 2006 at 09:49 AM | Comments (13)
The previous entry on LAF support for RTL components compared various core (Metal / Windows) and third-party look-and-feels for RTL-oriented menus. Due to a bug in core Swing classes, all LAFs suffered from accelerator alignment problem (has been since partially fixed in Looks). I have filed a bug (internal number 653437) on this issue on February 19th with the proposed fix, but five weeks later it hasn't even been acknowledged. Oh well :(
Now it's time for RTL combos. First, before people start pointing fingers to the specifications, here is a screenshot of RTL combo in IE7 on XP (it looks the same in Firefox):
Note that not only the drop button is on the left-hand side, but the popup itself is layed accordingly (scroll on left, everything aligned to the right). Having native acquaintance with RTL environment, i can most certainly confirm that this is how it should look like. Now, let's see Metal and Windows core Swing LAFs:
Here, we have three major problems that are propagated to almost all third-party LAFs as well:
- The selected value is not right-aligned and is instead very close to the drop arrow button.
- The scroll bar on popup is on the right side and not under the drop arrow button.
- The popup values are not right-aligned
The overall impression is that of a complete disaster (and i'm not exaggerating).
What about third-party LAFs? JGoodies Looks was the clear winner in RTL menus, but this time Substance comes on top (after significant code fixes:). So, the first place is Substance:
The second place belongs to Synthetica (commercial), JGoodies Looks, Squareness and Pagosoft (with the nice touch of flipping the arrow orientation on popup activation). All of them inherit Swing problems with renderer alignment and scrollbar placement:
The third place goes to Liquid and Tiny with the additional problem of the location of drop arrow button:
The fourth place goes to Napkin with the additional problem of missing glyphs and no visual mark of currently selected (rollover) item:
The fifth place goes to Office (ClassCastException on NetBeans color selection combobox with custom cell renderer), Trendy (commercial, the same ClassCastException) and Metouia (NullPointerException).
In addition to this RTL problem in core Swing classes, i have also found two other problems:
- Scroll buttons on wrapped tabbed pane are not shown at all (with the exact fix) got internal number 673417 on March 19.
- System menu not correctly aligned got internal number 673418 on March 19.
Needless to say that both are yet to appear on bugparade. And if you're about to say "Contribute to Mustang, that's why we have the process" - sorry, don't have the time to invest in this.
Bookmark blog post: del.icio.us Digg DZone Furl Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Kirill,
Thanks for these excellent articles. I'm very interested in writing user interfaces that work for all languages and writing systems, but despite my best intentions, I just don't know what guidelines to follow for different cultures. Furthermore, as I don't know Arabic, Chinese, Hebrew, et al (basically any non-Western language or writing system) I can't even guess and see if I get it right.
Is there anywhere you can recommend I look for screenshots of various applications or mock applications, featuring comprehensive widget sets, or just good guidelines?
Thanks,Chris
Posted by: chris_e_brown on March 28, 2006 at 12:31 PM
-
Chris,
Usually, Microsoft (Office line) gets it right. If you can get your hands on multi-language Office (or try looking for screenshots on MDSN - i saw quite a few of them here). Obviously, when you don't know the language, it's quite problematic to understand not only the translations and relative locations of various dialog elements, but also you're missing the cultural background behind the layouts. In addition, when you're designing a l18n / l10n screen, you have to consider that some languages are more verbose (like German) and some are much less (like Chinese which has much narrower strings but due to symbol complexity needs larger font size).
Personally i have good (10+ yrs) knowledge of RTL environments which comes very handy in spotting Swing problems in this area. The latest release of JGoodies Looks features support for non-Western fonts - perhaps it would be worth your while to see that code. I'm not aware of any tutorial on this subject - you need a native speaker (with good Java coding skills and good design skills -> that's why Microsoft can afford releasing its products in 100+ languages).
This is a link to PDF file with screenshots of one of the leading financial software programs with a lot of RTL screens. As you will see, without knowing the language it can be tricky to understand why some of the controls are LTR while most are RTL. Installing this program (second link) will give you two PDFs in "User's Manual" directory). You can compare the screenshots there.
Posted by: kirillcool on March 28, 2006 at 01:33 PM
-
Interresting blogs..
Can you take a look at general layout managers and how well they support RTL? I know that the NaturalLayout (part of the UIC package) will reverse the orientation automatically; I'm wondering how many layout managers follow that idea!
Posted by: zander on March 28, 2006 at 07:17 PM
-
First off, thanks for this blog entry.
It would help if you provide the exact Java environment
and L&f versions used for your test. The Sun Windows L&f
is getting better and better with every Mustang build,
as do the third-party L&fs.
Next, the JGoodies Looks consists of two L&f families:
the JGoodies Windows L&f and the JGoodies Plastic L&fs.
So you may test them individually, or just test
the JGoodies Windows L&f and Plastic XP.
The JGoodies L&fs do not inherit the renderer alignment problems
from the core L&fs. Actually there's quite a lot of code
for getting:
a consistent font baseline position for editable and non-editable combos,
consistent component bounds,
an improved lead gap for popup values,
popup values that are aligned with the combo box value,
a consistent selection background rectangle,
a scrollbar width that honors the desktop settings,
a scrollbar that is aligned with the combo popup button.
The focus for the JGoodies Looks 2.0.x is to bring these
consistency improvements for RL orientations.
Some of the improvements made will work with all renderers,
others are unleashed only with the default renderer.
The other way round: a poor custom renderer cannot be handled
perfectly by the combo and combo popup.
The JGoodies Looks Demo has a Combo test page where you can see
how different renderers affect the features mentioned above.
I've recently described how to write a good custom renderer.
More on this will be done if I implement my proposal for a
customizable micro layout.
Thanks again and go ahead,Karsten
Posted by: karsten on March 30, 2006 at 06:24 AM
-
Thomas (Zander),
I favor to separate concerns in layout systems over having every feature in the layout manager. With the builder pattern, almost any layout manager can get support for RL and LR orientations, as well as TL and TR.
Separation of concerns typically leads to smaller parts, where each part is easier to understand, to manage, to maintain, to reuse, to replace, and to customize.
The other way round. If you put all advanced features into the layout manager, not the layout system, it'll likely end up with a bloated design. In the JGoodies Forms layout system I've separated the support for: orientations, platform layout styles, minimum sizes, Dialog Units and other sizing units. Sun's GroupLayout does the same with its layout style.
Posted by: karsten on March 30, 2006 at 06:33 AM
-
Karsten
The tests were done under JDK 5.0_06 on XP SP2. The behaviour is the same for JDK 6.0-b59g-beta. I have used 2.0 release of Looks on PlasticXP on the following code:
final JComboBox combo10 = new JComboBox(new Object[] { "\u05e8\u05d0\u05e9\u05d9 1",
"\u05e8\u05d0\u05e9\u05d9 2", "\u05e8\u05d0\u05e9\u05d9 3", "\u05e8\u05d0\u05e9\u05d9 4",
"\u05e8\u05d0\u05e9\u05d9 5", "\u05e8\u05d0\u05e9\u05d9 6", "\u05e8\u05d0\u05e9\u05d9 7",
"\u05e8\u05d0\u05e9\u05d9 8", "\u05e8\u05d0\u05e9\u05d9 9"});
combo10.setToolTipText("RTL combo");
combo10.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
combo10.setMaximumRowCount(6);
In case you're interested in fixes, see SubstanceComboBoxUI class. It has quite a few cases for component orientation in both property change listeners and initialization code (hopefully i have all cases covered, but if not - let me know).
The above code is one part of the test. Another is changing the current locale to RTL (Hebrew / Arabic) and checking that all application combos are RTL.
Posted by: kirillcool on March 30, 2006 at 06:49 AM
-
Hi Kirill, very interesting - as always.
However, I wondered what version of my LookAndFeel you were using. The ComboBox looks like the old version (the box is _way_ to big and it'd be definitly another bug that I'd have to fix - though I thought I already smashed it for the... oh well... third time, I guess - if it was in the newest version). Anyway, there's definitly something wrong with my work and I'll have to fix that.
Posted by: pago on March 30, 2006 at 10:38 AM
-
Patrick,
You're right, i was using 0.2. I have updated the screenshot to 0.5 (the visual noise around arrow buttons is gone). You might want to take a look at the sizes of different (especially editable) comboboxes. You can download substance.jar and substance-tst.jar from Documents & Files section and run the substance-tst.jar. Then, go to "Combo box" tab and select "Look & Feel -> Custom LAFs -> Pagosoft" menu entry. You'll see an assortment of combos (the panel is in test.CombosPanel class in substance-src.zip) with widely varying sizes under Pagosoft.
Posted by: kirillcool on March 30, 2006 at 12:34 PM
-
Thanks for noticing the issues on Napkin ;-)
The visual indications for selection aren't there even for "normal" menus; this has been added in only recently (after 1.0, that is)
As for the missing glyphs, we have been working on a possibly cool solution on that (without touching the original font files, that is)
But yes something needs to be done about the scrollbar and the alignment :-/
Posted by: alexlamsl on March 31, 2006 at 02:28 AM
-
ok "menus" reads "combo boxes"
Posted by: alexlamsl on March 31, 2006 at 02:29 AM
-
Thank you very much Kirill. I'll have a look at the combobox sizing.
Posted by: pago on March 31, 2006 at 09:41 AM
-
Very good post, our application does live RTL switching for Hebrew support. People reading this article might find it helps them visualise how an RTL layout should appear in a real world application. You can check it out (live and free using JWS) by going to http://wg.vprise.com. In the application to see the Hebrew language just select within the "Languages" option "עברית" and it should switch on the fly, then you can try to return (the world English will still uppear in English so you shouldn't have much of a problem finding it).
Posted by: vprise on April 07, 2006 at 12:13 AM
-
Shai,
Can't you provide a sample demo without the need to go through the registration process. Nowadays it's a real turn-off (at least for me), but it really depends on how badly people want to check the particular application. Perhaps few more screenshots?
Posted by: kirillcool on April 07, 2006 at 04:53 PM
|