Collectible Card Game Headquarters

GUI improvement proposal. Substance is one way to make swing applications look less like swing applications (which should generally be considered a good thing).

I tried adding it to forge just to see how it looks and I would say it's pretty nice. Here are some screenshots with different look-and-feels for your viewing pleasure:

http://i48.tinypic.com/97qmpd.jpg
http://i50.tinypic.com/w6utk4.jpg
http://i48.tinypic.com/10gxk5c.jpg

To add it I just commented out the first try-catch block in main in Gui_NewGame.java and added the following around the new Gui_NewGame(); call. The substance.jar of course needs to be in your classpath.

Code: Select all

JFrame.setDefaultLookAndFeelDecorated(true);
SwingUtilities.invokeLater(new Runnable() {
        public void run() {
            try {
                UIManager.setLookAndFeel("org.jvnet.substance.skin.SubstanceDustLookAndFeel");
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    });
           
SwingUtilities.invokeLater(new Runnable() {
        public void run() {
            new Gui_NewGame();
        }
    });


It did as I mentioned above interfer with the original implementation, had to comment some things out, but it's not something that would be hard to fix. There does however appear to be a few hardcoded areas. See the "resizable game area" in the second screenshot for instance. (It's whiter, you'll see it very clearly with a darker look-and-feel.) But again not that hard to fix.

One of the nice things is that the dependecy is resolved at runtime and could always fall back to the original design. Which means that anyone who would want this could simply download the substance.jar and place it in the classpath. For everyone else the application would work as usual.

It would take a bit more work but you could have it changeable at runtime as well. (Instead of a hardcoded string or something to that extent.) Have a look at the webstart demo on this page to see what I'm taking about.

Anyways, proposal submitted for your consideration.

Wow, I think this looks awesome, thanks for sharing Arch!
What do you guys think?

i think it's nice. runtime configuration should be easy, just like the Look & Feel chooser already in Gui_NewGame, so why not also for skins?

Yeah, curious name though, I think "Style" would suit it much better

Substance over style, ha.

I messed around with this, but I haven't succeeded in getting different skins to show up. I keep getting the following error:

java.lang.ClassCastException: org.jvnet.substance.skin.ChallengerDeepSkin cannot be cast to javax.swing.LookAndFeel
at javax.swing.UIManager.setLookAndFeel(Unknown Source)

Never mind, got it working now. I'll add a bunch of skins to the next version

I've added all of the Substance skins... some of them look great, thanks for sharing, Arch!!!
My favorite "look and feel" is this one (it's called Napkin Look And Feel, and it's actually not in Substance). I mean, how baddass is that? It looks like someone drew all of the stuff on a napkin

It's easily one of the best skins out there. The novelty wears off pretty quickly though.

I updated my local copy and followed the instructions that were included in the log message. I tried out most of the skins, some look good and other are hard to read.

Several time I had an exception while trying out the various skins. I also noticed that instructions for adding the external JARs results in a change in my local classpath file. Eclipse wanted to merge this into our SVN.

I deleted my local copy and re-imported the entire SVN. I still have a new classpath file after adding the External Archives and Eclipse wants to merge this new classpath file into our SVN.

I got a few exceptions also, but this only seems to happen after multiple changes of skins...
Hmm, what kind of classpath file is this by the way? For me, whenever I commit stuff, there's a lot of files eclipse wants to include... I just uncheck them.

DennisBergkamp wrote:I got a few exceptions also, but this only seems to happen after multiple changes of skins...

`
Yes, that is the same problem that I noticed

Hmm, what kind of classpath file is this by the way?

`
The Build Path -> etc command is modifying my classpath file. The Remote File BASE has this:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
   <classpathentry kind="src" path="src"/>
   <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/>
   <classpathentry kind="output" path="bin"/>
</classpath>

`
After using the Build Path -> etc command I get this:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
   <classpathentry kind="src" path="src"/>
   <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/>
   <classpathentry kind="lib" path="/Users/chrish******/workspace/ForgeSVN/res/lib/jdom-1.0.jar"/>
   <classpathentry kind="lib" path="/Users/chrish******/workspace/ForgeSVN/res/lib/jl1.0.1.jar"/>
   <classpathentry kind="lib" path="/Users/chrish******/workspace/ForgeSVN/res/lib/napkinlaf-1.2.jar"/>
   <classpathentry kind="lib" path="/Users/chrish******/workspace/ForgeSVN/res/lib/napkinlaf-swingset-1.2.jar"/>
   <classpathentry kind="lib" path="/Users/chrish******/workspace/ForgeSVN/res/lib/nimrodlf.jar"/>
   <classpathentry kind="lib" path="/Users/chrish******/workspace/ForgeSVN/res/lib/substance.jar"/>
   <classpathentry kind="output" path="bin"/>
</classpath>

`
Looking at the diff of these two files I can see the diff being the hard drive path to the jar files included in the recent SVN update.
`

For me, whenever I commit stuff, there's a lot of files eclipse wants to include... I just uncheck them.

`
I have not yet found a way to uncheck this file and I am concerned. I do not want to merge this classpath file. It may cause problems. Maybe Silly Freak knows something about this and can explain this to me.

I have not yet found a way to uncheck this file and I am concerned. I do not want to merge this classpath file. It may cause problems.

`
OK, I finally figured out how to uncheck this one file when I merge my work with the SVN. Cool.