[11011001]

So, what kind of tools are available for developing a GUI for a pure java cross platform application?

I take it that it is not possible to use Interface Builder and nibs if it's supposed to be cross platform huh?

[Kristoff]

Tools?

you don't really need any. I always code the gui by hand. Java's Swing and AWT classes are really easy.

[depolitic]

If you are learning Java then I would serially advise you to learn how to hand code swing applications by hand. Just so that you understand the basics.

Many people have different view on how to build good java swing GUI's. What layout manager do I use? Swing versus AWT versus SWT etc etc.

You can download Netbeans and Eclipse and both have swing and swt visual editors. However I have found that jvider ( www.softandco.com/a/8201/jvider.html ) is the best just because of its speed.

I will give you the following tips, many folks will tell you to use GridBagLayout, as it is feature rich, however it is overly complex and can behave in unexpectant ways. Their is also some performance questions about applications built using GridBagLayout.

I have found it better to use a combination simple layout managers like box, and SpringLayout. It is also useful to use Interface builder to mook up an interface, as it helps you see the final gui while following the Aqua interface guidelines. Also avoid absolute positioning at all cost it may looks simple but as soon move os you are F***

Also look at the Aqua Developer Interface Guidelines.

Best of luck.

[djohnson]

The only thing I have really written in Java was a GUI to control a robot. It would display the position on a map it created along with the ability to move the robot to point X,Y on the map. It was written on a Sun machine and then ran on a stripped version on linux. Java is uber easy, I taught myself everything I needed to know in about 4 hours a day for 3 days. I would suggest Swing as it works well on *nix's. We never tested it on windows... but it looked great in OS X as well. Umm... you can use absolute positioning, just make sure you lock the window Oh and stay away from windows!!!

[Arkham_c]

Take a look at Foam. It's pretty interesting.

[itai195]

Unfortunately I'm not as big on Swing as the other posters here. I've used JBuilder's Swing GUI builder and it's pretty decent, though you still need to fill in some code by hand of course. Coming from a Cocoa/Obj-C background, I don't think Swing is anywhere near as easy as Cocoa for building user interfaces and I haven't found a tool that matches Interface Builder, but it's more than possible to teach Swing to yourself in a few days. Also, coming from a Cocoa background -- Java really could use delegates. You'll see what I mean when you start having to subclass all of Swing's adapter and action classes. I've also found that YMMV in regards to crossplatform Swing development and you really ought to test your GUI on every platform/jvm you're targeting. I'll echo that absolute positioning is a bad idea.

That's probably more advice than you wanted, but the second sentence is relevant

[depolitic]

Different look and feels space object differently and even if you lock the window with absolute positioning, you will run into problems Apple does not recommend the use of absolute positioning for that reason. With absolute positioning applications you will often find that widget are outside the window edge and unreachable, as you switch LAF and OS�s.

Also absolute positing does not make for a very flexible layout manager, windows should expand and shrink.

As for Cocoa versus Swing, no contest Cocoa kicks ass in pure simplicity. However Cocoa is not portable and is not part of Java specification and for many people Java is were we make our living.

I only hope that Apple adds Swing support to Interface Builder in the future since Java is capable of the same dynamic linking of objects that Cocoa has.

[itai195]

Originally posted by depolitic:
As for Cocoa versus Swing, no contest Cocoa kicks ass in pure simplicity. However Cocoa is not portable and is not part of Java specification and for many people Java is were we make our living.

You're absolutely right. I just wanted to mention my own personal experience with it, in case 11011001 is coming from a cocoa background.

[11011001]

Yes, I am coming from a Cocoa background, and I am finding coding some things that are so simple a real pain in the a$$ in Java. I wish there were delegates too... grr.

Oh well.

I intend to learn swing and AWT whether I use a graphical builder or not. But, the scope of what we have to do in this course makes coding our entire interface by hand a bad idea.

[11011001]

Just some updates:

