Re: [XNap-Commons-Devel] GUI Components to Support ComponentOrientation?

[Felix B. <bf...@gm...>]

On Thursday 27 October 2005 23:02, Sean Crotty wrote:

> > Could you be a bit more specific as to what components you would expect
> > to have support for component orientation and in what way? Does this only
> > affect text components?
>
> I think all the xnap commons GUI components need work in this regard.

After a first couple of tests it doesn't look that bad after all, the layout 
managers are orientation aware, so I just had to change a few constructor 
calls from new Boxlayout(BoxLayout.X_AXIS) to new 
BoxLayout(BoxLayout.LINE_AXIS) to get the desired effects. 

For the completion boxes we will have to add a propertychangelistener to the 
text fields to keep the orientations in sync.

> For example, FileChooserPanel inherits from java.awt.Component and
> thus offers an API to setComponentOrientation(
> java.awt.ComponentOrientation o ). Unfortunately, from what I can
> tell, using this API this does not rearrange the parts (text box, edit
> box, folder icon) of the FileChooserPanel based on the
> ComponentOrientation passed in. If I do:
>
> FileChooserPanel chooser = new FileChooserPanel(20);
> chooser.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
> The shown FileChooserPanel does not seem to rearrange for
> right-to-left languages like Arabic or Hebrew.
>

This could be remedied by what I described above.

> Other xnap commons GUI components like the various
> org.xnap.commons.gui.Dialogs hide access to the underlying
> java.awt.Component and so even setting the ComponentOrientation is
> impossible for them.

Are you supposed to call that for every component individually in the normal 
use case or shouldn't it be taken from the currently set locale, see 

static ComponentOrientation  getOrientation(Locale locale) 

So if you set the locale before you use any of the dialogs they should use the 
proper layout after we made the necessary changes, at least I'd hope it would 
work like this.

> The reason I ask is that I'm evaluating frameworks that will help
> facilitate development on a new project. However, this project must be
> fully I18N, G11N, L10N compliant. This includes supporting physical
> layout changes of GUI components for languages written right-to-left
> or even vertically.
>
> Many of the tools in xnap commons are attractive for my needs. If I
> can negotiate the time, I might even be able to devote some time to
> providing such support in the xnap commons source. It will really come
> down to whether the benefit of using the xnap commons components in
> their current state more than offset the time required to get them
> fully I18N-able.

Maybe I should warn you that our current I18n class lacks proper plural 
support as it is offered by GNU gettext.

I'd be interested to hear what other requirements come up. We are interested 
in improving the xnap commons code base, if the requirements prove to add to 
the general value of the components.

Thanks,
Felix

-- 
Try Debian GNU/Linux!
http://www.felix.beldesign.de/