1 2 Previous Next 23 Replies Latest reply: Oct 29, 2009 11:05 PM by 793415 RSS

    setLayout(null) is never necessary.  Ever!

    793415
      I'm sick of hearing experienced GUI programmers who occasionally write WTE.
      "Well, if you know where the components go, a 'null' layout might be the best solution."

      I argue that setLayout(null) is never necessary, ever, along the following lines

      1) Custom rendering, overiding paint() or paintComponent(). Who cares what the layout is? It is irrelevant. Paint every pixel and be done with it.

      2) A layout that does not exist in the standard API such as a 'wherever I drag (and drop) the component' layout or a 'scroll the components continuously' layout. Hey, if you are clever enough to figure the exact positioning of components across different..
      - Screen sizes
      - Screen resolutions
      - PLAFs
      - JRE versions (and/or tweaks to PLAFs between versions).
      - OS'
      - etc.
      Then damn it, put the logic into a layout manager purely for the encapsulation, and it is again not necessary to setLayout(null) anywhere (AFAIU).

      +Can anybody prove me wrong, or argue a convincing case to the contrary?+
        • 1. Re: setLayout(null) is never necessary.  Ever!
          843807
          AndrewThompson64 wrote:
          I argue that setLayout(null) is never necessary, ever, along the following lines
          Absolute statements are never always correct. {color:lightgray}(Sorry, I had to say that){color}
          • 2. Re: setLayout(null) is never necessary.  Ever!
            793415
            Encephalopathic wrote:
            AndrewThompson64 wrote:
            I argue that setLayout(null) is never necessary, ever, along the following lines
            Absolute statements are never always correct. {color:lightgray}(Sorry, I had to say that){color}
            Keep that up and I'll award you some Duke stars. Don't be fooled, I have Dukes and I'm not afraid to use them.

            ( And no apologies for using the 'dreaded term'. ;)
            • 3. Re: setLayout(null) is never necessary.  Ever!
              843807
              I am not an expert, but I consider using 'null' layout is better than doing custom painting...
              1) Custom rendering, overiding paint() or paintComponent(). Who cares what the layout is? It is irrelevant. Paint every pixel and be done with it.
              e.g. for case of 'drag drop' kind of layout, I think using 'null' layout is better than using custom rendering because for drag and drop we require mouse event handling and it is easier to add event handling to individual components rather then handling events in the container which is custom painted (i.e. we have to search for which custom painted component that event was meant for...). So my point is, for an interactive GUI it is better to use built in event handling mechanism etc. of the swing components (which can be done using null layout) rather than doing custom painting and handling events ourselves.

              Thanks!
              • 4. Re: setLayout(null) is never necessary.  Ever!
                843807
                I've found occasion to use a null layout to solve a problem posted here.
                [http://forums.sun.com/thread.jspa?threadID=5278235]

                Like to take a stab at achieving that layout with one of the standard JDK layout managers, Andrew? OverlayLayout comes to mind, but it isn't in the tutorials and I haven't ever been able to fathom exactly what should be passed as "Object constraints" to its addLayoutComponent. It would be edifying to find it can be done.

                Oh, and don't bother to Duke this account ;-)

                db
                • 5. Re: setLayout(null) is never necessary.  Ever!
                  jduprez
                  +Can anybody prove me wrong, or argue a convincing case to the contrary?+
                  I probably can't prove you wrong, too bad (well, those forums would be so boring without some dissent here and there).
                  However I'm interested to read you elaborating on the following true situations (true stories):

                  1) please have a look at [this thread|http://forums.sun.com/thread.jspa?threadID=5388984] . A custom container class currently implements absolute positioning (null layout) of its children widgets along a time line, according to time and duration properties of the children widgets. The same logic might certainly be implemented as a custom LayoutManager (I haven't taken this endeavour yet), but this latter would need to either:
                  - know about (cast) the specific children widget's classes to extract their time/duration properties.
                  - support specific constraints to hold these time/duration properties, which as one of the poster suggested, might be over-engineering an otherwise simple positioning rule (+x = duration x nbPixelsPerHour+).

                  2) fixed-size window on a dedicated appliance with no resizing feature, and dedicated areas with fixed proportions (side menu, center area, status bar). The equivalent custom layout manager is obviously very simple to implement, but what would it bring compared to a custom container code exposing setSideMenu(JComponent), setStatusbar(JComponent),...)?
                  • 6. Re: setLayout(null) is never necessary.  Ever!
                    jduprez
                    I understand that you would reward convincing or balanced arguments against your claim. But if you happened to be right, and noone argued against it, what would you do with the dukes? :o)
                    • 7. Re: setLayout(null) is never necessary.  Ever!
                      843807
                      4 cases I could think of:

                      1. You want draggable + resizeable components. See tjacobs.ui.drag.Draggable (http://tus.svn.sourceforge.net)
                      2. Panel in a (J)ScrollPane of fixed size, filled with components at fixed positions
                      3. You have non-rectangular components. This isn't actually possible, given the specification for Component, but in an implementation where it was possible (tjacobs.ui.shape is an attempt at something like this - promoting shapes to first class / component-like objects) the requirements for designing a generic layoutmanager would be very high
                      4. Fully and partially overlapping components, translucency. You could build a layoutmanager to do this, but could you build one generic enough to be useful as a standalone?
                      • 8. Re: setLayout(null) is never necessary.  Ever!
                        camickr
                        Of course there is always more than one way to solve a problem and you could probably find a solution that gets around using a null layout, but I fail to see why you would want to do this. In the proper context a null layout is a perfectly valid solution.

                        Simple JDK example would be JDesktopPane / JInternalFrame interaction.

                        I agree completely, that newbies tend to use null layout because they percieve them as easier to use than spending time learning how to use layout managers, but that is not a reason to ban the existence of null layouts.
                        • 9. Re: setLayout(null) is never necessary.  Ever!
                          Kleopatra
                          What an unexpected fun thread on a dreary Monday :-) Naturally, I can't resist jumping into it ...
                          camickr wrote:

                          Simple JDK example would be JDesktopPane / JInternalFrame interaction.
                          which is very far from ideal, due to the fact that the core swing team developers didn't take into account all of the bullets Andrew listed under item 2)

                          From me it's a clear "no no never ever" for null layout (exceptions proof the rule, of course :-) - my advice always is to put all the brains and all the combined experiences into finding a solution with a LayoutManager. And only as a very very very last option fallback to null - but mark as dirty/pending/tobedone to remind everybody that it's a hack.

                          Cheers
                          Jeanette
                          • 10. Re: setLayout(null) is never necessary.  Ever!
                            Kleopatra
                            wont get me any dukes (not much interested, because they are male :-) - I have nothing but a onehundredthousandbillion ACK!

                            Cheers
                            Jeanette
                            • 11. Re: setLayout(null) is never necessary.  Ever!
                              Kleopatra
                              tjacobs01 wrote:
                              4 cases I could think of:

                              1. You want draggable + resizeable components. See tjacobs.ui.drag.Draggable (http://tus.svn.sourceforge.net)
                              don't know your code, so could well be off-mark - but: even when dragging components around or resizing them, re-arranging the sister components will be necessary at one point in time. Definitely would opt for an intelligent enough layoutManager.
                              2. Panel in a (J)ScrollPane of fixed size, filled with components at fixed positions
                              "fixed" in which units? pixel, dlg, pt, mm, relative to each other? In my experience, there is no single unit that's applicable always. So better have a LayoutManager which is aware of that and handles all the nitty-gritty details on conversion.

                              can't say anything at 3) - so snipping ..
                              4. Fully and partially overlapping components, translucency. You could build a layoutmanager to do this, but could you build one generic enough to be useful as a standalone?
                              sure, and most probably there are already implementations which can cope with it. The alternative is to cope with all the dirty details (Andrew's item 2) in every concrete context again and again ..

                              CU
                              Jeanette
                              • 12. Re: setLayout(null) is never necessary.  Ever!
                                camickr
                                Kleopatra wrote:
                                camickr wrote:

                                Simple JDK example would be JDesktopPane / JInternalFrame interaction.
                                which is very far from ideal, due to the fact that the core swing team developers didn't take into account all of the bullets Andrew listed under item 2)
                                I guess I don't understand how you can "program randomness". Once you give the user the ability to move components in a random fashion, "how does that become a layout"?
                                • 13. Re: setLayout(null) is never necessary.  Ever!
                                  Kleopatra
                                  Darryl.Burke wrote:
                                  I've found occasion to use a null layout to solve a problem posted here.
                                  [http://forums.sun.com/thread.jspa?threadID=5278235]
                                  you seem to have too much time at hand, if you really suggest doing something similar with an arbitrarily complex container <g> Besides, in that particular case, I would have more than one question about what's really needed.

                                  CU
                                  Jeanette
                                  • 14. Re: setLayout(null) is never necessary.  Ever!
                                    DarrylBurke
                                    Kleopatra wrote:
                                    wont get me any dukes (not much interested, because they are male :-)
                                    [http://jduchess.org/wp-content/themes/nordljus/images/javaduchess3.png]

                                    ;-)
                                    1 2 Previous Next