Foam is brilliant.. it's exactly what I would like to use. However, it's $300 (EDIT: i was giving a rough estimate in Canadian dollars. with the current exchange rate it is $ 263 sorry for misleading people ), and I found it to be very buggy still. (EDIT: some clarification, the bugs aren't that big, but i got frustrated enough at one point that i judged it a little too harsly. however, in comparison to some of the other things I have been working with.. the gripes are trivial. It's a good product, for those who can afford it i'd recommend taking a look)

I never got anything working in Eclipse for building interfaces.

NetBeans is too slow.

However, I found two excellent solutions that I like.

One is uicompiler. This is a great little tool. You design and layout your interface in Qt Designer. (i don't know what QT stands for, but it's not quicktime). Designer is very good at something like GridBoxLayout, using spacers. You save the widget as a .ui file. Then you run uic.jar on it, to produce a Java class for you window. Then, you extend the class to add your actions functions. It works very nicely.

The other alternative is Borldand's JBuilder who's latest solution has a nice built in GUI builder that generates the code for you. No complicated process for the compiling (first saving the file as a .ui, then running uic on it, and then extending that class, as one has to do in uicompiler). See this thread for instructions on building and installing the Linux version of JBuilder Foundation for OS X.

So, now my question is. Which do you think I should go for, uicompiler, or JBuilder. The GUI builder in QT Designer is superior in terms of actually laying everything out, and extending the class is also nice, in that it keeps GUI code and event handling code seperate. But alternatively, I can put things together quicker in JBuilder. I think uicompiler will be easier if we need to make changes to the GUI later on.

What do you guys think? Which should I go for? And has anyone actually used either of these two solutions?

Finally, for a nice discussion on serialization of Java GUIs take a look at this weblog over at java.net. It's where I found out about uicompiler and discusses the quest for something comparable to IB.

[itai195]

Don't JBuilder and QT Designer also cost money? I know JBuilder used to be available for academic use for $99. I've used it before and it's decent, but it's no IB. You probably got a pretty good idea regarding its capabilities from the tutorial. It has a factorization feature that I like, though it's unrelated to the UI tool. It did tend to crash a lot on Mac OS X when I used it, but that was an old version (v7) and it might have been Apple's fault.

BTW, I think there are some Java GUI builder plugins for Eclipse on sourceforge.net.

[hengx]

Originally posted by itai195:
Don't JBuilder and QT Designer also cost money?

Not JBuilder Foundation X. It's a free download.

Originally posted by itai195:
BTW, I think there are some Java GUI builder plugins for Eclipse on sourceforge.net.

Yes, I think you're correct.

I don't know, as a beginner I think it's wise to not use a tool that generates the GUI for you, so you learn what actually happens behind the scenes. Of course, it involves much more work, but you learn a few things that way...

[gperks]

Foam is currently $199, not $300. It's already a very good cross-platform solution, and the next release should contain some very interesting cross-platform/cross-L&F features.

I've emailed 11011001 asking about the bugs he has found.

Cheers,
Graham Perks.
http://www.computersinmotion.com

[Arkham_c]

Originally posted by gperks:
[B]Foam is currently $199, not $300. It's already a very good cross-platform solution, and the next release should contain some very interesting cross-platform/cross-L&F features.

I've emailed 11011001 asking about the bugs he has found.
/B]

Thanks for stopping by and representing Foam. I downloaded the demo and was very impressed. If I ever need to write a Java GUI app for anything, I'll probably use Foam. All my significant java code has been server-side up to this point.

[absmiths]

Originally posted by 11011001:
Yes, I am coming from a Cocoa background, and I am finding coding some things that are so simple a real pain in the a$$ in Java. I wish there were delegates too... grr.

So, how do you use delegates in Cocoa that are so much easier than extending a single class and overriding a single method? For what it's worth, I don't know how delegates work in ObjC, only C#.

Most of the time when programmers make broad complaints against Java it is because they haven't learned the entire language and have only found one way to do something.

[11011001]

Originally posted by absmiths:
So, how do you use delegates in Cocoa that are so much easier than extending a single class and overriding a single method? For what it's worth, I don't know how delegates work in ObjC, only C#.

Most of the time when programmers make broad complaints against Java it is because they haven't learned the entire language and have only found one way to do something.

