Nested GridBagLayout and its pitfals

Discussion in 'Java' started by nukleus, Feb 8, 2007.

  1. nukleus

    nukleus Guest

    I am working on one app that has few frames
    to get/set various program parameters.

    Some of those frames have several buttons,
    several text fields with labels, several checkboxes,
    a text area and, status field and a choice boxes.

    To make it all look nice and clear from the standpoint
    of GUI element layout, you would have to get into
    some pretty hairy issues.

    Working with it, what I was seeing is nothing less
    than magic. Buttons would dissapear in run time,
    text fields would have Y size several times smaller
    than the font Y size and on and on an on.
    I could not believe my eyes seeing all that madness,
    and I ended up spending probably 10 times more time
    on it all, than it should have taken me, or any
    mortal for that matter.

    I decided to use my gadget and review the 25000
    article archive of this group, going back at least
    half a year, and see if this issue was ever discussed.
    The result was nothing but shock. There were but a
    handful of articles, most in Sept. 2006, addressing
    this issue, and even there, the advices were so
    scetchy, that they wre virtually useless,
    in case of just about any realistic frame imaginable
    having more than a few similar GUI elements.

    So, let us attempt to fix that problem
    and put an end to the whole grdibag debate.

    I was recomended by one of people here to read the
    Sun's tutorial on GridBagLayout. Yes, I agree, it
    is humanly readable, but, unfortunately, the example
    it provides is nothing more than a childish invention,
    and there is very little chance it is going to be of
    any use to you. It does not address ANY of subtleties
    of realistic layouts, having not just a bunch of buttons,
    filling the entire frame, but a mix of various GUI
    elements.

    Finally, what i came up with, was a realization
    that about the easiest and the best way of doing it,
    was to use nested layout.

    Here is the summary of what I have found.
    It is all out of memory as I do not want to load
    another piece of bloatware and wait for days
    when I want to switch some tab.

    1. In just about any realistic GUI frame,
    you are likely to have a mix of various elements.
    If you try to lay them all out using a single
    GridBagLayout, you'll waste half of your life,
    being blown out of the chair when you change
    any parameters.

    You may try to cheat and create more grid cells,
    trying to properly position various unrelated
    groups of elements, setting trying to make one
    GUI element to occupy more than one cell in X or
    Y dimension, trying to accomodate for your
    positioning requirements, but it will likely
    to und up in nothing less than utter frustration.

    So, use nested layout instead.
    Meaning: Organize all of your similar GUI
    elements into logically related areas on your
    frame. Group buttons in one group, labels and
    text fields in another group, and so the checkboxes,
    text areas and the rest of it.

    2. Create separate panels for each of those groups,
    where you put related items.

    Use GridBagLayout for each of those panels.
    For the group of checkboxes, GridBagLayout is not
    the best choice as it does not guarantee the equal
    Y offsets between the checkboxes.

    So, for check box panel, use GridLayout instead
    as it will guarantee the equal X size distribution
    between all the checkboxes.

    Use GridBagLayout for the frame itself, and put
    all those panels into separate cells of the frame
    GridBagLayout.

    3. Avoid using fills as much as possible,
    as their effect may be such that you'll never have
    a handle on your layout. Say, for example, you have
    a group of labels, in Y dimension, that label the
    corresponding text fields. The entire row of labels
    will be dimensioned at run time to have an X size
    of the label having the longest text string.
    If you use fills to pad the label column size,
    and, later on, decide to change the text of your
    longest label and make it much smaller, all of a
    sudden, your whole layout will change.

    Fills are not the absolute size of some GUI element.
    They are what needs to be added to the size of a
    text string, that element contains, be it label,
    button, text field. That is why their are called
    paddings, which should immediately turn the warning
    lights on.

    That means that if you use fills hoping to minimize
    the size of some row or a column, you'll be sweating
    half of your life to make it work, especially if you
    try to resize that frame in run time.

    Use insets instead. Those are guaranteed not to change
    regardless of the size of your GUI element.

    4. Try to keep all the values of constraints structure
    at zero instead of filling them with values you THINK
    will make it look better. Use only those parameters
    that you feel are absolutely necessary, such as insets.

    The exception is the row/column numbers and a number
    of cells you want your GUI element to occupy in X or Y
    dimension.

    5. On all labels, use a small X padding of 3 - 6 pixels
    for the labels so that the text field, following that
    label in X position have some margin and does not run
    into the end of the label string.

    6. Try not to use fills for any of constraints structures
    for each of your GUI elements, unless it is absolutely
    necessary in such cases as the length of text field
    in X dimension to make sure your field occupies as
    much of X dimension of your frame, as possible.
    Fills are only applicable to the cases where you resize
    frame to make it BIGGER than what you designed with you
    GUI designer, or you set the initial size of your frame
    bigger than what you saw with your GUI designer.

    For example, using fills on your text fields in Y dimension,
    will increase the Y margin betwee the different label/text
    fields in a group, which is not what you would want to do
    in most cases. You would probably want them to stay equally
    positioned regardless of the size of your frame
    and to be guaranteed their minimum size as limited by the
    font you are using and the lengths of your string.

    7. Try to make your frame resizable and resize it in
    run time. If all the GUI elements and groups keep sain
    proportions, it means you've got all your constrains
    and structure of your nested layout correctly configured.

    8. If you use a GUI designer, and it generates Java code
    for your constraints, panels, etc., do not modify that
    code by hand. You'll waste half of your life if you
    ever need to change your layout in the future, which
    is pretty much inevitable.

    The same exact code as generated by the GUI designer
    should work like a champ in just about ANY situation
    imaginable.

    Forget about the minimum and preferred sizes.
    They are virtually useless. If you do your
    design correctly, you'll have the absolute
    minimum of variour parameters to be set
    as far as boundaries, sizes, etc.,
    behaving the in the most predictable way
    possible under the Sun.

    9. Separate your GUI related code for the frame
    and do not add anything to that class beyond
    get/set methods for each element.

    Make a superclass that extends that frame and that
    is where you can add the keyboard and mouse listeners,
    and all the bells and whistes to your frame. That
    superclass has access to its underlying frame's
    variables and has right to do anything it pleases
    with those variable, even though it should not attempt
    to modify the sizes, constraints etc. It all has
    to be done by the code generated by your GUI designer.

    10. Try not to use some proprietary layout managers
    because they are not guaranteed to work with the
    future versions, unless they rely on the existing
    basic layouts, which you can do yourself.

    Futhermore, they'll end up doing the same thing
    the gridbag does, and, if you are trying to be lazy,
    hoping to save some time or effort, you are likely
    to regret at the end, it is all just a matter of time.

    Some claim that by using some proprietary
    layouts, they can save half the amount of code lines,
    which is about the funniest argument possible.

    Your frame look and feel is about one of the most
    important aspects of your entire application.
    Just about ALL the users will see with your app
    is those very frames. Trying to save a few hundred
    bytes or code lines is simply foolish.

    11. Spend enough time on making sure your frame
    behaves in a very predictable way regardless of
    its size. All the GUI elemenents have to look
    consistent and corresponding margins should not
    change when frame is resized.

    If that is the case, it implies that all your
    constraints and the entire logical structure
    of your frame are correct.

    12. Try not to use weights, if at all possible.
    If your frame has several groups of GUI elements,
    each having several elements, then what you think
    is space distribution may end up being utterly
    different in run time and you'll waste hours if
    not days, trying to play with those weights.

    Even if you use weights with such elements as
    buttons, you may be unpleasantly suprised at
    how it looks during the render time, especially
    when you resize your frame.

    Weights refer to relative distribution of space,
    within the group of gui elements, they call
    "display area" - ugggghhhh,
    and not the frame as such.
    So, if you only have one group of elements
    in your frame, weights may work fine,
    but, as in any realistically complex frame,
    where you have more than one row/column of
    your main gridbag, the things may and WILL
    become simply bizzare. You'll sooner go nuts
    than get the results you expect from all that
    mess. By changing any element in a different
    group of elements, the whole frame may look
    utterly ugly, as those weights only affect
    the elements in a group.

    Even to use weights for each cell of the maing
    gridbag of your frame, hoping that relationship
    between groups will remain consistent, you may
    be very unpleasantly surprised with the results
    while resizing that frame or adding/removing
    some elements.

    Weights is probably close to useless if you consider
    all the remifications of using them in a relatively
    complex frames.

    Summary:

    Instead of using a single GridLayout on just about
    any realistically complex frame, that has several
    different types of GUI elements, group the related
    elements and put them into separate panels.

    Select the layout for each panel that suits your
    frame design concepts in the easiest and most
    natural way. Do not try to make things more complex
    than necessary as about ALL you are going to get
    at the end is a royal grade pain on the neck.
    It won't work. Trust me.

    Try to use GridLayout for all those panels
    whenever possible as this is the most general
    purpose layout having all the power to do just
    about anyting imaginable. But it has its limitations
    and unpredictability of behavior if you expect
    some rows or columns to be of equal size
    regarless of the label, text field or button text
    string sizes.

    GridLayout is not a good choice for that because the
    column size relationships may change in run time and
    your columns will end up of not equal size, and,
    trying to make them of equal size, by using paddings
    or weights, could end up being a pain on the neck
    and of a grand proportions.

    Use as few parameters in your constraints structure
    as possible.

    By using nested gridbags, your design will end up
    being the simpliest possible with WAY more predictable
    results, having the smallest amount of various cells
    possible, and with the smallest amount of various
    constraint parameters, which will eventually translate
    into the most stable, predictable and flexible run
    time behavior and having the minimum amount of
    maintenance efforts of your code.

    If you follow these few simple advises,
    you'll be amazed at how much power and flexibility
    you can achieve with nested GridLayout.

    Good luck.

    Finally, if any experts around have any comments,
    it would probably be a good idea to clarify some
    more subtle points and issues, or correct some
    errors or philosophical fine points as this information
    will become a permanent reference on this issue
    and will be available through argives for generations
    to come.

    Simmply sending people to read some Sun "tutorial",
    you are effectively sending them to hell,
    as those "tutorials" cover only the most primitive
    and most basic concepts having virtually nothing
    to do with a realistic application.

    Instead, you can spend half an hour of your time
    and spill out the fine points of this most important
    thing there is in the entire concept of GUI design,
    GridLayout, which all would have to learn eventually
    no matter what.
    nukleus, Feb 8, 2007
    #1
    1. Advertising

  2. "nukleus" <> wrote in message
    news:eqfboa$1llq$...
    > Use GridBagLayout for each of those panels.
    > For the group of checkboxes, GridBagLayout is not
    > the best choice as it does not guarantee the equal
    > Y offsets between the checkboxes.


    I'm not sure what you mean by this. Of course
    you can get equal y offsets or y spacing. Maybe
    you meant "X" here?

    > So, for check box panel, use GridLayout instead
    > as it will guarantee the equal X size distribution
    > between all the checkboxes.


    If you have some checkboxes with long labels
    and some with short labels, you may not want
    equal spacing in X.

    > 4. Try to keep all the values of constraints structure
    > at zero instead of filling them with values you THINK
    > will make it look better. Use only those parameters
    > that you feel are absolutely necessary, such as insets.
    >
    > The exception is the row/column numbers and a number
    > of cells you want your GUI element to occupy in X or Y
    > dimension.


    I think for most layouts it's better to place components
    left-to-right and top to bottom using gridwidth=REMAINDER
    to end a "line". The layout is easier to modify that way.

    > Forget about the minimum and preferred sizes.
    > They are virtually useless. If you do your
    > design correctly, you'll have the absolute
    > minimum of variour parameters to be set
    > as far as boundaries, sizes, etc.,
    > behaving the in the most predictable way
    > possible under the Sun.


    Sometimes you need certain components to be
    shrinkable to zero size to get the effect you want,
    so setting a zero preferred and minimum size of
    zero in one or both directions is useful.

    > Some claim that by using some proprietary
    > layouts, they can save half the amount of code lines,
    > which is about the funniest argument possible.


    By wrapping GridBagLayout in a helper class that
    does the common things I need, I probably save
    75% of the size of the gui part of the source code,
    and a lot of space in the class file as well. It also
    keeps my layouts consistent by enforcing common
    spacings, etc. Most of my GridBagLayout code
    uses one line of code for each component added,
    and that is a method call with two parameters.
    For example (part of one layout):

    panel.addLabel("Color", GBLPanel.ANCHOR_EAST |
    GBLPanel.FLUSH_BOTTOM);
    panel.add(color_setter, GBLPanel.ANCHOR_WEST |
    GBLPanel.HOG_WIDTH | GBLPanel.FILL_HORIZONTAL |
    GBLPanel.FLUSH_ALL);

    If you are doing a large amount of gui code using
    GridBagLayout, creating such a helper class is
    well worth the effort.

    > 12. Try not to use weights, if at all possible.
    > If your frame has several groups of GUI elements,
    > each having several elements, then what you think
    > is space distribution may end up being utterly
    > different in run time and you'll waste hours if
    > not days, trying to play with those weights.


    Having zero weights can cause strange effects.
    Always use weights, but choose from a limited set.
    Normally you have some group of components
    that together should use all of the extra height or
    width (text fields, text areas, sliders, editable combo
    boxes, lists, etc.) and others that should have a
    fixed size (labels, buttons, etc), and you can get by
    with always using a weight of either 1000000 or
    ..000001.

    > Use as few parameters in your constraints structure
    > as possible.


    Use mostly consistent parameters, and few choices
    for weights and spacings.

    GridBagLayout does not play well below preferred
    size. Consider only using it within a scrolled pane
    or a window that is not shrinkable below preferred
    size.

    Creating your own layout manager is much simpler
    that you think. For some reason people will spend five
    hours fiddling with GridBagLayout or SpringLayout
    trying to get it to do something it wasn't meant to do,
    when they could write a custom layout manager in
    under an hour.
    Larry Barowski, Feb 8, 2007
    #2
    1. Advertising

  3. nukleus

    nukleus Guest

    In article <>, "Larry Barowski"
    <MElarrybar-AT-eng_DOT_auburnANOTHERDOTeduEND> wrote:
    >
    >"nukleus" <> wrote in message
    >news:eqfboa$1llq$...
    >> Use GridBagLayout for each of those panels.
    >> For the group of checkboxes, GridBagLayout is not
    >> the best choice as it does not guarantee the equal
    >> Y offsets between the checkboxes.

    >
    >I'm not sure what you mean by this. Of course
    >you can get equal y offsets or y spacing. Maybe
    >you meant "X" here?


    Yep.

    >> So, for check box panel, use GridLayout instead
    >> as it will guarantee the equal X size distribution
    >> between all the checkboxes.


    >If you have some checkboxes with long labels
    >and some with short labels, you may not want
    >equal spacing in X.


    Well, than this issue does not apply to your situation.

    >> 4. Try to keep all the values of constraints structure
    >> at zero instead of filling them with values you THINK
    >> will make it look better. Use only those parameters
    >> that you feel are absolutely necessary, such as insets.
    >>
    >> The exception is the row/column numbers and a number
    >> of cells you want your GUI element to occupy in X or Y
    >> dimension.


    >I think for most layouts it's better to place components
    >left-to-right and top to bottom using gridwidth=REMAINDER
    >to end a "line". The layout is easier to modify that way.


    >> Forget about the minimum and preferred sizes.
    >> They are virtually useless. If you do your
    >> design correctly, you'll have the absolute
    >> minimum of variour parameters to be set
    >> as far as boundaries, sizes, etc.,
    >> behaving the in the most predictable way
    >> possible under the Sun.

    >
    >Sometimes you need certain components to be
    >shrinkable to zero size to get the effect you want,
    >so setting a zero preferred and minimum size of
    >zero in one or both directions is useful.
    >
    >> Some claim that by using some proprietary
    >> layouts, they can save half the amount of code lines,
    >> which is about the funniest argument possible.

    >
    >By wrapping GridBagLayout in a helper class that
    >does the common things I need, I probably save
    >75% of the size of the gui part of the source code,
    >and a lot of space in the class file as well. It also
    >keeps my layouts consistent by enforcing common
    >spacings, etc. Most of my GridBagLayout code
    >uses one line of code for each component added,
    >and that is a method call with two parameters.
    >For example (part of one layout):


    It'll break your GUI designer, if you use one.
    Otherwise, just write it all by hand.
    Good luck on that one.

    >panel.addLabel("Color", GBLPanel.ANCHOR_EAST |
    > GBLPanel.FLUSH_BOTTOM);
    >panel.add(color_setter, GBLPanel.ANCHOR_WEST |
    > GBLPanel.HOG_WIDTH | GBLPanel.FILL_HORIZONTAL |
    > GBLPanel.FLUSH_ALL);


    >If you are doing a large amount of gui code using
    >GridBagLayout, creating such a helper class is
    >well worth the effort.


    The problem is that you are talking about making
    things by hand, which I, personally, do not support.
    At THIS stage of the game, you'd better have some
    automation.

    >> 12. Try not to use weights, if at all possible.
    >> If your frame has several groups of GUI elements,
    >> each having several elements, then what you think
    >> is space distribution may end up being utterly
    >> different in run time and you'll waste hours if
    >> not days, trying to play with those weights.


    >Having zero weights can cause strange effects.
    >Always use weights, but choose from a limited set.
    >Normally you have some group of components
    >that together should use all of the extra height or
    >width (text fields, text areas, sliders, editable combo
    >boxes, lists, etc.) and others that should have a
    >fixed size (labels, buttons, etc), and you can get by
    >with always using a weight of either 1000000 or
    >..000001.


    That is another problem, the inconsistency of behavior.
    In some instances, changing weight from 0 to 0.00000001
    changes the behavior in such drastic manner,
    it is well beyond comprehension.

    >> Use as few parameters in your constraints structure
    >> as possible.


    >Use mostly consistent parameters, and few choices
    >for weights and spacings.


    >GridBagLayout does not play well below preferred
    >size. Consider only using it within a scrolled pane
    >or a window that is not shrinkable below preferred
    >size.


    >Creating your own layout manager is much simpler
    >that you think. For some reason people will spend five
    >hours fiddling with GridBagLayout or SpringLayout
    >trying to get it to do something it wasn't meant to do,
    >when they could write a custom layout manager in
    >under an hour.


    If they had enough experience to do that.
    But, no matter what is the situation,
    writing a GUI class by hand seems to be like a joke
    considering where we are. It is like writing an app
    with a hex calculator. Sure, some experienced users
    will be able to do it, but even there, if you want
    to change some things in the future, your scull may
    crack trying to read back your own code if your
    frame is complex enough. That is why there are GUI
    design tools on the first place.
    nukleus, Feb 8, 2007
    #3
  4. "nukleus" <> wrote in message
    news:eqg01l$1u0g$...
    >>By wrapping GridBagLayout in a helper class that
    >>does the common things I need, I probably save
    >>75% of the size of the gui part of the source code,
    >>and a lot of space in the class file as well. It also
    >>keeps my layouts consistent by enforcing common
    >>spacings, etc. Most of my GridBagLayout code
    >>uses one line of code for each component added,
    >>and that is a method call with two parameters.
    >>For example (part of one layout):

    >
    > It'll break your GUI designer, if you use one.
    > Otherwise, just write it all by hand.
    > Good luck on that one.

    ....
    >>If you are doing a large amount of gui code using
    >>GridBagLayout, creating such a helper class is
    >>well worth the effort.

    >
    > The problem is that you are talking about making
    > things by hand, which I, personally, do not support.
    > At THIS stage of the game, you'd better have some
    > automation.


    I don't support using a gui builder for anything other
    than prototyping and toy applications. In the long
    run doing your layouts by hand will save a lot of
    time and frustration. With a wrapper class like I use,
    coding by hand with GridBagLayout is very simple.

    Also, using a gui builder prevents you from creating
    systems that automatically build gui from data (like
    a list of settings names and types) and methods that
    build similar interfaces with minor variations. Having
    the gui-builder mindset means you will miss out on
    chances to make your code easily maintainable in
    this way.

    >>> 12. Try not to use weights, if at all possible.
    >>> If your frame has several groups of GUI elements,
    >>> each having several elements, then what you think
    >>> is space distribution may end up being utterly
    >>> different in run time and you'll waste hours if
    >>> not days, trying to play with those weights.

    >
    >>Having zero weights can cause strange effects.
    >>Always use weights, but choose from a limited set.
    >>Normally you have some group of components
    >>that together should use all of the extra height or
    >>width (text fields, text areas, sliders, editable combo
    >>boxes, lists, etc.) and others that should have a
    >>fixed size (labels, buttons, etc), and you can get by
    >>with always using a weight of either 1000000 or
    >>..000001.

    >
    > That is another problem, the inconsistency of behavior.
    > In some instances, changing weight from 0 to 0.00000001
    > changes the behavior in such drastic manner,
    > it is well beyond comprehension.


    To be fair, the GridBagLayout documentation does
    say "Unless you specify a weight for at least one component
    in a row (weightx) and column (weighty), all the components
    clump together in the center of their container.

    >>Creating your own layout manager is much simpler
    >>that you think. For some reason people will spend five
    >>hours fiddling with GridBagLayout or SpringLayout
    >>trying to get it to do something it wasn't meant to do,
    >>when they could write a custom layout manager in
    >>under an hour.

    >
    > If they had enough experience to do that.


    When people need a custom layout, it's usually for a
    row of buttons or something; they don't need to
    create a general-purpose layout manager. I've seen
    people do what I describe above many times. They
    have some very simple layout requirement for a few
    components for which GridBagLayout and SpringLayout
    are ill suited, and go through all kinds of hoops and
    hours of work to try to use them. Then they decide to
    write their own layout manager and find that it is trivial.
    There's some kind of fear that it's "low-level work" or
    something.

    If the behavior of the desired layout is easy to
    understand, then the layout manager is easy to design
    and build.
    Larry Barowski, Feb 9, 2007
    #4
  5. nukleus

    Chris Uppal Guest

    Larry Barowski wrote:

    > When people need a custom layout, it's usually for a
    > row of buttons or something; they don't need to
    > create a general-purpose layout manager. I've seen
    > people do what I describe above many times. They
    > have some very simple layout requirement for a few
    > components for which GridBagLayout and SpringLayout
    > are ill suited, and go through all kinds of hoops and
    > hours of work to try to use them. Then they decide to
    > write their own layout manager and find that it is trivial.
    > There's some kind of fear that it's "low-level work" or
    > something.


    It may also, in part, be a fear of failing to re-use ("NIH-phobia"). I think
    that many people's reluctance to create custom Collections has a similar root.

    (Though, to be fair, that's not the whole explanation.)

    -- chris
    Chris Uppal, Feb 9, 2007
    #5
  6. nukleus

    nukleus Guest

    In article <>, "Larry Barowski"
    <MElarrybar-AT-eng_DOT_auburnANOTHERDOTeduEND> wrote:
    >
    >"nukleus" <> wrote in message
    >news:eqg01l$1u0g$...
    >>>By wrapping GridBagLayout in a helper class that
    >>>does the common things I need, I probably save
    >>>75% of the size of the gui part of the source code,
    >>>and a lot of space in the class file as well. It also
    >>>keeps my layouts consistent by enforcing common
    >>>spacings, etc. Most of my GridBagLayout code
    >>>uses one line of code for each component added,
    >>>and that is a method call with two parameters.
    >>>For example (part of one layout):

    >>
    >> It'll break your GUI designer, if you use one.
    >> Otherwise, just write it all by hand.
    >> Good luck on that one.

    >....
    >>>If you are doing a large amount of gui code using
    >>>GridBagLayout, creating such a helper class is
    >>>well worth the effort.

    >>
    >> The problem is that you are talking about making
    >> things by hand, which I, personally, do not support.
    >> At THIS stage of the game, you'd better have some
    >> automation.

    >
    >I don't support using a gui builder for anything other
    >than prototyping and toy applications.


    Well. Thats your choice.

    >In the long
    >run doing your layouts by hand will save a lot of
    >time and frustration. With a wrapper class like I use,
    >coding by hand with GridBagLayout is very simple.


    Could be. Can you post that code here?

    >Also, using a gui builder prevents you from creating
    >systems that automatically build gui from data (like
    >a list of settings names and types) and methods that
    >build similar interfaces with minor variations.


    Unfortunately, in my case, GUI is not some database
    type of form with lots of repetitive elements.
    It has to be hand sculpted to the most minute detail.
    THAT kind of automation does not help in my case.

    >Having
    >the gui-builder mindset means you will miss out on
    >chances to make your code easily maintainable in
    >this way.


    Well, I happen to think just the other way around.
    Right now, i have converted about 7-8 of my frames
    and all the gui designer generated code is kept
    in a separate class to be extended by higher levels.
    So, from now on, i can modify that gui in the easiest
    possible way, within minutes, then simply switch to
    another piece of bloatware and hit "build" button.
    The source file is the same for both environments
    and they both build nicely.

    So, once the initial phase is done with,
    it becomes the simpliest thing in the world to extend
    that gui in the most precise way, and that GUI is
    not that simple at all. Pretty intricate in fact.
    Not lika full blown IDE, but not far from it.

    That is how I see it.

    Looking back, when I was recomended to use layouts
    instead of null layout and my own on-the-fly XY layout
    approach, I am not sure this whole thing is even worth
    bothering with, as the code I had, after all the mods
    I did to it, was probably the most optimal, the easiest
    thing to maintain and modify possible, and it correctly
    took into account font sizes and things like that.
    So, it should render properly on just about any platform
    and screen resolution.

    But we are past that phase, and it was an interesting
    trip to see all this layout madness as I call it,
    because I have no better term for it.

    I wasted more than a week trying to convert about
    a dozen of my frames, which I initially estimated
    should last no more than a week, and I am still not
    quite done with it.

    The gridbag is screwed up beyond repair as far as
    I can see. I think conceptually, some things will
    NEVER reconcile, just looking at behavior of weights
    and fills.

    So...

    I have chosen the path of "mr. GUI designer, do
    your trick and give me that code, which I do not
    even want to see". And that code is overkill by
    ANY standards. But it is fine with me. For me,
    GUI, even if it takes 5% of total code, is something
    worth paying attention to.

    Most of the frames I converted look REALLY good,
    by ANY standard I know of. It is just perfect.
    I did not expect it to get THIS good.

    >>>> 12. Try not to use weights, if at all possible.
    >>>> If your frame has several groups of GUI elements,
    >>>> each having several elements, then what you think
    >>>> is space distribution may end up being utterly
    >>>> different in run time and you'll waste hours if
    >>>> not days, trying to play with those weights.

    >>
    >>>Having zero weights can cause strange effects.


    I know. I am dealing with this issue this very moment.
    I just took a lil break from it to read usenet.
    I am working on the main app's frame, which is pretty
    intricate. There are 3 pannels, 2 of which have text
    areas either for text entry or for command history
    display.

    The third one is a panel that contains all the buttons,
    and there are about 8 of them, 3 per each row.

    All implemented using gridbags. The problem is:
    I do not want buttons to be touched in ANY way.
    So, I set weights to 0.

    But my text areas need to adjust when you resize.
    So, beside the text areas, each panel has several
    labels, text fields, choice boxes, and checks.
    All have to look real good.
    So, I set the X weights on all the rows but the
    text area to 0, and set text area weight to 1.0.

    The same is with other panel that ALSO has a text
    area.

    Then, in the frame's gridbag, I set Y weight of one
    panel to 0.3 (of the whole frame), and the other
    panel at ...

    At what should I set it?
    Well, When I set it to 0.5, hoping that the panel
    with buttons would take about 20% of total Y dimension,
    the things would simply go bezerk, and I suspect
    because total weight exceeds 1.0. The entire button
    pannel just disspeared in run time, and text areas
    would not be of size corresponding to weights.
    The one with smaller weight was rendered bigger,
    and the one with bigger weight, was rendered smaller,
    and I had to waste at least an hour till I realized
    that the panel with bigger weight, that rendered
    smaller, should had its weight REDUCED in order to
    make it render LARGER.

    Kinda madhouse logic. But I am sure there is an
    explanation for this monkey logic somewhere.

    And how could I possibly know how much weight
    give to a button panel? I do not use paddings
    at all, if I can help. So, what weight should
    i use considering that the weight of my button
    pannel is unknown, is something beyond believable.

    Yes, I suspect if i did it by hand, I could easily
    calculate the correct ratios.

    Anyway, the gridbag concept is flawed as far as
    I can see.

    >>>Always use weights, but choose from a limited set.
    >>>Normally you have some group of components
    >>>that together should use all of the extra height or
    >>>width (text fields, text areas, sliders, editable combo
    >>>boxes, lists, etc.) and others that should have a
    >>>fixed size (labels, buttons, etc),


    Exactly.

    >>>and you can get by
    >>>with always using a weight of either 1000000 or
    >>>..000001.


    Weird, ain't it?
    Could you explain the effect of going from 0 to 0.0001
    or from 1 to 100000?

    What does it do?
    May be I should actually try it. The problem is this
    GUI designer is a buggy as hell. Not sure how could
    one of the biggest and baddest manufacturers out there
    could even release this kind of crap.
    It swallows 50 megs per mouse click and, after about 5-10
    minutes of work, starts freezing my box, yelling at me
    that it runs out of heap. It says there is only 10 megs
    of heap left.

    Ever heard?

    10 megs of heap is not enough just to lay out a 20k source
    code, at the VERY most. And I have about 1 Gig of virtual
    memory, and this stupid thing is telling me it does not
    have enough heap. Well, go get it, dummies, I've as much
    as you want. But, if i do not exit this "super" IDE,
    the box simply eventuall freezes and I can not even
    exit the IDE. You can't close the damn thing.

    Now, if the biggest and the baddest produce THIS kind
    of "advanced" tools, hailed on every corner, then
    what are you asking of ME, a mere mortal?

    :--}

    But I tell ya, my stuff NEVER behaves like that
    royal grade crap, where one hand does not even
    know what the other is doing. Weirdest thing I have
    EVER seen in my life.

    >> That is another problem, the inconsistency of behavior.
    >> In some instances, changing weight from 0 to 0.00000001
    >> changes the behavior in such drastic manner,
    >> it is well beyond comprehension.


    >To be fair, the GridBagLayout documentation does
    >say "Unless you specify a weight for at least one component
    >in a row (weightx) and column (weighty), all the components
    >clump together in the center of their container.


    Well, but that is a chicken shit level.
    Even if i DO specify it, it is still behaving
    in the most insane manner I have ever seen.

    >>>Creating your own layout manager is much simpler
    >>>that you think. For some reason people will spend five
    >>>hours fiddling with GridBagLayout or SpringLayout
    >>>trying to get it to do something it wasn't meant to do,
    >>>when they could write a custom layout manager in
    >>>under an hour.


    True. And I did that, and about the only problem
    I had is the Y size of menu and a title bar.
    When I added menus, all of a sudden the top row was
    obscured by the menu, and I couldn't find any place
    where I could get the menu size.

    The same thing is with scrollbar. But, if I recall
    correctly, you can get a scroll bar size by creating
    a scroll pane or something of a kind.
    Never tried it, but there could be even problem with
    that, because, I suspect, the scrollbar size may be
    returned as 0, unless the pane is shown, which is about
    the weirdest thing imaginable. And I wouldn't like
    to flash things and make some funky panes just to
    get the X/Y size of a scroll bar. This stuff is
    simply obscene.

    >> If they had enough experience to do that.


    >When people need a custom layout, it's usually for a
    >row of buttons or something; they don't need to
    >create a general-purpose layout manager. I've seen
    >people do what I describe above many times. They
    >have some very simple layout requirement for a few
    >components for which GridBagLayout and SpringLayout
    >are ill suited, and go through all kinds of hoops and
    >hours of work to try to use them.


    I totally agree. Use gridbag ONLY if you have some
    pretty sophisticated and pretty complex GUI.
    Othewise, it is a ROYAL pain on the neck.

    >Then they decide to
    >write their own layout manager and find that it is trivial.


    Isn't it?

    About the ONLY problem I had was that i could not
    get the insets that give me the value of a title bar
    and a menu, because there seems to be no way of getting
    them until the frame is shown. So, the old code, used
    addNotify() and it kinda worked, but not for the menu.
    The result was utterly different on different compilers.

    That is how I got into this layout madness.

    >There's some kind of fear that it's "low-level work" or
    >something.


    Well, if I knew what am I getting into,
    I would NEVER, even for a moment have considered it.
    But it was a good experience I guess, and I am
    pleased with the overall results.

    You see, the way I did it in the on-the-fly XY layout
    is to create a few variables telling the relative
    offsets of various columns and X/Y sizes of text
    fields, checkboxes, etc. Then, as things would get
    layed out on the fly, I would use the Y size of text
    fields, based on the font size, and add a inter-field
    margin to it, and the next row would get layed out
    at that Y position. It worked just perfectly and
    the code was VERY easy to modify and maintain.
    It was all just a matter of cut and past of a block,
    containing a row, and it would contain all correct
    offsets, and then paste it where I wanted to add
    more elements to extend the GUI.
    By the time I layed out all the rows,
    I had a final value to be used to set the frame's size.
    Worked like a champ.

    The whole trip of adding or modifying it, would take
    SECONDS, LITERALLY. Well :--}
    But no more than a couple of minutes.

    And now?

    Just look at this mess this thing generated.
    It is such an overkill, that i can hardly believe
    all these piles of code it generated.
    For every single gui element, there are couple of
    heavy duty calls with about 10 arguments each.
    This stuff is probably 5 times the size of my
    original code. Well, at least 2 times, thats fer sure.

    >If the behavior of the desired layout is easy to
    >understand, then the layout manager is easy to design
    >and build.


    Well, if you were here when I was asking about
    how to get the Y size of a title bar and a menu,
    and proper insets, I wouldn't have to waste more
    than a week of my time. Even my system crashed
    to the point where I had to reinstall the whole
    world from scratch, which is like having a heart
    attack.

    But it is all done deal now, more or less.

    But thanks for your feedback.
    nukleus, Feb 9, 2007
    #6
  7. nukleus

    nukleus Guest

    In article <45ccaf39$1$761$>, "Chris Uppal"
    <-THIS.org> wrote:
    >Larry Barowski wrote:
    >
    >> When people need a custom layout, it's usually for a
    >> row of buttons or something; they don't need to
    >> create a general-purpose layout manager. I've seen
    >> people do what I describe above many times. They
    >> have some very simple layout requirement for a few
    >> components for which GridBagLayout and SpringLayout
    >> are ill suited, and go through all kinds of hoops and
    >> hours of work to try to use them. Then they decide to
    >> write their own layout manager and find that it is trivial.
    >> There's some kind of fear that it's "low-level work" or
    >> something.

    >
    >It may also, in part, be a fear of failing to re-use ("NIH-phobia"). I think
    >that many people's reluctance to create custom Collections has a similar root.


    Well, looks like something smart sounding.
    But where is the specifics of the issues?

    >(Though, to be fair, that's not the whole explanation.)


    I bet you it isn't.
    It isn't even CLOSE to ANY kind of explanation.
    You'd have to look at specific situation and
    suggest a better way of doing it OVERALL,
    considering ALL sorts of things, such as esthetics,
    functionality, convenience, maintenance and ease of
    extendability of relatively complex GUI designs,
    and that is not the end of the list.

    > -- chris
    >
    >
    nukleus, Feb 9, 2007
    #7
  8. "nukleus" <> wrote in message
    news:eqj12t$30j2$...
    > In article <>, "Larry
    > Barowski"
    >>I don't support using a gui builder for anything other
    >>than prototyping and toy applications.

    >
    > Well. Thats your choice.


    It's an opinion based on experience.

    >>With a wrapper class like I use,
    >>coding by hand with GridBagLayout is very simple.

    >
    > Could be. Can you post that code here?


    There's a snippet above.

    >>Also, using a gui builder prevents you from creating
    >>systems that automatically build gui from data (like
    >>a list of settings names and types) and methods that
    >>build similar interfaces with minor variations.

    >
    > Unfortunately, in my case, GUI is not some database
    > type of form with lots of repetitive elements.
    > It has to be hand sculpted to the most minute detail.
    > THAT kind of automation does not help in my case.


    Most desktop applications have a lot of gui repetition
    and many similar gui elements, but yours may be
    different.

    > Then, in the frame's gridbag, I set Y weight of one
    > panel to 0.3 (of the whole frame), and the other
    > panel at ...
    >
    > At what should I set it?
    > Well, When I set it to 0.5, hoping that the panel
    > with buttons would take about 20% of total Y dimension,
    > the things would simply go bezerk, and I suspect
    > because total weight exceeds 1.0. The entire button
    > pannel just disspeared in run time, and text areas
    > would not be of size corresponding to weights.
    > The one with smaller weight was rendered bigger,
    > and the one with bigger weight, was rendered smaller,
    > and I had to waste at least an hour till I realized
    > that the panel with bigger weight, that rendered
    > smaller, should had its weight REDUCED in order to
    > make it render LARGER.
    >
    > Kinda madhouse logic. But I am sure there is an
    > explanation for this monkey logic somewhere.
    >
    > And how could I possibly know how much weight
    > give to a button panel? I do not use paddings
    > at all, if I can help. So, what weight should
    > i use considering that the weight of my button
    > pannel is unknown, is something beyond believable.
    >
    > Yes, I suspect if i did it by hand, I could easily
    > calculate the correct ratios.


    Normally you don't need any ratios. Give elements
    in rows or columns that need all the extra space a
    high weight and those in rows or columns that
    should have a fixed size a low weight.

    > Anyway, the gridbag concept is flawed as far as
    > I can see.


    Behavior between minimum and preferred size is
    flawed in my opinion. This was changed to something
    much better in one of the Beta releases or pre-releases,
    then changed back because it broke existing applications.
    Why they didn't just add a flag to support the new
    behavior, I don't know; maybe they thought it would be
    too much of a maintenance hassle.

    > Weird, ain't it?
    > Could you explain the effect of going from 0 to 0.0001
    > or from 1 to 100000?


    Only the ratios of total weights between different rows
    and between different columns matter. If you multiply
    all the weights in the layout by 1000000, there will be
    no change. I (mostly) use a high weight and a low weight
    instead of a high weight and zero weight, so that things
    still work in layouts where there are no high weight
    rows or columns. If all the rows or columns have zero
    weight, none of the extra space will be given to any
    component, and they will clump together in the middle
    as described in the documentation.

    > What does it do?
    > May be I should actually try it. The problem is this
    > GUI designer is a buggy as hell. Not sure how could
    > one of the biggest and baddest manufacturers out there
    > could even release this kind of crap.
    > It swallows 50 megs per mouse click and, after about 5-10
    > minutes of work, starts freezing my box, yelling at me
    > that it runs out of heap. It says there is only 10 megs
    > of heap left.
    >
    > Ever heard?
    >
    > 10 megs of heap is not enough just to lay out a 20k source
    > code, at the VERY most. And I have about 1 Gig of virtual
    > memory, and this stupid thing is telling me it does not
    > have enough heap. Well, go get it, dummies, I've as much
    > as you want. But, if i do not exit this "super" IDE,
    > the box simply eventuall freezes and I can not even
    > exit the IDE. You can't close the damn thing.


    You can probably run it with a bigger max heap size.

    >>>>Creating your own layout manager is much simpler
    >>>>that you think. For some reason people will spend five
    >>>>hours fiddling with GridBagLayout or SpringLayout
    >>>>trying to get it to do something it wasn't meant to do,
    >>>>when they could write a custom layout manager in
    >>>>under an hour.

    >
    > True. And I did that, and about the only problem
    > I had is the Y size of menu and a title bar.
    > When I added menus, all of a sudden the top row was
    > obscured by the menu, and I couldn't find any place
    > where I could get the menu size.


    Why lay out menus and title bars? Frame and Dialog
    do that for you.

    > The same thing is with scrollbar. But, if I recall
    > correctly, you can get a scroll bar size by creating
    > a scroll pane or something of a kind.
    > Never tried it, but there could be even problem with
    > that, because, I suspect, the scrollbar size may be
    > returned as 0, unless the pane is shown, which is about
    > the weirdest thing imaginable. And I wouldn't like
    > to flash things and make some funky panes just to
    > get the X/Y size of a scroll bar. This stuff is
    > simply obscene.


    JScrollBar.getPreferredSize() and getMinimumSize()
    return appropriate values.

    >>When people need a custom layout, it's usually for a
    >>row of buttons or something; they don't need to
    >>create a general-purpose layout manager. I've seen
    >>people do what I describe above many times. They
    >>have some very simple layout requirement for a few
    >>components for which GridBagLayout and SpringLayout
    >>are ill suited, and go through all kinds of hoops and
    >>hours of work to try to use them.

    >
    > I totally agree. Use gridbag ONLY if you have some
    > pretty sophisticated and pretty complex GUI.
    > Othewise, it is a ROYAL pain on the neck.


    I use the standard layouts for pretty much everything,
    but you have to know when they don't apply.

    > You see, the way I did it in the on-the-fly XY layout
    > is to create a few variables telling the relative
    > offsets of various columns and X/Y sizes of text
    > fields, checkboxes, etc. Then, as things would get
    > layed out on the fly, I would use the Y size of text


    You generally want the borders, insets, and other
    spacings specified by the Look-and-Feel, so this is
    a bad idea. Why not do the same thing, but use
    preferred sizes of the components?

    In general it sounds like you have never used layout
    managers before, and you just don't have a good feel
    for them yet. Designing good layouts is not always
    simple but it is important. Everybody hates fixed-size
    dialogs like you see in many native Windows apps,
    where you can't stretch the darn thing out to see the
    rest of the filename or more of the text.
    Larry Barowski, Feb 10, 2007
    #8
  9. nukleus

    nukleus Guest

    In article <>, "Larry Barowski"
    <MElarrybar-AT-eng_DOT_auburnANOTHERDOTeduEND> wrote:
    >
    >"nukleus" <> wrote in message
    >news:eqj12t$30j2$...
    >> In article <>, "Larry
    >> Barowski"
    >>>I don't support using a gui builder for anything other
    >>>than prototyping and toy applications.

    >>
    >> Well. Thats your choice.

    >
    >It's an opinion based on experience.
    >
    >>>With a wrapper class like I use,
    >>>coding by hand with GridBagLayout is very simple.

    >>
    >> Could be. Can you post that code here?

    >
    >There's a snippet above.
    >
    >>>Also, using a gui builder prevents you from creating
    >>>systems that automatically build gui from data (like
    >>>a list of settings names and types) and methods that
    >>>build similar interfaces with minor variations.

    >>
    >> Unfortunately, in my case, GUI is not some database
    >> type of form with lots of repetitive elements.
    >> It has to be hand sculpted to the most minute detail.
    >> THAT kind of automation does not help in my case.

    >
    >Most desktop applications have a lot of gui repetition
    >and many similar gui elements, but yours may be
    >different.
    >
    >> Then, in the frame's gridbag, I set Y weight of one
    >> panel to 0.3 (of the whole frame), and the other
    >> panel at ...
    >>
    >> At what should I set it?
    >> Well, When I set it to 0.5, hoping that the panel
    >> with buttons would take about 20% of total Y dimension,
    >> the things would simply go bezerk, and I suspect
    >> because total weight exceeds 1.0. The entire button
    >> pannel just disspeared in run time, and text areas
    >> would not be of size corresponding to weights.
    >> The one with smaller weight was rendered bigger,
    >> and the one with bigger weight, was rendered smaller,
    >> and I had to waste at least an hour till I realized
    >> that the panel with bigger weight, that rendered
    >> smaller, should had its weight REDUCED in order to
    >> make it render LARGER.
    >>
    >> Kinda madhouse logic. But I am sure there is an
    >> explanation for this monkey logic somewhere.
    >>
    >> And how could I possibly know how much weight
    >> give to a button panel? I do not use paddings
    >> at all, if I can help. So, what weight should
    >> i use considering that the weight of my button
    >> pannel is unknown, is something beyond believable.
    >>
    >> Yes, I suspect if i did it by hand, I could easily
    >> calculate the correct ratios.

    >
    >Normally you don't need any ratios. Give elements
    >in rows or columns that need all the extra space a
    >high weight and those in rows or columns that
    >should have a fixed size a low weight.
    >
    >> Anyway, the gridbag concept is flawed as far as
    >> I can see.

    >
    >Behavior between minimum and preferred size is
    >flawed in my opinion. This was changed to something
    >much better in one of the Beta releases or pre-releases,
    >then changed back because it broke existing applications.
    >Why they didn't just add a flag to support the new
    >behavior, I don't know; maybe they thought it would be
    >too much of a maintenance hassle.
    >
    >> Weird, ain't it?
    >> Could you explain the effect of going from 0 to 0.0001
    >> or from 1 to 100000?

    >
    >Only the ratios of total weights between different rows
    >and between different columns matter. If you multiply
    >all the weights in the layout by 1000000, there will be
    >no change. I (mostly) use a high weight and a low weight
    >instead of a high weight and zero weight, so that things
    >still work in layouts where there are no high weight
    >rows or columns. If all the rows or columns have zero
    >weight, none of the extra space will be given to any
    >component, and they will clump together in the middle
    >as described in the documentation.


    Interesting. I'll try that and see what happens.

    >> What does it do?
    >> May be I should actually try it. The problem is this
    >> GUI designer is a buggy as hell. Not sure how could
    >> one of the biggest and baddest manufacturers out there
    >> could even release this kind of crap.
    >> It swallows 50 megs per mouse click and, after about 5-10
    >> minutes of work, starts freezing my box, yelling at me
    >> that it runs out of heap. It says there is only 10 megs
    >> of heap left.
    >>
    >> Ever heard?
    >>
    >> 10 megs of heap is not enough just to lay out a 20k source
    >> code, at the VERY most. And I have about 1 Gig of virtual
    >> memory, and this stupid thing is telling me it does not
    >> have enough heap. Well, go get it, dummies, I've as much
    >> as you want. But, if i do not exit this "super" IDE,
    >> the box simply eventuall freezes and I can not even
    >> exit the IDE. You can't close the damn thing.

    >
    >You can probably run it with a bigger max heap size.


    I was trying to see where could I set that,
    but, after spending at least half an hour,
    just gave up.

    >>>>>Creating your own layout manager is much simpler
    >>>>>that you think. For some reason people will spend five
    >>>>>hours fiddling with GridBagLayout or SpringLayout
    >>>>>trying to get it to do something it wasn't meant to do,
    >>>>>when they could write a custom layout manager in
    >>>>>under an hour.

    >>
    >> True. And I did that, and about the only problem
    >> I had is the Y size of menu and a title bar.
    >> When I added menus, all of a sudden the top row was
    >> obscured by the menu, and I couldn't find any place
    >> where I could get the menu size.


    >Why lay out menus and title bars? Frame and Dialog
    >do that for you.


    I did not try to lay out menus and title bars.
    All I needed is the top inset so I knew where to start
    positioning the first row.
    If you start positioning it at 0 pix,
    then your first row will be obscured by the menu and
    a title bar.

    >> The same thing is with scrollbar. But, if I recall
    >> correctly, you can get a scroll bar size by creating
    >> a scroll pane or something of a kind.
    >> Never tried it, but there could be even problem with
    >> that, because, I suspect, the scrollbar size may be
    >> returned as 0, unless the pane is shown, which is about
    >> the weirdest thing imaginable. And I wouldn't like
    >> to flash things and make some funky panes just to
    >> get the X/Y size of a scroll bar. This stuff is
    >> simply obscene.


    >JScrollBar.getPreferredSize() and getMinimumSize()
    >return appropriate values.


    Sorry, AWT ONLY in my case.
    Microsoft does not support anything beyond it.

    >>>When people need a custom layout, it's usually for a
    >>>row of buttons or something; they don't need to
    >>>create a general-purpose layout manager. I've seen
    >>>people do what I describe above many times. They
    >>>have some very simple layout requirement for a few
    >>>components for which GridBagLayout and SpringLayout
    >>>are ill suited, and go through all kinds of hoops and
    >>>hours of work to try to use them.

    >>
    >> I totally agree. Use gridbag ONLY if you have some
    >> pretty sophisticated and pretty complex GUI.
    >> Othewise, it is a ROYAL pain on the neck.


    >I use the standard layouts for pretty much everything,
    >but you have to know when they don't apply.


    Unfortunately, most of them do not support margins.
    So, if you lay out things with grid layout, all your
    elements will glue together with no margins.
    Border layout is pretty much useless.
    Flow layout has some validity to it, but it is also
    way too limited, and I am not interested in anything
    beyond the most basic, standard stuff supported by
    AWT. Someone proposed some proprietary layout, but
    when I downloaded and looked at the source, it was
    immediately clear that it won't even build with MS.

    Basically, I am pleased with the results of gridbag
    overall, with all the associated pain on the neck.
    I just finished my main frame, which is about the
    most complex and intricate frame I have, and it all
    worked out just fine at the end. So, I am happy with
    it.

    >> You see, the way I did it in the on-the-fly XY layout
    >> is to create a few variables telling the relative
    >> offsets of various columns and X/Y sizes of text
    >> fields, checkboxes, etc. Then, as things would get
    >> layed out on the fly, I would use the Y size of text

    >
    >You generally want the borders, insets, and other
    >spacings specified by the Look-and-Feel, so this is
    >a bad idea. Why not do the same thing, but use
    >preferred sizes of the components?


    Sorry to tell you, but I did not trust the very
    concept of preferred size or minimal size after
    I was trying to get bounds of some of the components
    and was getting structures filled with 0.
    I did have the equivalent of margins, and I do know
    my element sizes. So, trying to get into this
    preferred stuff seems to be like getting into another
    pile of mess. Quite a lot of things are either messy,
    or have inconsistent behavior, or utterly out to lunch.
    At least this is the perception I have at the moment.
    I can't trust just about anything beyond the simpliest
    things on C level. Sure quite a lot of things work,
    but even working with sockets seems like a royal pain.
    Never expected anything like it in my wildest dreams.

    >In general it sounds like you have never used layout
    >managers before, and you just don't have a good feel
    >for them yet.


    True, and to tell you the truth,
    I am not even interested.
    Because there are much more important things to do.
    I explect to simply drag and drop the gui elements
    into a graphical GUI design panel, and snap them
    to some grid so they have the same exact sizes.
    That is about ALL I want to know about layouts.

    >Designing good layouts is not always
    >simple but it is important. Everybody hates fixed-size
    >dialogs like you see in many native Windows apps,


    And so do I. Because when you open a file dialog
    and there are hundreds of files to chose from,
    about the LAST thing I want to see is that microscopic
    dialog that I can not even maximize. The stuppidest
    thing imaginable.

    >where you can't stretch the darn thing out to see the
    >rest of the filename or more of the text.


    EXACTLY.

    When will these high priests of architects
    realize that their minds are minds of 5 year old
    and they are UTTERLY out of touch with the real world?

    :--}
    nukleus, Feb 10, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. nukleus

    GridBagLayout and its pitfals

    nukleus, Feb 8, 2007, in forum: Java
    Replies:
    2
    Views:
    483
    nukleus
    Feb 9, 2007
  2. nukleus

    GridBagLayout and its pitfals

    nukleus, Feb 9, 2007, in forum: Java
    Replies:
    0
    Views:
    389
    nukleus
    Feb 9, 2007
  3. thunk
    Replies:
    1
    Views:
    292
    thunk
    Mar 30, 2010
  4. thunk
    Replies:
    0
    Views:
    454
    thunk
    Apr 1, 2010
  5. thunk
    Replies:
    14
    Views:
    599
    thunk
    Apr 3, 2010
Loading...

Share This Page