On Tuesday 05 November 2002 17:32, you wrote:
> Interesting article.
>
> If I am reading your article right you are advocating copying code
> from various UI classes. This can lead to lots of problems down the
> line. This is incredibly error prone and requires you to constantly
> update your UI classes with every release of the platform, you
> might not even pick up fixs found in update releases (the _ releases,
> such as 1.4.1_01).
>
Yes. that's true. That's exactly why I'm interested in incorporating
the technique which I proposed (not my implementation) into the
official JFC release.
> Just as application has different packages, an applications will often
> times have different resource bundles. This is especially true in large
> applications where various portions are loaded as needed. Your
> implementation seems to assume you will only ever have one
> ResourceBundle, which does not seem vary realistic. Additionally
> System.getProperty may throw a SecurityException in an
> applet/javawebstart environment.
>
If the technique will be adopted, a standard (maybe customizable) way
for finding the localizable GUI ressources of an application has to
be established. In the article, this is simply done by setting the
system property "MainClassName", then a ressource bundle with that
name is searched for.
But if you look for example at BasicFileChooser.java you can see that
anyway most of the text strings are loaded from a ressource file
(e.g. UIManager.getString("FileChooser.helpButtonText");). What would
be needed is just a more elaborate and customizable way to do it. And
to do it every time before a text string get's painted not just once.
> As you get at in your article overriding the UIs is very cumbersome as
> you have to multiply the effort by the number of UIs you wish to
> support. Is there a reason why you don't override the Swing class
> directly?
Because the painting is only done in the UI classes and some
ressources aren't even set in the Swing classes themselves, but in the
actual UI classes. (For example some of the file chooser button texts
like 'helpButtonText'. It's impossible to set it from JFileChooser.)
> Additionally overriding the UIs requires you to know the
> implementation and know where it calls into the J class to get the
> text, overriding the J class should take care of all UIs. Case in
> point, the layout methods need access to the text which would require
> your UIs to override these methods as well.
>
> -Scott Violet ([EMAIL PROTECTED])
>
As pointed out above: all the painting is done in the UI classes. All
I propose is not to paint (or layout) any text directly, but try to
translate it first based on the current locale. If this translation
fails for whatever reason, the text itself may be painted. This fall
back option gives you a nice kind of backward compatibility for any
application which doesn't want to have a run-time localizable GUI and
simply doesn't define any resoources, but simply sets all the text
attributs of labels, buttons, .. to concrete values.
To summerize:
- I propose to change the JFC in such a way, that all the
text ressources of any component will be painted only after beeing
translated according to the current locale. (This is in fact an
additional level of indirection.)
- This process of translation could be made configurable (for
example in the same way the 'bidi' algorithm is enabled for
StyledDocument) to avoid the overhead for users who don't need the new
functionality.
- The benefit will be a GUI wich will adopt to locale changes during
run-time. That's great - have a look at the IntNotepad demo which
is a patched version of the standard Notepad demo with the
before mentioned features. It's available at:
http://www.progdoc.de/papers/intSwing/intSwing.html
(Download 'IntNotepad.jar' and execute it with
'java -jar IntNotepad.jar')
Volker Simonis ([EMAIL PROTECTED])
> On Tue, Nov 05, 2002 at 06:52:22AM -0800, Chet Haase wrote:
> > Thought you two would like to see this post on the j2d interest
> > list...
> >
> > Chet.
> >
> >
> > -------- Original Message --------
> > Subject: [JAVA2D] Making Swing Components Locale-Sensitive at run-time
> > Date: Tue, 5 Nov 2002 06:33:02 -0700
> > From: Volker Simonis <[EMAIL PROTECTED]>
> > Reply-To: Volker Simonis <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> >
> > Dear list subscribers, dear Java2D/Swing team,
> >
> > recently I published an article called "International Swinging:
> > Making Swing Components Locale-Sensitive" which describes how to make
> > Swing components aware of locale switches at runtime.
> >
> > The article is available online at:
> > "http://www.cuj.com/java/articles/a23/a23.htm?topic=java"; or from my
> > home page: "http://www.progdoc.de/papers/intSwing/intSwing.html";.
> >
> > The changes I propose in the article are minor in my opinion while
> > providing a significant benefit to the Swing/JFC library
> > (automatically changing an application's appearance at run time in
> > order to conform to the conventions of a specific locale).
> >
> > I post this message here in order to ask the authors of Swing/JFC and
> > any other interested developers for theirs opinions and comments. Is
> > there a chance to incorporate the functionality described in the
> > article into the standard JFC distribution?
> >
> > I'm also interested in hearing somthing from the MacOS X Java porting
> > team, since for MacOS X the UI delegates are not available in source
> > code. So the technique applied in the paper could not be implemented
> > for the Mac Aqua Look and Feel until now.
> >
> > Sincerely,
> >
> > Volker Simonis
> >
> >
> > e-mail: [EMAIL PROTECTED]
> >
> > =========================================================================
> >== To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > of the message "signoff JAVA2D-INTEREST". For general help, send email
> > to
> > [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
