• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Set own LookAndFeel

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I created my own LookAndFeel as subpackage in my application. To set it I did the following:
programmatically in the start class (dbgui.Start) I wrote:
package dbgui;
.....
public static void....
UIManager.setLookAndFeel("dbgui.modellooks.MotifSpecial");
On the commandline I wrote:
java -Dswing.defaultlaf=dbgui.modellooks.MotifSpecial dbgui.Start
In a recommendation of John Zukowskis "definitive guide to swing for java 2" the commandline has to look as follows:
java -Xbootclasspath:HomeOfJsk\jre\lib\rt.jar;HomeDirectoryOfLookAndFeel
Dswing.defaultlaf=dbgui.modellooks.MotifSpecial dbgui.Start
But it functions without writing the Xbootclasspath in most cases. Can anyone tell me, why? In which cases do I have to use this statement additionally?
Thanks for your help,
liliana
 
Bartender
Posts: 4121
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You only need to either hardcode the call -


or set the swing.defaultlaf property -


Hardcoding it into the main method ensures that the program *always* runs using that look and feel, while setting the swing.defaultlaf property dynamically tells the program that *for this run* (or until you tell it otherwise in the code) that it will use the specified look and feel. Personally I think only setting it as a property is probably the best case (loose coupling of the application and the look and feel... it makes it easier to use either without necessarily needing the other).

As far as setting the bootclasspath - the only reason that is ever needed is if you need to override a class from the default APIs that you can't normally change due to classes or methods being inaccessible due to being private, protected, or package private. If you don't need to override anything hidden, you might as well just use the regular classpath. I'm assuming that this is working for you because the look and feel is in the same package structure as your program.
 
liliana punkt
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Nathan,
many thanks for your help.
Liliana
 
reply
    Bookmark Topic Watch Topic
  • New Topic