Related
Swing provides the basic building blocks for any GUI application but what about a higher level take on building GUI applications?
I'm not asking about the many arbitrary libraries that provide yet more wizzy variants on various visual components.
I'm talking about the missing pieces that everyone ends up building themselves whenever they create anything other than a trivial GUI application.
I.e. the framework that the application specific logic builds on.
E.g. handling data binding, application lifecycle issues or supporting common things like building forms.
If we were talking about persistence you could say that anyone can code up their own persistence layer using the javax.sql or java.io classes - however most people would rather use something like Hibernate.
So, just as someone asking about persistence libraries probably isn't looking for variants on ObjectOutputStream, I am not looking for variants on some JComponent subclass or other.
I think this is a fair Stackoverflow question as, unlike areas like persistence, a clear consensus on the answer is not easy to determine using Google.
Rather than a grab bag of random libraries perhaps people could answer in terms of what GUI issues are not immediately addressed by Swing and what libraries they feel best fill these gap?
I asked a similar question to this last week and it was closed - I've tried to phrase this such that this won't also be closed. If you feel inclined to close it perhaps you might consider making it community wiki instead?
Here are some essential libraries:
JGoodies - http://www.jgoodies.com/. This provides some nice layout tools (FormLayout) as well as common builders and databinding tools
SwingLabs - http://www.swinglabs.org/. This provides many common components you likely may need to use that are not part of standard swing.
Swing Application Framework - https://appframework.dev.java.net/ (already mentioned by jluzwick)
Groovy SwingBuilder - http://groovy.codehaus.org/Swing+Builder. This provides for easier building of GUIs by using a logical, hierarchical scripting-like language for building GUIs. It also has native support for some databinding.
Could you be referring to something like this?
https://appframework.dev.java.net/
This was integrated with Netbeans at one point and I don't think the development has continued, but this framework greatly helped me in creating a much more involved application with java.
EDIT:
It seems these projects are derivations of the former I mentioned that are actively in development:
http://kenai.com/projects/bsaf/pages/Home
http://kenai.com/projects/guts/pages/Home
JGoodies Bindings is great if you want to have a well-architected program.
NetBeans Platform (RCP) I really want to try. It's really the only viable Swing frameworks because ...
Swing Application Framework is very lacking and is not actively in development anymore.
MiGLayout is my favorite layout manager for cases where I used to use GridBagLayout (long time ago) and JGoodies form layout. Also, I dislike GroupLayout.
Have look at the NetBeans Platform (Swing based RCP)
I've been writing Java web (JSF, Struts, JSR168) apps for a number of years. With the recent departure of a colleague, it looks like I'm going to be building more client applications. I've used Eclipse since the beginning and I'm really comfortable with it. It feels as though SWT is waning (just an opinion based on literature I can find) and Swing is surging.
My question:
Is there value in learning Swing through writing apps by hand in Eclipse (as opposed to using Matisse in Netbeans)?
Yes, it is very valuable to learn coding Swing apps by hand. One reason for this is that no GUI-Designer I know always does the things you want them to do. The other - and in my opinion more important reason - is that most GUI builders (especially NetBeans') generate all and everything into one single class. This can be very annoying because the maintainability is reduced a lot (separation of concerns). Also many GUI builders have blocked regions, i.e. you cannot modify the generated code by hand. Or if you do the GUI builder will overwrite it the next time you use it.
However that standard LayoutManagers coming with Swing are very complicated. This is why I suggest that you give MigLayout or JGoodies FormLayout a try. On the JGoodies site you also find other libs for alternative Look&Feels, Binding and Validation, which can be very useful.
I would also suggest that you have a look at the Presentation Model pattern (Martin Fowler), which helps a lot if you want to unit-test your GUI-behaviour.
If you then are motivated to improve the design and add some very cool effects to your application check out the book Filthy Rich Clients.
Hope it helps.
Yes, definitely - even if you plan on using Matisse most of the time, you will benefit from having at least a reasonable understanding of the Swing code under the hood.
It sure will help. Maybe you'll reach the end of what Matisse can do, and want to tweak some of the code by hand. At this point it will be better to know what happens under the hood.
Note that using Matisse and writing Swing by hand are not mutually exclusive at all. Matisse just produces Swing code, and you can customize it. You can make part of your GUI with Matisse, and the part next to it by hand, for instance. Get the best of both worlds - that's how I do it, at least.
Fast way to learn how to do something in Swing is to do it in Matisse, and then see the code it produced.
You definitively need to know how Swing works since you will most likely have to adapt and change things which the GUI prgram expects you to know how works and what it is called.
The Java Tutorial has a good Swing trail: http://java.sun.com/docs/books/tutorial/uiswing/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What mechanism do you prefer for building a GUI: from scratch or using GUI-building software?
If the question is about GUI development using Swing then IMO it is best to code everything manually without a WYSIWIG tool.
In order for a manual UI design/coding to be efficient a really good layout manager should be used. MigLayout is one of such layout managers. Since I've started using it I have never looked back at WYSIWIG tools -- a sheet of paper, a pencil, MigLayout and you get a full control over your design and code.
Also tools like Balsamiq simplify making GUI mock ups for quick prototyping if the paper and pencil approach is not suitable.
My personal opinion is never use visual editors. Until there is a single standard for GUI-building in Java you will find yourself tied to an IDE. The best IDE for building Java GUI has switched around quite a bit in the last 10 years (I wonder how many projects were hit by a massive maintenance overhead from switching away from JBuilder for example).
For most applications, the actual layout of GUI code is probably something like 5-10% of the total amount of time you are likely to spend writing the app as a whole. Therefore even halving this by using a designer is not really saving you very much in the grand scheme of things.
Taking this together with the lack of flexibility and more complicated maintenance, it's almost always better just to write the GUI by hand.
I actually enjoy building GUIs with the NetBeans GUI Builder; the thing is, it is fairly customizable - it allows you to change the code used for auto-generation and the auto-generated code [no pun intended] (which is necessary for custom components), it also allows "easy" event-handling and binding. And NetBeans GUI Builder is not restricted to GroupLayout but rather allows you to choose which LayoutManager to use (a somewhat hidden setting in the form's properties dialog).
But it is not always the best choice; as others already said: MiG Layout is a good choice when you need to have full control of your application, knowing every single JLabel, every JButton etc.
I must confess I prefer Netbeans' GUI builder for the ease of use and WYSIWYG view.
But I also think that it does not even matter if you have created the GUI-Code by hand or with a GUI-Designer; adding Controls / custom Components dynamically works with both, doing this and that works with both etc.. The only thing that matters is that it works.
(From my point of view I do not see a point in coding a GUI manually if it can be done faster with a GUI-Builder, as I do not see why one should bother coding it by hand without some kind of benefit)
I use GUI builders to rapidly prototype designs and stuff like that. But when it comes down to building the actual production GUI, I code it from scratch. I'm not morally opposed to GUI builders, but I prefer the greater control over my code I get from writing it by hand.
Like any code generator tool, IMHO, you shouldn't use a GUI builder until you at least understand the concept - in this case, the Swing layout managers are particularly tricky.
If you give me the choice between NetBeans and by-Hand I'd definitely choose by-Hand. I was never really convinced by the NetBeans GUI builder's approach. At least the last time I used it, it relied on some proprietary sidecar files...
Look at Visual Editor for for Eclipse
You will still want to understand what the editor is doing for you.
You need to know how Swing works to be able to make things work properly. Nothing like building by hand to learn that :)
THEN the Netbeans GUI builder is rather nice.
Edit: I would strongly recommend going through the Java Tutorial Swing Trail - http://java.sun.com/docs/books/tutorial/ui/index.html
Both - use a WYSIWYG editor to get the ball rolling, but at the end of the day you'll need to manipulate your controls and in some cases create them programmatically at run time. Eclipse has a variety of free editors as plugins. Go to eclipse.org and look through the plugins listing.
Depends on your requirements. Some GUI building software work really well with simple applications, however, if your client requires many custom components the third party GUI builders may not work.
Also, it depends on the amount of forms and the complexity of them. If you need to build a form for each table in the database, for example, a third party GUI builder may be faster and cheaper.
In my experience, it really varies from project to project.
If you want a complex gui, then use something like netbeans to build it and create all of the events. If you're looking for a fairly simplistic gui, then building one by hand is still an option.
My company uses Netbeans for GUIs and eclipse for the regular programming.
We have looked but we haven't found any other (free or at least cheap) tool that does GUIs as good as NetBeans.
I used to write them from scratch with a plain text editor...
That depends what the reasons you're making the UI for,
I found that there are two reasons to make UI:
First is for clients, in these cases you want to UI to be polished and to handle really well in projects like this the core or essence of the project is the UI itself.In these cases it's usually the best to hand-craft the code for your UI because it's probably non-trivial code.
Second reason is usually quick & dirty UI where the core of the program is something else and the UI is created usually for Control aspects on your main application and you are the main client. In these cases the best thing to do is make the UI as quickly as possible as you don't want to "waste" time working on it and its more legitimate to use WYSIWYG editors.
I always find a GUI builder to be a good idea to begin with and then I end up in a situation where I am wasting my time fixing things to my own ways rather than that of the IDE and making them actually suit. And don't get me started on the messy code that GUI builders generate! Hence, it's often more efficient to build from scratch; at least for me...
I prefer hand coding the GUI myself so I can have complete control. For complex layouts I will use JGoodies Form Layout. Their syntax for specifying the layout makes it easy to draw the GUI on paper then transfer this to code.
I tried the Netbeans GUI builder and was impressed by how easy it was to use. Then I looked at the code it generated using GroupLayout and decided that by going that way you were basically locking yourself into Netbeans which was something I did not want to do.
I started by coding it manually using Swing. Now I use WYSIWYG editors, but I think it's important to know what's behind the editor. Also you might need to update the code manually, WYSIWYG editors often can't do exactly what you want.
Having created Java GUI's extensively, I can assure you the process is quite often painful. I'm well aware that Java's strength does not lie in it's GUI, but I'm surprised that a decent free interface builder tool hasn't been released.
Sometimes I'll use Eclipse's Visual Builder tool for quick and dirty mock-ups. It's code generation is a bit scary IMHO. I believe Netbean's Visual Editor is the best available at the moment (for free anyway); however, I find myself hand rolling GUI code for consistent cross-platform layouts. If your disapointed with these free GUI editors (like me), quite honestly, just use a layout library (like MIG) and just do it yourself. It'll be slow at first, but you'll have a lot more control and less editor newonses.
It really does depend on what you are trying to accomplish with the GUI. When I was tossing together ideas for a Computer Science class and testing functionality, the Netbeans WYSIWYG editor was great since it automatically generates a lot of the code for you. However, I found you tend to get better control with doing it by hand (in Java) than learning Netbeans.
I tried to use Eclipse's Visual Swing plugin, but on some occasions, the code it generated just disappeared, and I was left with a screen full of errors. In all the GUI apps I write, I use Netbeans, even though I hate the code generated when using GroupLayout. However, if layout code is not your concern, I think you'll be very pleased with the development speed it offers you. The only thing you'll have to do is implement the event logic and other logic you may require.
Eclipse's Visual Editor is a great choice, because the code that it generates is very straightforward and there's no hidden magic. Plus, you can make changes by hand and the editor will reflect them.
I test-drive the model of the UI, so that I have the functionality of the UI enclosed in a class that is completely decoupled from the GUI library and can be easily tested in isolation. Then I create a thin wrapper layer on top of the model, so that the GUI's event handlers are mostly one-liners that delegate to the UI model.
I've been using mostly IntelliJ IDEA's GUI builder (using the JGoodies Forms layout manager). It has been quite handly for laying out components in a static layout. But I think that for example with MiGLayout it's quite easy to write the GUI layout code by hand, so a GUI builder is not necessarily needed, and it helps to avoid tool lock-in. And dynamic layouts will anyways need to be written by hand.
But before writing any code, I first design and test a paper prototype of the UI, so as to have a clear vision of what needs to be done.
If you aim to create the final Java GUI, I recommand the Eclipse plugin named "Jigloo GUI Builder", which can generate clean and maintainable Java code.
If you just want to create the GUI quickly for review, you can try the UI prototyping tool like "ForeUI".
There's nothing wrong with using a GUI Designer when :
You understand what the IDE does and what it generates, how to customize the IDE output
You understand the code actually generated by IDE
Understanding at least the basics of Swing is important. Imagine the following scenario which happens just too often.
Q:"I have 10 years of experience writing swing applications"
A:ok
Q:How would you debug this code
A:Oh wait, there's no Netbeans form file??? You guys are not high tech!
Q:Hum.. you don't understand it?
A:Of course not, it's like machine code, you need to refractor it all and use an IDE!
I find that GUI builders can often complicate things and I'd rather know what was going on when the GUI was built than just use the variables created. I think because I don't know everything about Swing and layout managers as well, I am afraid to generate code that I have no conception of or don't know truly how it works.
When I was doing simple scripting using AutoIt that I knew would only be used on machines that had big enough screens I would use the GUI form editor. However, with commercial applications and those which may run on machines with any specifications I would generally shy away from GUI builders.
That said I think my decision may be influenced by my lack of knowledge regarding layout managers and maybe in the future I will start to embrace them more, as I can see nothing wrong with using them when you have a full understanding. Unlike some programmers may state, it is only a lazy way of building a GUI if you use the software with lazy intentions, and not for efficiently as the applications were written for.
To answer the original question directly, 99.5% of the time I will write the GUI from scratch!
After spending a lot of time and code on programming in Swing, I thought this can't be state-of-the-art Java GUI building. After not finding a user-friendly visual gui bilder for eclipse I stumbled upon declarative GUI building with XML UI toolkits... and I thought: This must be it! I think it's the right way to go, easy and also close to web-programming.
But after looking around in the web and on SO, I got the impression that it is not very common! Although there are many implementations and APIs, it seems like most of them are kind of dead and had no updates in the last 5 years..
So I wonder: Is my feeling right, that XML is not very widespread for java GUIs? And if so - what are the reasons? Maybe it couldn't become accepted or it has some major drawbacks or people are doing everything in the web instead with fatclients or there are better alternatives, maybe javafx?
I just need to know if it is worth spending time in that area or better look for alternate ways. As I dont read developer magazines I just don't know what the trends in gui building are and which technologies are believed to have a future. But I can't imagine that people still spend so much time on writing nasty swing (or swt) apps.
There new fresh and interesting approach - it uses YAML. Check it out at http://code.google.com/p/javabuilders/
Sun's answer to that seems to be JavaFX.
It has a declarative language for specifying the GUI and there will be builder apps as well.
There is some prototype work going on for e4 (Eclipse 4), which would allow building a GUI by editing an Ecore model and customizing it via CSS.
See this blog post for some details and instructions to try it out yourself.
Five to ten years ago XML was very popular. Although fine to provide some kind of standardisation for transferring data between heterogeneous systems, it's not suitable for programming. It always starts with the easy stuff, and lets declare everything. But any real system requires code. XML then falls down. There is also the problem that XML is a bad syntax for humans, and even languages like Java are easier to read.
On the other hand, there is clearly a need for the rails of GUIs. Naked Objects is the closest reasonable attempt I have seen.
I came to the same conclusions as you about the declarative frameworks out there. It is not worth learning a new GUI syntax unless it's widely supported. XUL as an interface language is widespread, but there is no java rendering framework for it. I'd say HTML+CSS+Javascript and a Servlet container is the best Java platform for GUIs today, but sadly I haven't found a platform independent way to display web pages like a desktop application.
If you use Eclipse, you can now use WindowBuilder to help you in creating Swing apps in a user-friendly visual GUI builder. It's now available as a free download, and Google has donated the Swing GUI builder framework to the Eclipse Foundation.
I'd second Thilos suggestion with javaFX.
Additionally the trend is pointing to webapps, so I think that in the long run javaFX and web based UIs will catch up to swing+swt GUIs.
I do all my swing stuff by hand and none of my application is nasty. If you do not know how to create usable and good looking UI there is no technology to help you.
The answer is surely not going to be XML. What problem are you trying to solve? You want to have reusable building blocks, and a compact way of describing them. I don't see XML helping you there.
[edit] Creating a java code equivalent of XUL would be an immense improvement on XUL.
XML makes it really, really hard to do good separation of concerns and once and only once. It is however perfect for the mongolian horde approach. You need a layer on top of swing, it only provides the building blocks.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Question for all the GWT gurus out there - which is the best GWT widgets library out there? And why?
List based on the answers:
Default
Sencha GXT
Smart GWT
Vaadin
GWT-Bootstrap
GwtBootstrap3
Rocket GWT (inactive)
Tatami (inactive)
ErraiFramework
GWTMaterialDesign
И наконец- новое поколение основанное на JsInterop:
GWT + Polymer Elements
GWT + Polymer
Angular and GWT
GWTMaterialDesign
Do not bind yourself to ANY of these libraries. Use Vanilla GWT to create the structure of your project. In particular, use the MVP pattern and an Event Bus. Please, see google article to know how to best design your client application with GWT: Building MVP apps
After, you can use any widget of these libraries (say a table, or a combobox, a datepicker, etc) and incorporate it to your project. Try to use extended components ONLY if you don't see a way to do it with vanilla GWT. This way you don't tie yourself to these libraries which are ALWAYS a pain when you try to do something that doesn't appear in the demo application, contain many bugs and their support are poor at best.
How to look for widgets should follow this order:
First check GWT Incubator to see if
there's what I'm looking for.
http://code.google.com/p/google-web-toolkit-incubator/
Then, if you are looking for
something "cooler" check GWT Mosaic
http://code.google.com/p/gwt-mosaic/
Careful with other libraries, I've worked with them (and still have nightmares).
Depends on what you mean by "best". Best looking? Best API? Best for extending to your own custom needs?
E.g., I was just evaluating table classes to use in our application. We've been using GWT-Ext, but it has many performance problems for us, and is very hard to get the tables sized the way we need them. I came very close to going with GWT-Mosaic, but decided instead to build off the widgets in the GWT Incubator.
So, why did I make this choice? It seems that too many of the libraries out there come with their own, for lack of a better word, baggage. Either you have to dive whole-hog into some MVC framework (which may not be entirely compatible with the rest of your code base), or you have to adopt someone's new fangled layout system, or you have to live with the fact that you cannot really debug the code (because its just JSNI wrappers).
Don't get me wrong, the GWT Incubator isn't perfect...the widgets there are in some amount of flux. In my case, this was the best choice, though. It gives me good (but definitely not perfect):
API
Extensibility
Look and feel (well, this is kinda weak, but that's what CSS is for.)
So...the answer (for me) is a combination of:
Stock GWT widgets (with lots of custom styling)
GWT Incubator tables
A few home-grown widgets
(I should add: the "baggage" I'm referring to isn't necessarily a bad thing. But, if you just want a widget or two, it can raise the bar on what it takes to just get your work done and how good youe application looks.)
See this component library GWT Bootstrap this is a implementation in gwt of Twitter Bootstrap.
GWT alone is a pretty good library.
I didn't use all of the mentioned ones but can recommend Ext GWT.
I prefer vanilla GWT.
Some of the other APIs look pretty and their showcases really show off the widgets, but I always find that the performance isn't the best....when I say performance I mean more like response time. I hate when an application feels sluggish.
Most of the libraries mentioned are not open source and even worse: are just wrappers on top of a JavaScript library. The power of GWT lies in the fact that the application works on different browsers (because of the code generation for the "big" browsers specifically). These JavaScript underlying libraries can cause lots of problems.
I agree with jgindin GWT Incubator and GWT Mosaic are the best so far.
Not saying it's "the best", but I've been using GWT-Ext at work lately. It's got some pros and cons:
Pros:
Relatively easy to setup and use
Decent sized community behind it
LOTS of examples online, all of which have accompanying code
Good selection of widgets that cover a wide range of functionality
Cons:
Makes assumptions about your data's format and structure that you may not be able to accommodate
Library is just a JSNI wrapper, which makes it harder to debug and extend
Future support and development on the library is uncertain
Some annoying cross-browser issues still exist (especially with layouts)
Search function on their forums is essentially useless. (This is becoming a big pet peeve of mine >_<)
Do NOT use any of them! If you plan to develop a large scale application, you should consider using MVP pattern. The best implementation around is MVP4G framework, it supports GWT code splitting out of box. There are a lot of great examples, you can start with. The most valuable one is Mvp4GModules.
Add the new one: GWT-Bootstrap :)
There isnt a stable release right now, but will have soon.
My experience shows that there are always many problems with 3rd party libraries. The best way - is to use well-known and well-maked technology itself plus your own components. It may take a longer time to write and maintain them, but TCO is always at lower level.
3rd party libraries often can break your plans unexpectedly. And it's hard to find and fix the source of problem.
So I'd suggest to use plain GWT.
I think SmartGWT is fine if you just whant to use the Widgets as they are,
but if you would like to extend or modify the widgets as I do in
the Gxt Scheduler I think that Ext-GWT is a better choice.
for me EXT-GWT (aka GXT) is the best library currently available,I use it in 6 months project,and it helps a lot with many predefined components like grids,trees....
It's beautiful as well
SmartGWT is a good library and it has a lot of examples but the user interface is not that sleek. For user interface Ext GWT is good.
gwt-mosaic's user group doesn't seem very active and I couldn't find a user's manual besides the wiki snippets. gwt-mosaic introduced me to two interesting tools.
1) gwt-mosaic includes a wrapper for Tibco's PageBus which is a publish/subscribe tool for the JS parts of your app (RPC handlers, widget callbacks, widget setters). This is an alternative to gwt's event bus.
2) gwt-mosaic encourages the use of Beans Binding (http://code.google.com/p/gwt-beans-binding/) for binding data to widgets and validating widgets.
smartgwt isn't cheap for the full feature set and support. The jar is too large for appengine unless you remove the theme files you don't use. They invest engineering on the server side too.
I've heard ext-gwt is sluggish and the JS files are large.
The gwt widget incubator looks deprecated. I believe the deluxe grid will be released with the new gwt.
The lack of look-and-feel, binding, and validation standards is hampering the interoperability of widget libraries.
Definitely not SmartGWT. Their framework is bloated and has a very half-baked nature. They have a million widgets, but trying to get them to work for your project is not easy. Datasources complicate the process of managing your data in a very big way, for example, in order to get to data in your datasource, you must use fecth and inspect often. While you can cache the results, it is not always easy to interrogate them.
RPC is another weak and convoluted area. There is contradicting information in the documentation and in the forums. While the documentation will say that you should rarely use a custom operation as part of a ds, they forum will tell you that it's perfectly fine. Learning to use these tools effectively is an uphill climb on the best of days.
They will oversell the product. For example, the charting/analytics package contains graphs... But those graphs won't display negative values or let you manipulate axis labels in any meaningful way. And they openly respond to queries about this on the forum with a "yeah so what" attitude. "We don't plan on adding that to 3.0x even though that's one of our selling points, it's on our road map." When they sold me the package, they never mentioned that I couldn't display negative values. Really? What graph would not need to be able to show negative values? I can think of only one- the one depicting the number of unhappy Isomorphic customers.
Stay away from these guys, and head over to any competitor's site, for example ExtJS, JQuery, heck even quxdoo. There are a few projects out there that are really gaining ground and actually offer a good solution.
Take great caution if you ever evaluate this product. It looks nice, but about two weeks in to the project using it, you'll start seeing what I mean. Widgets are half baked, datasources are extremely over complicated, and just because you paid for forum support, doesn't mean you'll actually get anything other than snide, condescending answers that at first will make you think you missed something. You didn't they're generally very arrogant.
Best of luck, and stay away from this product if you value your development time and maintainability. Oh and one last thing. Look at the MVC example on their web site. It has literally nothing to do with MVC other than the label reads "MVC". They'll try to convince you that such frameworks are for inexperienced developers, and that such a concept has no place in real programming... Kinda like those try catch blocks.
Google's default library is the most powerful library.
Ext GWT adds bells and whistles but apart from that it's similar to Google's.
We're currently liking the GWT Mosaic widgets. We've worked with ext-JS and we've rolled our own widgets in the past. ext-JS licensing and bulk were a problem for us. Rolling our own isn't what we want to do. Mosaic gives us a happy middle ground which we like to think will be an even happier middle ground as the project matures.
I would say if you need only a few widgets then build your own. You might copy-paste some concepts from the libraries mentioned. But they all lack one or the other thing.
I have played with most of them and abandoned every one.
One thing to be aware of is that from the forums GWT-Ext looks like it will no longer be developed/maintained much (maybe not at all?). On their website they recommend migrating to SmartGWT.
Didn't see this one mentioned, Vaadin (previously known is IT Mill Toolkit), but maybe that's because it's not technically exactly GWT; as their FAQ says:
How does this differ from GWT?
GWT applications run in the browser,
while Vaadin applications run on the
server. We do actually use GWT as a
"rendering engine" on the browser
side, so you can combine Vaadin and
GWT.
smartGWT is slow and examples are lacking and it is very hard to find answers for even the basic questions, i.e. see all my non answered questions on this forum.
I'm dumping smartgwt.
Comparison of the two EXTs here with pros and cons.
We have built a large HR portal and a couple of smaller applications using GWT Portlets. The focus of the project is not so much on building a collection of widgets but on creating a simple programming model.
From the website:
GWT Portlets is a free open source web framework for building GWT (Google Web Toolkit) applications. It defines a very simple & productive, yet powerful programming model to build good looking, modular GWT applications.
The programming model is somewhat similar to writing JSR168 portlets for a portal server (Liferay, JBoss Portal etc.). The "portal" is your application built using the GWT Portlets framework as a library. Application functionality is developed as loosely coupled Portlets each with an optional server side DataProvider.
I am using GWT for a year. After lots of research, I have decided GWT Mosaic as a widget library.. Mosaic uses some of the GWT incubator components such as PagingScrollTable.. But the features of the combobox and table are not sufficient for us.. That is why, we have extended these components to add needed functionality.
Check out SpiffyUI: www.spiffyui.org
It is not just a widget library but complex UI/UX GWT framework.
Two important things -and what the most of libraries miss- are unit testing and debugging. It is where GWT shines. If you use a library which is based on vanilla js, you give away the ability to unit test and debug your project. As a GWT developer you should consider these points and use a library with no or minimal js dependency.
We've been doing gwt projects for more than 2 years, and we stick to the default widgets. We made our own open source library to autopopulate the default ones or our own widget extensions. Please check it, it's called gwt-jet. It's very well tested since we use it in large production environments, and we hope it will grow safely thru time.