Can I remove the view label area?

[khuxtable]

I am developing an application that will have one top-level window for each document being viewed. There will also be search results and other windows, but I don't see them as being switched within a top-level window.

That being the case, I'd rather not take up the vertical real estate with the view label and migrate that information into the title bar, much as web browsers, word processors, and similar applications do.

Is this possible? If so how?

Any information would be appreciated.

BTW, I'm migrating from Spring RCP 0.2.0 to 1.0.0.

-K

[khuxtable]

Okay, I figured it out. I have to set a new PageComponentPaneFactory in the applicationServices bean. This new factory creates a new PageComponentPane type. This new type creates something other than SimpleInternalFrame that handles the view label differently.

Thanks,

-K

[Developer Dude]

If I understand what you are doing or have done or needed, I think I need the same thing or something similar.

I have a very simple app we are using to start our migration from an old VB UI (which I know almost nothing about) to Java Swing. When a certain command is invoked in the VB app we are going to call this Swing app which has one window with three large buttons (eventually maybe for touch screen), each of which invokes dialogs (which I had to really dumb down).

This main window has two menus - 'File/exit' and 'Help/about'. The main content view with three buttons, is stationary and opened on startup. You can't close that view. You do your work then close the app.

I have it sufficiently dumbed down, but I don't want a title bar on the main view (the three button view).

I don't see a simple way to do this. I should not have override a lot methods, or implement a new factory, I should be able to say that I don't want a title/caption bar, or a border/frame, or whatever.

Is there a better simpler more straight forward way?

In Swing you would just use a different component.


~~~~~~~~~~~~~~~~~~~~~

This is one of my disappointments with this framework; it handles the 80 percent use cases where you are doing standard stuff, but if you do something slightly non-standard it becomes a pain because of the assumptions made.

[khuxtable]

True. I had to override about three classes.

I have abandoned Spring Rich Client for my current project because it does too many things its own way. I no longer have the code handy, though I could dig it out of Subversion if you'd like. It wasn't that hard and once done it stayed done.

-K

[Developer Dude]

What I found by accident was that if I set the string for the caption to be an empty string, then the caption/title bar was so thin it was almost unnoticeable, which is good enough for now. I noticed that if I left the message property blank then in the resources then SRCP assigned its own default - which is also bad practice. Along with 'ApplicationDialog' for the title bar for dialogs. This is kind of like the Swing practice of supplying a default table model populated with colors (or is it fruit? I forget) - although I think Sun may have stopped doing that.

I think there is a property I can set to do this, but for now I just overrode getDisplayName() in the view.

I am not ready to abandon SRCP but I am disinclined to use the built-in components. Either try using JIDE, or write my own hierarchy of component classes that are more bean oriented and configurable like the rest of Spring but use the RCP framework (yeah, right, in my copious spare time ;-) ). I am not saying it would be easy to do this, and I am not belittling the work done so far, I am just saying it is a real problem.

I like a lot of what I see, but as I said the assumptions in the components supplied get in the way if you are doing anything out of the ordinary.

If you are doing a Plain Jane data processing app and stick with normal windows, dialogs and such, then you will be okay - but I have yet to work on any app where some PM or user or domain expert didn't come along and want something that takes you down a different path, and then it becomes painful.

[Developer Dude]

For example, if View (or ViewDescriptor) were more bean oriented, instead of overriding getDisplayName(), I would just do this:

<bean id="MainButtonView" class="org.springframework.richclient.application.support.DefaultViewDescriptor">
     <property name="viewClass" value="binker.MainButtonView" />
     <property name="displayName" value="Some text here" />
   </bean>

Or I would create the view bean and refer to that as a ref in the bean above, or something. But since there is no setter for 'displayName' in the bean or the descriptor, I can't do that. Maybe there is some property in the descriptor view properties map? But unless the 'beans' (I hesitate to call them that) are immutable (which they are not), why provide a getter but no setter for each property?

Of course, in this case you have to take into account localization, but I am talking about properties overall, not just displayed strings.

[khuxtable]

It wasn't *that* hard to figure out what to override to remove the title pane.

That said, one of the main problems with SRC is that the documentation is so rudimentary.

[Developer Dude]

It wasn't *that* hard to figure out what to override to remove the title pane.

That said, one of the main problems with SRC is that the documentation is so rudimentary.

My point is that overriding a method like that on a bean is not very Spring like. I am used to going into an XML file and tweaking some config or property setting to get what I want, or providing a reference to an alternative implementation.

The overriding a method to tweak some minor behavior, like whether a title bar is present, or its contents, should be something done with IOC, not code.

[LievenDoclo]

Are you referring to changing the title of the view? If that is the case, you only need to set the id of the view descriptor (which is a simple property) and put <view id>.title=Something in your messages file.

[Developer Dude]

Are you referring to changing the title of the view? If that is the case, you only need to set the id of the view descriptor (which is a simple property) and put <view id>.title=Something in your messages file.

No, if you are talking about the original problem, not my rantings, we wanted remove the title bar altogether to there was no vertical real estate taken up by it. I cheated and made the title bar minimal (just a thin band) by using "" as the title.

As I said, SRCP covers the 80 percent cases of Swing apps where you have a menu bar, a tool bar and some windows in the work area of main app framed window. That is good and helpful.

But when you need to do something outside that box (or in my case, less of the "box"), say something with no tool bar, maybe even no menus, no titled windows, but want to use the rest of the app framework, you start bumping into these problems of workarounds to get past the assumptions built into the framework. I actually would have gotten my app written in about one-fifth the time if I had just stuck to a plain Swing app - but I wanted to learn the framework too, so...