Hi Alex,
>>> Does this means there is going to be some work in JDK 8 so that the
>>> smart invalidation becomes the default?
>
> I wish we could have turned it on by default,
> but it caused regressions in the users' code
> so we made it optional to preserve the backward compatibility
User's code
Anthony,
> The algorithm caused a number of regressions in Swing that were identified
> too late in the release cycle of JDK 7, and as such it was decided to make
> this functionality optional in order to not delay the release of JDK 7.
Thanks for the clarifications.
Does this means there is goin
Anthony,
>> Great, that's it "-Djava.awt.smartInvalidate=true" solves the problem,
What was the reasoning of having the smart invalidate algorithm not
being the default?
Cheers,
-Christopher
Pavel,
> Of course all Swing methods (if javadoc doesn't say the opposite) must be
> called from EDT thread.
Which makes me remember that I recently received a bug report from
someone using the Java Access Bridge (JAB).
The bug is that JAB calls "Component.isFocusOwner()" outside of the
EDT but
Hi Anthony,
> It's been a long time since we discussed the issue. Now is the time for
> revival.
Thanks for raising the undead! :)
> The fix has been tested quite thoroughly
I had a look at the code and I don't see anything wrong with the
logic. Good work!
If all is well, in which build should
Hi Anthony,
> Unfortunately we indeed found incompatibilities with our solution: a Swing
> regression test failed.
I expected such cases but then the question becomes whether old code
that does not follow the rule should fail in order to clean things up
for the future.
> Since subsequent evaluat
> I'm not an expert in Swing, but AFAIK the paradigm used in Swing is calling
> the revalidate() method rather than making direct calls to the validate().
If only all Swing developers knew the Swing paradigm. Also, if Swing
did not expose invalidate() and validate() they would probably not end
up
Hi all,
I may be thinking out loud... but talking about incompatibilities:
In a situation where a container has a JScrollPane with a JComponent
somewhere down its hierarchy,
component.invalidate();
container.validate();
// Use some layout related values immediately
... would not have any effect a
Hi Anthony,
> Applets always have a parent: it's either an embedded frame on the web-page,
> or your own container (such as a JFrame, or whatever). So this condition is
> not going to work as we would like it to.
If I understand correctly, the logical validate root in case of the
browser is the b
> There's a reason to mark an Applet as a validate root: user should be able
> to call validate() on all the validate roots. If invalidate() goes up to the
> applet's parent (embedded frame), what code will call validate() on it? Do
> we want developers to write something like this:
>
> applet.g
While looking at some of the changes, I saw some existing code which I
do not really understand: why is JTextField having a special logic in
isValidateRoot in case it is not in a JViewPort? And if this component
has a special handling, why not other components?
-Christopher
On Thu, Jul 23, 2009
Anthony,
I think I disagree with Applet returning true to isValidateRoot. If I
am not mistaken, I think I saw some people placing an applet in their
component hierarchy as if it was a normal component. Invalidation
should propagate so that outer components can revalidate and thus have
proper layou
Hi Anthony,
> One more concern that comes to my mind is that the logic stated in the
> Swing's method specification is going to be implemented on the AWT's side,
> which I don't like much. So definitely we need more opinions on this
> proposal.
This may be a stupid idea, so disregard it if it is
Hi all,
I was trying out the new Lw/Hw mixing capabilities and I found a big
issue with it: for performance reasons, it does not calculate the
shapes of native components when the hierarchy is not valid.
The solution is not as simple as ensuring that the hierarchy is valid.
Let me explain.
I have
14 matches
Mail list logo
