Can I remove the view label area?

What you're actually referring to is creating your own ApplicationWindowFactory. That's the one that holds the statusbar, toolbar, menubar, ... and sets up the JFrame (so you can hide the title bar) Customizing that is actually quite easy. Take a look at DefaultApplicationWindowFactory, that's the one that you're probably using. If you create your own factory and put it into the context, SRCP will pick it up automatically. The dataeditor sample uses a different factory to get that taskpane menu on the left.
Almost all aspects of a Spring RCP application can be altered in one way or another.
About that time consumption: you're correct when creating simple apps. But what if your users come up with:
- we want security (button disabling) based on rights
- we want pretty colors for validation everywhere
- you're using a particular component for a type of field, we want another component to be used... everywhere
With Spring RCP, these are all 10 minute problems. With a plain Swing app... I'd like to see someone do that in 10 minutes :)

Thanks. I was reading up on the architecture/etc. yesterday and noticed the factories. I agree they could be used that way. Not that sure of the advantage with respect to productivity since you wind up writing the code anyway.

I actually wound up just removing the reference to any toolbars in the context.

What I am saying is that I am used to using other Spring projects where the components and configuration is a lot more bean oriented, where I can plugin different implementations or settings not just of factories, but of different beans or tweak the existing beans by setting a property on them.

My point can maybe be understood by looking at the getters/setters interface of beans in other projects and the interfaces of the classes in RCP - there are much fewer get/set methods in RCP classes, and often there are getters for a property but no setter. How can I set a property value on an RCP class if there is no setter?

Maybe I am misunderstanding how Spring works (I don't think so), but that always seemed to me to be one of the core concepts and advantages of Spring - i.e., the dependency injection. My impression is that RCP doesn't use that concept/advantage near as much as the other Spring projects.

I know this is not as easy with Swing as it is with other logic, but no one said it would be easy. If I have to evaluate Spring RCP v. using something like JIDE alone, then just saying that there is a lot built into the framework isn't going to convince me or others, since other frameworks have a lot built into them too (JIDE surely does). What attracts me to Spring RCP? The *potential* to use Spring IOC/dependency injection, but I am not seeing it here like I see it elsewhere in Spring.

Please, take this in the spirit intended: constructive feedback. I want Spring RCP to succeed and become all it can be. I want it to differentiate itself from other frameworks the way other Spring projects do - as a compelling offering of best practices as we know them.

Thanks for listening.

I agree completely.

Spring RCP isn't up to par when comparing it the the rest of the Spring Framework. But please bear in mind that up to this day, Spring RCP is still a self sponsored project with limited manpower. There are thing in Spring RCP that many of us like to see changed or augmented, but we simple lack the time.

That said, I think Spring RCP can easily hold up when comparing it to something like Jide. Hey, Spring RCP even has a JIDE integration subproject :). Its real strength lies in the fact that it takes a lot of the plumbing out of Swing app development, like security, validation, i18n, binding, ... with minimal effort whilst leveraging the strengths of the Spring Framework.

When you look at the current market, Spring RCP has only 2 competing frameworks: Netbeans RCP and Eclipse RCP. Jide has a nice framework, but let's face it, it's not even nearly as complete as these 3.

If you're planning on going to Devoxx, be sure to come to the Spring RCP BoF on Tuesday evening. I'd be happy to talk over a beer afterwards.

Thanks Lieven.

I had read a couple of other posts where the nature of the dev effort was explained and I can sympathize. I used to work almost solely on Swing apps which often made it difficult for me when it was time to find another gig since as you know 99% of Java dev is server side or if client side then a web client, not Swing. So I can understand that there just isn't much support for developing another Swing framework because few see the need.

I agree that Spring RCP has a lot of good to recommend, I am just asking that the dev effort should try to keep in mind the core Spring ideals of IOC/dependency injection when writing classes/interfaces.

I am tempted to join in and contribute, but I have enough personal dev projects on my short list already, and almost all of them entail server side logic and maybe some web client work (probably GWT). Actually server side code is mostly simpler and easier than client code. I am concentrating on SQL more than Java - or at least I need to concentrate there more.

I learned my lesson in the employment marketplace and the last year or so I have been doing almost solely server side/web client work and haven't touched Swing for a while until now. Maybe my current employer will want more Swing apps and I can maybe find some way to contribute then - we'll see.

I'm in the same situation, but I'm not giving up on promoting rich clients. The web guys may have a louder voice, we'll see who has the last laugh when demo time arrives and all the demo computer has installed is Mozilla because that's the company's standard :).

Oh I will always advocate for thick rich clients in certain applications. The right tool for the right job. Web clients have a *LONG* ways to go to even begin to compare to rich clients, especially cross platform clients like Swing.

However, these arguments often fall on deaf ears and given time web clients will slowly catch up in ability - although I bet by that time they will be almost as thick as something like Swing which was there all along. I could go on and on, but it isn't necessary - I would be preaching to the choir.

I like GWT because it feels like Swing, I can write the client and server code almost completely in Java and I can debug in Java. There are some times when I can't. More annoying is that GWT still doesn't completely address all of the issues of browser compatibility, but I think it does the best job of the frameworks I have looked at, and it is *almost* pure Java.

I've said in the past that web clients are one of the reasons why a lot of projects either seriously go over their initial budget, or fail altogether. Web frameworks are great from a deployment point of view, which is one of the main selling points of webapps (management loves to hear instant deployment and updates). However, deployment is only a mere fraction of the effort involved in a project. When choosing a tech, managers should start by looking at what users they'll be serving AND what they might be asking in terms of usability, functionality and interactivity (all those -ty words, it's almost buzzword bingo). How many times are users confronted with a web application that doesn't really hold up to their expectations 'because what they asked wasn't possible in a webapp'?
I'm not a real fan of GWT, although I must agree that it has more affinity towards traditional rich client development. But then again, GWT is only a babystep away from full rich client applications.