AWT problem on linux

gelderk at natlab.research.philips.com gelderk at natlab.research.philips.com
Wed Sep 9 07:22:07 PDT 1998


> But that doesn't happen automatically - without a succeeding parent
> validate, the parent isn't layouted. And if validate()
> unconditionally does a layout, we have the same behavior, again. The
> only difference I can see is with cached layout sizes of valid
> Container childs (siblings of the Component that caused the
> invalidation) - these birds wouldn't be layouted during the JDK-
> validation. However, I guess this is rather a source of confusion
> than a useful feature, and don't see where it is defined in the
> specs. Anything I'm missing there?

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?)

What I would like to see is some sort automatic validate in each
top-level Container:

public void invalidate() {
  valid=false;
  if (parent!=null) parent.invalidate();
  else validate();
}

public void validate() {
  if (!valid) {
    // validate (layout) all children
    doLayout();
    valid=true;
  }
}

This has another problem, which I describe in the last paragraph of
this mail.

> Well, there are these class library books. They provide some annotations
> to the class docu, but it also is a semi-official source. Yes - I'm
> afraid, our main basis are the class docus.

Then how are we supposed to make a JVM with all classes, working? That
would force us to use parts of the jdk, which is precisely what you do
not want to do. Not releasing the standard/specification is what I
hate so much about M$.

Anyway the docs at
  http://java.sun.com/products/jdk/1.1/docs/api/java.awt.Container.html
  http://java.sun.com/products/jdk/1.1/docs/api/java.awt.Component.html
state clearly what I said in my first post:
 - invalidate() propagates through parents, marking them as invalid
 - validate() propagates through children, layouting and marking as valid
So we'd better implement it, then.

Apart from this, the whole validate() system might be circumvented by
something like (called from add(), remove(), setBounds() or whatever,
instead of invalidate()):

public void doLayoutUpwards() {
  doLayout();
  if (parent!=null) parent.doLayoutUpwards();
}

As I understand from the (somewhat cryptic) comments from Sun, the
validate() system allows multiple invalidate()s (layout requests) to
be handled later in one validate() call. It saves time, because double
layouts are prevented, but the programmer has to indicate when the
actual layout is done. That is not good, but we're probably stuck with
it (you might hide it is some repaint()-update() combination?)

Bye!

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


More information about the kaffe mailing list