AWT problem on linux

[gelderk at natlab.research.philips.com]

OK, here are my thoughts (it's Monday):

> > Who says Component Z can keep the same size if I enlarge Component X
> > in the same Container? I think that's the responsibility of the
> > LayoutManager (what else are minimum and preferred sizes for?)

Restated: if Component Z is resized, what would the LayoutManager of
its parent do? It would resize it back to its old size, because
neither its minimum, preferred nor maximum size is changed.

This means the a setBounds() should only layout itself and its
children. Programmers should never call setBounds(), only the resize
of a top-level Frame may call setBounds().

It also means that functions like setPreferredSize() (if they'd exist)
should propagate upwards in the tree.

[snip]

> > public void doLayoutUpwards() {
> >   doLayout();
> >   if (parent!=null) parent.doLayoutUpwards();
> > }
> 
> Suppose you have a dialog which can be expanded to show more
> ("advanced") options.  To show more options, you add a couple of dozen
> new buttons, checkboxes, labels, and so on to the dialog.  Wouldn't
> the doLayoutUpwards() solution (at least in the implementation above)
> mean that doLayout() would be called at least once for every new item
> you add?

As in the above, Yes;
In any real-life implementation it should be avoided.

> Anyway, Swing seems to have solved this in a nice way.  Since Swing is
> not thread-safe, you are supposed to perform all GUI updates from the
> event dispatch thread.  The revalidate() method, which seems to be
> called automatically by all methods that change a component (including
> setFont(), setBorder(), setText(), and similar methods), first calls
> invalidate() and then queues a request for validation (for the root of
> the component hierarchy) as a new event on the event dispatch thread.

Sounds OK (though I do not know what the event-dispatch-thread is).
Problem is in the ``all methods that change a component'', which will
particularly cause trouble in derived classes.

> Since you are *in* the event dispatch thread, you can continue
> changing/adding components.  Swing keeps track of the currently queued
> requests, so it won't add any more validation requests for the same
> root.  When you are done changing/adding components, the event
> dispatch thread will eventually get to the validate() request and
> validate() will be called.

That's OK.

> The programmer never has to call invalidate() or validate()
> manually.

I hope so!

However, for a class like

  public class DoubleLabel extends Label {
    private String secondtext;

    public void setSecondText(String newtext) {
      secondtext=newtext;
    }

    public void paint(Graphics graphics) {
      // put ``text: secondtext'' on the graphical context
    }
  }

no layout would be committed on the call of setSecondText(). To do
something about that, I'm afraid the programmer must call
invalidate().

That's exactly what invalidate() is for. I think it needs to be there.

As is implemented in kaffe at this moment, this is not far off, except
for the invalidate()/validate() mechanism.

--- now some free thinking: ---

Perhaps separating invalidate() into setMinimumSize(),
setPreferredSize() and setMaximumSize() would allow for better control
of what happens, would allow better ``caching'' of preferred sizes for
Containers; it is more work, though.

In Sun's implementation, the call to validate() must be done by the
user as well, which I think is bad. As Swing does, some trick with
threads should enable automatic layouting without
re-re-re-re-layouting when inserting several Components. 

Besides, I think the same argument holds for calling repaint(),
can't/shouldn't that be hidden from the programmer as well?

OK, that's it, bye!

+--- Kero ------------------ kero at dds.nl ---+
| I ain't changed,                          |
| but I know I ain't the same               |
+--- M38C --- http://huizen.dds.nl/~kero ---+