Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: gui
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      173

      Description

      The NB generated code is making modification way, way more complex than
      neccessary. There are a number of disadvantages to using it:

      (1) NB uses a special jar file for the layout manager which has a snapshot of
      the pre-release Mustang layout manager. UC is stuck forever into using this
      magic jar file.
      (2)The final Mustang layout manager is different from the one in the jar file.
      (3) NB will not allow you to use the Mustang layout manager
      (4) This GUI is ultra-simple. It would be very easy to use a different, old,
      layout manager and everything would look the same. And we would have complete
      control of the code
      (5) The NB layout manager and NB forms are useful for very complex GUIs – but
      they just get in the way for this GUI
      (6)NB forms are buggy. I developed an app using the forms (big mistake!). I
      eventually got into a situation where it was impossible to modify the form
      because of NB bugs. This was catastrophic. I had to gut all the NB-form stuff
      and redo it from scratch. It's a bad idea to depend on NB for handling the GUI
      with forms for commercial software.

      I am trying to add a TableSorter class in-between the existing table-model and
      the JTable view. That is already hard to do, but NB is making it incredibly
      difficult to do – maybe impossible.

      Summary: Using NB forms is bring very little to the party other than extra
      complexity and hassles.

        Activity

        Hide
        raccah added a comment -

        Downgrading to P3 as it does not affect the user and should not be required for
        beta.

        Anyway, I disagree, but am gathering ammunition to give a detailed response to
        each of your points =).

        Show
        raccah added a comment - Downgrading to P3 as it does not affect the user and should not be required for beta. Anyway, I disagree, but am gathering ammunition to give a detailed response to each of your points =).
        Hide
        Byron Nevins added a comment -

        While you are gathering up the ammo, I remembered the NB Form issue that I had:

        Change anything on the form
        The change is not reflected in the GUI. E.g. I add a button and no button
        appears. Or move something around – no change is reflected at runtime. The
        GUI is now mysteriously frozen to the last accepted change.

        I went through the NB forums and confirmed that other people had run into this
        problem. No solution was posted.

        Show
        Byron Nevins added a comment - While you are gathering up the ammo, I remembered the NB Form issue that I had: Change anything on the form The change is not reflected in the GUI. E.g. I add a button and no button appears. Or move something around – no change is reflected at runtime. The GUI is now mysteriously frozen to the last accepted change. I went through the NB forums and confirmed that other people had run into this problem. No solution was posted.
        Hide
        raccah added a comment -

        Here's my response from an expert on the NB team:

        (1) is not true. You can easily switch the layout code generation to standard
        JDK code for Java 6, even for existing forms that use the library. This is
        already in 5.5 - open the form and select the root node in Inspector, then see
        property "Layout generation style". So once you don't have to support 1.5, you
        can regenerate the forms to 1.6 and get rid of the swing-layout library.

        (2) is not accurate either. The layout manager in 1.6 is functionally equal to
        swing-layout 1.0.1. The GUI builder is able to generate the same GUI forms for
        both.

        (3) is the same as (1). There should be no serious problem in migrating, as I
        described.

        (4) is right in that ultra simple UI can be managed manually. OTOH simple UI is
        simple to do in GUI builder as well. The bugs in GUI builder have lower chance
        to cause you problems As for the complete control over code - this area is
        often exaggerated. Except the layout code, the GUI builder lets you do whatever
        you want. In most cases you don't need to customize or insert into the
        generated code, you can simply write your code after the initComponents() call
        in the constructor. You may consider initComponents() doing the rough work in
        the layout area, then do additional setup of the components as you need. (On
        other than Java platform you'd have the initComponents not as a code but some
        resource file which you would not want to modify either.)

        The true is though, that even if you can manually code whatever you want around
        the generated code or even inside it, for changing the generate part you need
        to use NB GUI builder (can't do it in other tools). That might be problem in
        open developer communities where everybody uses different tools. Strictly
        speaking, the only independent way of designing GUIs is then handcoding,
        because every GUI builder brings in some limitations...

        (5) I can't comment on this one, I haven't really try to build your UI. There
        are certainly types of layout that are not that suitable to be done in GU
        builder. Neither the GUI builder can avoid user mistakes and doing bad layout.
        But it seems mostly a matter of personal taste if the GUI builder is useful for
        you or not. I personally would use it always for UI that has more than 5
        components.

        (6) The bug that caused the form could get broken so it stopped regenerating
        code was in 5.0. It was a tricky one, if you had bad luck. It should be fixed
        in 5.5 though (i.e. the forms should not break this way anymore) and even
        automatically correct most of the broken forms. There are couple more fixes in
        6.0 in terms of recovery.

        As for adding the "TableSorter class in-between the existing table-model and
        the JTable view" - you don't set these things in GUI builder, it is some JTable
        setup you code manually regardless the rest of UI is created by GUI builder or
        not. I don't see how this is more difficult with GUI builder. Maybe I'm missing
        something.

        Show
        raccah added a comment - Here's my response from an expert on the NB team: (1) is not true. You can easily switch the layout code generation to standard JDK code for Java 6, even for existing forms that use the library. This is already in 5.5 - open the form and select the root node in Inspector, then see property "Layout generation style". So once you don't have to support 1.5, you can regenerate the forms to 1.6 and get rid of the swing-layout library. (2) is not accurate either. The layout manager in 1.6 is functionally equal to swing-layout 1.0.1. The GUI builder is able to generate the same GUI forms for both. (3) is the same as (1). There should be no serious problem in migrating, as I described. (4) is right in that ultra simple UI can be managed manually. OTOH simple UI is simple to do in GUI builder as well. The bugs in GUI builder have lower chance to cause you problems As for the complete control over code - this area is often exaggerated. Except the layout code, the GUI builder lets you do whatever you want. In most cases you don't need to customize or insert into the generated code, you can simply write your code after the initComponents() call in the constructor. You may consider initComponents() doing the rough work in the layout area, then do additional setup of the components as you need. (On other than Java platform you'd have the initComponents not as a code but some resource file which you would not want to modify either.) The true is though, that even if you can manually code whatever you want around the generated code or even inside it, for changing the generate part you need to use NB GUI builder (can't do it in other tools). That might be problem in open developer communities where everybody uses different tools. Strictly speaking, the only independent way of designing GUIs is then handcoding, because every GUI builder brings in some limitations... (5) I can't comment on this one, I haven't really try to build your UI. There are certainly types of layout that are not that suitable to be done in GU builder. Neither the GUI builder can avoid user mistakes and doing bad layout. But it seems mostly a matter of personal taste if the GUI builder is useful for you or not. I personally would use it always for UI that has more than 5 components. (6) The bug that caused the form could get broken so it stopped regenerating code was in 5.0. It was a tricky one, if you had bad luck. It should be fixed in 5.5 though (i.e. the forms should not break this way anymore) and even automatically correct most of the broken forms. There are couple more fixes in 6.0 in terms of recovery. As for adding the "TableSorter class in-between the existing table-model and the JTable view" - you don't set these things in GUI builder, it is some JTable setup you code manually regardless the rest of UI is created by GUI builder or not. I don't see how this is more difficult with GUI builder. Maybe I'm missing something.
        Hide
        raccah added a comment -

        closing

        Show
        raccah added a comment - closing

          People

          • Assignee:
            raccah
            Reporter:
            Byron Nevins
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: