On Thu, 2005-09-15 at 16:16 -0400, Anthony Balkissoon wrote: > On Thu, 2005-09-15 at 14:53 -0400, Thomas Fitzsimmons wrote: > > On Thu, 2005-09-15 at 20:48 +0200, Roman Kennke wrote: > > > Also, wouldn't it be sufficent to check if a component has a peer? The > > > API docs are a little bit confusing, but that is what it sounds to me. > > > > You mean rather than climbing the parent ladder? Whether or not a > > Component is displayable depends on the displayability of its parents. > > Whether or not a Window is displayable doesn't. > > > > The docs actually say that a Component is displayable when it is > attached to a native screen resource. It is _made_ displayable when it > is added to a displayable hierarchy or when it's hierarchy is made > displayable. These actions (adding to displayable hierarchy or making > hierarchy displayable) attach a native resource to the Component. So I > believe Component should simply return (peer != null). I tested this > and it passes the Mauve tests.
Please submit tests for all these assertions to Mauve, and run them on Sun. If they all pass on both Sun and ours with this patch, then you can commit it. Feel free to add to the existing isDisplayable tests. It would also be nice to clarify our javadocs on the matter now that we've figured it out (including a comment like "this reduces to checking that peer != null"). Tom _______________________________________________ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
