Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [albireo-dev] size/layout management 
Bruno Haible wrote:


the results look fine. The reason is the following sequence of calls:
  1. JLabel.setText() calls revalidate(), which only sets a mark bit but
     does not recompute sizes, and posts an invokeLater to do that.
  2. composite.layout() asks the SwingControl for its preferred size.
     This returns the old size. Then layout calls setBounds, which causes
     a call to setAWTSize(160,135).
  3. Then the posted invokeLater is executed. The new label size is computed.
  4. The second call to composite.layout() runs, retrieves the new, corrected
     size; then it calls setBounds, which causes a call to setAWTSize(190,135).


That explains it. I didn't realize there was an invokeLater involved.


  - The default RepaintManager "collects" all invalidation requests, in
    order to minimize the validate() calls. For example, when someone does
       label1.setText(string1);
       label2.setText(string2);
    then, assuming label1 and label2 have common "validation root", the
    validate() call on this validation root will be executed only once.
    (That's also the reason why it does an invokeLater: Swing doesn't have
    startModifyingLayout()/endModifyingLayout() calls. Instead, all calls
    in a single AWT-Event handling are considered all together.)
    We lose this optimization if we hook into
    RepaintManager.addInvalidComponent.
How would the optimization be lost? Nothing would change about how the RepaintManager works. We'd simply be updating the cached AWT size on every addInvalidComponent() call. (As I said in the last email, calling layout() on every size change should not be done, so the cache size update should not be expensive.) 


  - When a programmer does
      validateRoot.invalidate(); validateRoot.validate();
    the RepaintManager is not involved at all.
Right, this is clearly the case that the RepaintManager hook could not handle. 



This patch fixes the "Relayout Example". All it does is to trigger a
composite.layout() call after the validate() call, when the sizes have
changed.
I'm beginning to think that we should allow the client to be involved in the handling of size updates. Perhaps we need a callback here? The client can then decide how and when to call layout().

Back to the top