[jsword-devel] Look and Feel Switching

Joe Walker jsword-devel@crosswire.org
Tue, 09 Mar 2004 22:33:38 +0000


DM Smith wrote:

> I noticed that JSword has support for switching the look and feel of 
> the application.
>
> I have found some subtle and odd behavior.
>
> If you start the application in Windows LAF and then go to options and 
> change it to Metal, you only get a partial change. This can easily be 
> seen by bringing up a second copy of the application. The applications 
> look significantly different. An odd behavior is that any widget 
> created after the switch has the correct laf, but anything created 
> before does not.

Yes, the idea was to register parent less widgets with the look and feel 
manger class that I wrote so it could cope with changing them all properly.

> According to the Java Look and Feel Design Guide 2nd Edition 
> (http://java.sun.com/products/jlf/ed2/book/index.html), Appendix D: 
> Switching Look And Feel Design, switching is provided as a mechanism 
> for developers and not for end users. Sun cautions against letting the 
> user do the switching.

I have to admit my original thought was phooey, mostly as a result of 
having to hack about with Together (I think) ages ago to change the LAF 
from java to win on a win box. The results looked much better (to me) 
when Together used win LAF, and I was pleased when they later added the 
config option.

Though it as to be said that I'm not sure I would ever want to switch 
away from the win LAF on win (or that Mac LAF on Mac for that matter) So 
maybe Sun are right LAF is a developer only choice and therefore the 
Java LAF is fairly useless!!?

That said on Linux LAFs seem to be the norm, so maybe getting rid of the 
option all together isn't a good idea. I'm tempted to leave it in.

> What led me to find this was reading up on winlaf to see what it 
> provides. In looking at it I found that there was a discrepency 
> between what it said it provided and what JSword did. In looking into 
> it, I found that the LAF has to be installed before winlaf is 
> installed. The application does the reverse. I also found that winlaf 
> should only be installed if the laf is Windows.

I played with winlaf only briefly, thinking "install is more important" 
so I didn't get very far with it.

> If the user can switch the laf, I think it should be postponed until 
> the next run of the application. As a courtesy maybe it would be nice 
> to pop up a modal dialog box letting the user know it will occur at 
> the next startup. If this is done, then most of the LookAndFeelUtil is 
> not needed. Specifically, the methods setLookAndFeel(...), 
> updateComponents, addComponentToUpdate and removeComponentToUpdate are 
> not need.

This does simplify things quite a bit, and I think it is more important 
to cause some minor inconvenience (from restart) than potentially many 
bizarre side-effects (from wrongly lafed widgets)
So I agree.

> If the laf is to be an option, I think it would also be nice to 
> provide a pick list of the available lafs. I have found that this 
> differs between OS. For example, I don't have a Mac laf on my Windows box
> and on a Solaris workstation, Windows laf is not installable (it is 
> there but disabled, supposedly for licensing reasons). So the pick 
> list would need to be determined dynamically.

Not sure I can think of a good way to fix this.
Maybe next week.

I've had a quick look through the patch and it looks good.
I'd like to spend more time thinking about it than I have now, so I'll 
apply it next week if that is OK.

Thanks for your work on this,

Joe.