<Swing Dev> Review request #3: 6852592 (revalidate() must be smarter)
Anthony Petrov
Anthony.Petrov at Sun.COM
Wed Jul 29 09:56:11 UTC 2009
Hi Alex,
On 07/28/2009 10:31 PM, Alexander Potochkin wrote:
>>> As for the second question about making Window/Applet validate roots,
>>> I just don't see any practical benefits of this
>>>
>>> Could you please give more details why it is worth doing?
>>
>> As to the Applet class, there's a valid justification: the user does
>> not have a direct access to the underlying embedded frame which
>> therefore might be left invalid forever. Please see [1] for the
>> detailed description.
>
> If you absolutely need at least one validate root in the hierarchy,
This is not required. The requirement is to keep the whole hierarchy
valid. We can achieve that either using validate roots or calling
validate() on the top-level component. Since applets do not have
"official" access to/knowledge about their top-level component (the
embedded frame), we have to workaround that making the Applet a validate
root.
> and know how to correctly rewrite the messy code in RepaintManager and
> JViewport, I am fine with that
Hm, what kind of code might work wrong in that classes when the Window
and the Applet become validate roots? I don't see anything suspicious
there. In the mentioned snippets looking for a top-level component is
only used to verify that the whole hierarchy is contained within a
top-level. Since the search starts exactly from the previously found
validate root, the code must work perfectly even if there's no validate
roots between a component and the top-level (i.e. when there's no a
RootPane at least, which is unlikely for a Swing top-level, ain't it?)
But as I said, even in that fantastic case everything seems to work OK.
>> Regarding the Window: Artem proposed that at [2]. I didn't come up
>> with any failing scenario, so I considered this change harmless and
>> applied it. IMO, it isn't technically needed, but is conceptually
>> correct. Perhaps Artem might comment on that?
And here comes the technical justification to make the Window a validate
root. A component in a hierarchy can have two kinds of ancestors: a
container and an owner. The first one is the physical container as seen
on the screen (say, a Panel that a Button lays on). The latter is a
component that is kind of responsible for and/or dependent on the owned
component (like when the owned component must block its owner in some
cases, for instance). A perfect example is an owned modal Dialog. Dialog
does not have a container ancestor, but may indeed have an owner.
Unfortunately the API in AWT does not make any difference between these
kinds of ancestor: the Component.getParent() is used for both. And
unfortunately we can't change that now due to backward-compatibility
issues (that's why it is very important to architect APIs carefully from
the start.)
That said, the invalidate() method may easily jump to the owner of a
dialog (or a window) while invalidating the hierarchy of the owned
window - which is absolutely incorrect. To make sure this never happens,
we need to stop invalidating on top-level components, hence the need to
make the Window a validate root.
Sounds reasonable?
--
best regards,
Anthony
More information about the swing-dev
mailing list