Re: SwingX and ResourceBundles

Hi Karl,

good that you took the initiative 

Just make sure we really understand what is happening and
why some 
things are not working as expected: as I already noted in
the issue - we 
had tons of weird problems with resources and the current -
suboptimal - 
approach was what was considered "best working" at
that time. And 
beware, that localization problems have a tendency to creep
up in non-us 
machines <g> We have the XLocalizeIssues test with
both visual and unit 
test methods which are meant to shed light on some aspects
(incomplete, 
at some point we gave up).

That said, the theoratical  best approach (as I understood
Fred, forgot 
the details) is to add the resourceBundle to the
lookAndFeelDefaults of 
the UIManager

[code]
// commented code in LookAndFeelAddons
UIManager.getLookAndFeelDefaults().addResourceBundle(
               
"org.jdesktop.swingx.plaf.resources.swingx");

[/code]

With that in place (commenting the copy code of the
key/value pairs) and 
a fairly recent jdk (1.5u11), the localize unit tests are
passing - 
except when trying to find the Locale.US. Using a FRENCH
f.i. is okay. 
Same for visual tests with column control. Still no luck
with updating 
the find dialog (but that could be a problem with the
setup). On the 
other hand, swingx-demos fail with a NPE in JXDatePicker -
the 
UI-property "linkFormat" isn't found. So we are
back in  the old 
weirdness: some properties are found, others not. The usual
suspect for 
so much weirdness are classLoader issues, which equally
usually nobody 
understands really 

(UIManager.getDefaults().addRB looks okay - but as already
mentioned, 
was considered the wrong thing, maybe searching the forum
would turn up 
the exact reason for this).

So maybe we should leave it as is - the risk to introduce
instability is 
high, nothing I feel comfortable with a major release
nearing.
> In 1.6 adding ResourceBundles to the UIDefaults seems
to work as expected for the tests that we ran.  In 1.5,
there were some issues with non-default locales.  (I did not
experience those issues with update 12, but that is no
guarantee that they are not there.)  However, those 1.5
issues would be no more limiting that what is currently in
place and since 1.6 seems to work fine, using the
addResourceBundle approach seems to be a long-term win.
>
>   
well, could read that argument the other way round: we are
on 1.5, and 
can wait to explore this issue to greater depth once we
switched over.

As to your other suggestions - good to start thinking about.
One vs. 
more resource files is a common raging argument (myself
swaying slowly 
from one-big to one-per-class ;)  As is their location -
f.i. they  
often are expected under the classes they are installed for.
We might 
want to extract them under a dedicated source hierarchy (but
this could 
be done transparently, so only a minor issue). Personally, I
don't see 
anything wrong with multi-dot resource keys (appframework
uses them 
extensively): they are easily readable by translators as
well as easily 
parseable by code. But then, that's probably another raging
debate <g>

Cheers
Jeanette

------------------------------------------------------------
---------
To unsubscribe, e-mail: jdnc-unsubscribejdnc.dev.java.net
For additional commands, e-mail: jdnc-helpjdnc.dev.java.net

just a quick follow-up:
> Still no luck with updating the find dialog (but that
could be a 
> problem with the setup).
it's a bug in find panel - does nothing to update itself on
Locale changes.

Jeanette

------------------------------------------------------------
---------
To unsubscribe, e-mail: jdnc-unsubscribejdnc.dev.java.net
For additional commands, e-mail: jdnc-helpjdnc.dev.java.net

Jeanette,

> good that you took the initiative 
Thanks.
 
> Just make sure we really understand what is happening
> and why some 
> things are not working as expected: as I already
> noted in the issue - we 
> had tons of weird problems with resources and the
> current - suboptimal - 
> approach was what was considered "best
working" at
> that time. And 
> beware, that localization problems have a tendency to
> creep up in non-us 
> machines <g> We have the XLocalizeIssues test
with
> both visual and unit 
> test methods which are meant to shed light on some
> aspects (incomplete, 
> at some point we gave up).
I understand what you're saying.  I think, though that we
should, at least, have all of the UI delegates behave in the
same way.  Some classes walk the bundle, others use the
utility method in LookAndFeelAddon, others (used to at
least) walk the bundle during the static initialization
block (I think that's no longer used anywhere).  Regardless
of what approach we take we should have all delegates use
the same approach.  This will be easier for migration in the
future.
 
> That said, the theoratical  best approach (as I
> understood Fred, forgot 
> the details) is to add the resourceBundle to the
> lookAndFeelDefaults of 
> the UIManager
That approach seems to work well on 1.6.  There is always
another option, which is to emulate the resource bundle code
in UIManagerExt and have all Addons use UIManagerExt.getXXX
methods to access bundle properties.  That could be the most
interesting short term solution.
 
> So maybe we should leave it as is - the risk to
> introduce instability is 
> high, nothing I feel comfortable with a major release
> nearing.
Well, let's at least bring everything together using the
same approach.  I'm OK with using or not using the addRB
method or with placing the properties in the UIDefaults. 
Another short-term fix might be to load the bundles inside
the components and keeping a static instance.

> As to your other suggestions - good to start thinking
> about. One vs. 
> more resource files is a common raging argument
> (myself swaying slowly 
> from one-big to one-per-class ;)  As is their
> location - f.i. they  
> often are expected under the classes they are
> installed for. We might 
> want to extract them under a dedicated source
> hierarchy (but this could 
> be done transparently, so only a minor issue).
Sure, we can place them anywhere, but as they are (or should
be) addon-relate, having them in plaf.L&FName
directories (or subdirectories) seems best (to me ;).  And
as much as I thought I'd be in for the big file, after
looking at what we're doing, I think that smaller
per-component files are the way to go.

> Personally, I don't see 
> anything wrong with multi-dot resource keys
> (appframework uses them 
> extensively): they are easily readable by translators
> as well as easily 
> parseable by code. But then, that's probably another
> raging debate <g>
I don't recall them in the app framework, but then I haven't
used it in a while.  Kirill seemed to be the biggest
proponent of X.Y names, saying that they are the
"expected" style.  Really, we should defer to the
L&F implementors on this one.  Kirill, Wolfgang, any one
else, your thoughts, please.

Karl
[Message sent by forum member 'kschaefe' (kschaefe)]

http://forums.java.net/jive/thread.jspa?messageID=243813


------------------------------------------------------------
---------
To unsubscribe, e-mail: jdnc-unsubscribejdnc.dev.java.net
For additional commands, e-mail: jdnc-helpjdnc.dev.java.net