🚀 go-pugleaf

In article <MPG.1189d53f3b29ab7d989bd4@forums.inprise.com>, 
supportinfo@inprise.com says...
> restad@hinux.hin.no says...
> // When resizing of frames are done, no resizing of components are done
> // before the mousebutton is released. How can this be fixed?
> // 
> 
> Only a guess... this sounds like a project which would need you to go 
> back to basic frames and subclass with an over-ridden method, but I have 
> no idea which one(s). It has a feel of something you might need to get 
> the original JDK source from Sun, and waste a lot of time on experiments.
> 
> IMO you don't want to resize or move contained components until you drop 
> the frame, it will be lumpy as a mouse full of cat hair.  The 
> recalculate-paint overhead is too high or it would be implemented 
> already.  Note that active resizing contained objects is also unusual in 
> Windows (the OS) so I suspect MS also decided it was too intensive for 
> current systems.
> 
> 
I think it was more likely a performance issue with the original AWT.  
I've used a window_resizing event to recalc location/placement of 
components in other development environments for Windows and it works 
fine in terms of speed (although getting it right *really* makes you 
appreciate the layout manager approach of Java).

As performance boosters become more prevalent, the speed issue won't be 
the problem - it will be the legacy layout managers.

Tad Frysinger (TeamB)