Announcement Announcement Module
Collapse
No announcement yet.
Can I remove the view label area? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Can I remove the view label area?

    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

  • #2
    Got it

    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

    Comment


    • #3
      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.

      Comment


      • #4
        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

        Comment


        • #5
          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.

          Comment


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

            Code:
            <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.

            Comment


            • #7
              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.

              Comment


              • #8
                Originally posted by khuxtable View Post
                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.

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    Originally posted by LievenDoclo View Post
                    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...

                    Comment


                    • #11
                      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
                      Last edited by LievenDoclo; Sep 23rd, 2009, 06:50 AM.

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            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.

                            Comment


                            • #15
                              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 .

                              Comment

                              Working...
                              X