Yes, this is exactly what I do in Java.. extend the classes.

Anyways, the Cocoa method is a lot nicer. It totally abstracts the design and layout of the interface from the code. You connect to your interface through delegates.. and your interface passes actions to the controller class. Coming from this background, where a lot of things were automated, and abstracted away from the programmer, to an environment like Java, where I have to handle these things myself, I must say, that I prefer Cocoa, and am finding what is trivial in Cocoa a bit of a pain in Java.

Don't get me wrong though, I love Java.

[itai195]

I think it's more an issue of convenience. Obj-C sacrifices some type safety for this feature. There's nothing wrong with the way Java does it, but it certainly makes you jump through a few more hoops and makes your code uglier.

[gperks]

Foam's pricing strategy has changed and Foam now costs just $99! And $375 for a team pack (5 licenses)!!

11011001 has edited his prior post on Foam, so let me reiterate one part: "Foam is brilliant.. it's exactly what I would like to use".

There's also an update for Foam available to upgrade you to 1.1.02. It lets you center beans around any other bean - handy for situations like Up and Down buttons under a list. Just select "Check for updates" from the Help menu.


http://www.computersinmotion.com

[absmiths]

Originally posted by 11011001:
Yes, this is exactly what I do in Java.. extend the classes.

Anyways, the Cocoa method is a lot nicer. It totally abstracts the design and layout of the interface from the code. You connect to your interface through delegates.. and your interface passes actions to the controller class. Coming from this background, where a lot of things were automated, and abstracted away from the programmer, to an environment like Java, where I have to handle these things myself, I must say, that I prefer Cocoa, and am finding what is trivial in Cocoa a bit of a pain in Java.

Don't get me wrong though, I love Java.

I agree that Java has no tools like XCode/IB and no frameworks like Cocoa, but I personally don't use stuff like that anyway. I generally stick to coding UIs by hand as automated stuff usually breaks down at some point - then you are left to maintain a (usually horrid) design inflicted by the tool. The delegates that C# programmers always complain about Java lacking are pointers to generic functions that can be called regardless of the owning object or the name, etc. Basically a function pointer from C. Java certainly does not have that, but there are always typesafe ways to do the same thing and have a more solid design as a result.

[absmiths]

Originally posted by itai195:
I think it's more an issue of convenience. Obj-C sacrifices some type safety for this feature. There's nothing wrong with the way Java does it, but it certainly makes you jump through a few more hoops and makes your code uglier.

Ugly code is always a matter of choice. I have seen both elegant and atrocious UI code which get their job done. Actually, one of my main complaints against Cocoa is that it does not seem possible to construct a completely dynamic UI which is built in code from the ground up. Using IB seems to be the only option.

Type safety can be a huge boon - especially in very large projects.

[geekwagon]

Originally posted by absmiths:
Actually, one of my main complaints against Cocoa is that it does not seem possible to construct a completely dynamic UI which is built in code from the ground up. Using IB seems to be the only option.

There must be a way to do it, as a few people are in the process of porting wxWindows (which is a C++ cross platform GUI toolkit if you are unfamiliar with it) to creating Cocoa applications. I spent 2 or 3 minutes browsing through the source and I don't see any NIB files or anything. They must be doing it dynamically, as that is how wxWindows works.

[Michel Fortin]

Originally posted by geekwagon:
There must be a way to do it, as a few people are in the process of porting wxWindows (which is a C++ cross platform GUI toolkit if you are unfamiliar with it) to creating Cocoa applications. I spent 2 or 3 minutes browsing through the source and I don't see any NIB files or anything. They must be doing it dynamically, as that is how wxWindows works.

Code:
NSWindow *window = [[NSWindow alloc] initWithContentRect:NSMakeRect(100,100,300,300)
    styleMask:NSTitledWindowMask backing:NSBackingStoreRetained defer:NO];
NSView *view = [[NSButton alloc] initWithFrame:NSMakeRect(10,10,50,250)];
[[window contentView] addSubview:view];
[window makeKeyAndOrderFront:nil];

And now you have a window with a button inside.