GroupLayout made life easier.
I’ll see you in the carpark, mister! 
OK, compromise! - In this particular case layout manager’s probably the best way to go…
[quote]Quote from: alexxz4 on March 01, 2008, 11:55:01 am
Well, then, if u just add a component, would you be able to see it if it has the default size (i.e. 0,0)?
No, you wouldn’t. That’s why you should use layout managers, as was suggested many times before in this thread. Why do you not like them?
[/quote]
Ummm… yes you would. Try adding a button to an applet, you’ll see it in the upper-central location. Its size is not 0,0 i can tell you.
So in affect this code:
setLayout(null); button.setLocation(20,20);
all by itself has the same affect as
button.setSize(0,0);
And layout managers position stuff how-ever they like to. You cant tell position of a component when a layout manager is done with it.
[quote]If you insist on using null layout as you are, then yes, it makes perfect sense that the programmer is required to set both the size and location of all components. How else would the AWT know where/how big to display the components?
[/quote]
It doesnt make sense to me why a programmer must set the size of a checkbox when he doesnt have to.
[quote]Quote
If u have 2 default sizes they are not default anymore are they? Gottcha…
I’m not sure what you mean by this.
[/quote]
Well, the first default size is the smallest size to fit the contents of the component. You get it when you do this:
void init(){
Button button=new Button("Button");
add(button);
}
The “second” default size is (0,0), you get it when u do this:
void init(){
Button button=new Button("Button");
setLayout(null);
add(button);button.setLocation(20,20);
}
[quote]If you’re going to be the only one to ever look at/modify your code, then this mindset is fine. But don’t say this at a job interview!
[/quote]
Like i said, im gonna modify it after i finish. First i gotta make sure it works without making my head explode with countless classes.
[quote]You consider good OOP design, with several concise, readable classes, each doing a different task, more “bloated” than a 3000+ line mega-class?
[/quote]
Common, everyone knows that OOP takes more statements to implement than FO. A formal OOP implementation requires the use of declaration, setters and getters, while OF only needs a declaration. OOP doesnt reduce line count by any stretch of imagination.
[quote]They didn’t have the problems you’re having. Don’t you think this means that the problems you’re having aren’t with the AWT, but instead with your code (or your understanding of the API?).
[/quote]
:o Yeah right, they never had to press Backspace or Delete or refer to a manual or debug or ask for help. Common! No actually, my problems are with AWT cause my code uses them. The AWT may not be buggy, but its a little under-developed, which is what i have a problem with.
The applets default LayoutManager is the FlowLayout. The LayoutManger will use the components minimum/preferred/maximum size to set the location and size of the component. When you use null layout you must do this yourself. Makes sense, don’t you think?
Correct. As was stated earlier, that’s because AWT Containers by default have a LayoutManager installed (FlowLayout as someone else pointed out, I believe). If you read some documentation or tutorials on AWT/Swing, you would have known this.
Again, correct. Since you explicitly call “setLayout(null)”, there is no LayoutManager installed to calculate the appropriate size of the button. Thus, it defaults to a size of (0,0). I fail to see what your problem is. If you spent time reading the documentation on layout managers, you’d know what was going on.
Maybe this will clarify things for you: If you use a LayoutManager, you’re telling your container “use this logic to size and position your child components.” If you say “setLayout(null)”, you’re essentially telling your container “Don’t size or position any child components for me; I’m going to handle all of that myself.”
This is false. Each LayoutManager has explicit rules it follows to lay out components. These rules are described in their documentation (Javadoc). You pick the layout manager that will arrange your components as you want them to be, and it does it.
Actually, you can, via Component#getLocation(), but that’s beside the point. The idea is that the programmer doesn’t actually care what exact pixel location his components are at. He only cares that they are laid out properly, sized properly, have the proper amount of spacing between them, etc. Layout managers do this for you.
A programmer doesn’t have to. If he uses a layout manager, it’ll set the size for you. Again, somebody must set the size of your components: either you must do it explicitly, or you can use a LayoutManager to do it for you. Why is that so difficult to accept?
This is because in your first init() method, the default layout manager is being used. This default layout manager is sizing your button for you. In the second init() method, you’re explicitly saying to use null layout. Since there’s no layout manager to size your component for you, it defaulted to a size of (0,0), and so you’ll have to set its size (and position) yourself. I fail to see your point here.
If that’s how you work, that’s fine. You’re not the only person in the world who doesn’t like OOP.
I won’t argue that OOP languages with Java-style syntax are concise. The idea Java’s designers were going for is “readability over compactness.” They believed that having source that’s easier for programmers to read was worth the extra 50 lines in a source file. Your opinion may differ, and that’s fine; but surely you’d agree that you should never sacrifice code readibility or extendability for the sake of “making it as short as possible?”
I never said programmers didn’t make mistakes. I said that you can be pretty comfortable that the AWT, as an API, is stable, and any problems you’re experiencing are much more likely to be bugs in your code then in the AWT itself. And I’d be willing to wager that most Java developers have Javadoc open in a web browser while they program (or use a tool such as Eclipse that spoon-feeds your Javadoc to you while you type).
Remember, you’re the one that implied that AWT was buggy (see what you titled this thread, and your previous posts in this thread). Then, it turned out that it wasn’t the AWT that was your problem, it was that you hadn’t spent time to read any documentation to know how to actually use the API. And could you clarify what you mean by “under-developed?” If you want something more feature-rich, go with Swing over AWT, as the AWT feature set isn’t really being updated anymore (save Desktop support I suppose).
Compromise is good. That way, we both win (or lose)! 
Your overriding a button’s size as soon as you set text on it, which most of us do by calling the constructor.
The more I think about null layouts which I ditched ages ago, the more issues popup.
borders spacing, are all differend among L&F, difference in fonts difference in dpi difference in resolution etc, there is no way you get away with fixed sizes unless you have complete controll. We’re talking fullscreen exclusive here.
The implementation of layout managers is not trivial. Why not just keep the size of a component as if it did have a layout manager when a user decides not use one. Setting a component size to 0 inroduces so much ambiguity. If it just set the size to some number (not 0) then the programmer would know that he needs to resize it. Anyways, lets not argue aout the correct use of layout managers, if there is function that disables a layout manager, then the AWT should fully support this possibility.
[quote]Why not just keep the size of a component as if it did have a layout manager when a user decides not use one. Setting a component size to 0 inroduces so much ambiguity. If it just set the size to some number (not 0) then the programmer would know that he needs to resize it. Anyways, lets not argue aout the correct use of layout managers, if there is function that disables a layout manager, then the AWT should fully support this possibility.
[/quote]
To me it makes perfect sense that without any LayoutManager, no layout is being done for you whatsoever, so no sizes are being set.
I think what you’re basically suggesting is a new LayoutManager, something like AbsolutePositioningLayout which only does a ‘best effort’ to size the GUI components. Still, I’d never use it, although it might be useful in some simple cases for some.
Also all the documentation tells you to use LayoutManagers with Swing and AWT. Use of Swing or AWT without LayoutManagers is not recommended, so no documentation exists for that. You have to figure it out. But I forgot reading documentation takes too much time, lets just hack around and then blame other peoples code when things don’t work.
Like OMG, guess what happened :o
A friend of mine has to make an applet for his class where he has to place two textfields in the center and two scrollbars below each texfield using Layout Managers. So we spent a few hours figuring it out and arrived at nowhere. I coulda done all that without layout manager in 2 minutes. Man, i wouldnt wanna be in his place… :
Turns out im not the only one who does not consider layout managers the easiest thing in the world.
Didn’t say it would be easy.
There isnt by any chance a Layout that doesnt resize components?
Depends on what you mean by resizing. With SpringLayout it’s possible to have layouts which do not stretch the components when the window size is changed - it all depends on what constraints you set. The problem is that SpringLayout was not designed for writing layout code by hand, so it’s maybe the hardest LayoutManager to use. However, using a null layout is much harder than using SpringLayout, so maybe you’ll like it. : At least SpringLayout will use the preferred size of the components.
There are lots of ways to do this. One common way is to put the components you don’t want resizing in a JPanel at BorderLayout.NORTH (or SOUTH, LINE_START or LINE_END, depending on where you want it anchored). Read the documentation on BorderLayout for details.
And before I forget, here’s one more good reason to go with layout managers over null layout: Say someone using your program has different display settings than you (say they’re using an enlarged default font setting because of poor vision). If you use null layout, your GUI will look horrible - nothing will be the right size, components may overlap, etc - unless you hard-code a font to use, which is often a bad idea. If you had used a LayoutManager, it would have taken care of sizing the components for you, and things would be fine.
What you need to do is nest layouts. If you want to say put a button at the bottom of your screen, then you use BorderLayout. The problem is that the button is sctretched out as wide as the display. To counteract that you add a JPanel to the bottom(SOUTH) of your BorderLayout and then set that JPanel to use FlowLayout. Then add the button to that JPanel. It will be at the bottom, but will stay at the proper size.
There is a short tutorial just on LayoutManagers. It will help you understand them better.
http://java.sun.com/developer/onlineTraining/GUI/AWTLayoutMgr/shortcourse.html
Netbeans WYSIWYG gui profides pretty clean code. (using group layout.) and is backported you can download a separate jar from spring labs for <1.6.
SpringLayout is just crap imo
GroupLayout replaced all Layout managers appart from the rare occasional borderlayout.
LayoutManagers will start to make things easier than absolute positioning as soon as you start making GUI’s that go beyond 2 textfields.
But most importantly, LayoutManagers make your GUI’s better.
Really, they’re not difficult or time consuming to use at all.
If you’d spent your time learning to use them rather than argueing about them, you would’ve been an expert by now. And probably a LayoutManager evangelist too