Your expectation is not correct because if insets are set for a
container then its child components can receive negative size even if
the parent size is positive.
--Semyon
On 7/24/2015 7:09 PM, Sergey Bylokhov wrote:
On 23.07.15 16:06, Semyon Sadetsky wrote:
Peer validation doesn't make any sense until layout manager may
easily set negative size for any component using
Component.setBounds(). That happens this issue particularly.
In your first request you mention that the problem occurs when "On
Linux and Solaris platforms the initial frame window width and height
can be negative".
My expectation is that: if the window size if >=0 then none of the
layout managers should set negative value for width/height, no?
So we need either to introduce the size constraint and fix the
general issue either make UI to be prepared to get negative size
occasionally i.e. fix the particular case (what is done in the
solution).
Which option are you suggesting?
--Semyon
On 7/23/2015 2:06 PM, Sergey Bylokhov wrote:
On 23.07.15 9:22, Semyon Sadetsky wrote:
O.K. It sounds like a generic rule. Can I add this constant to the
Component.reshape()?
Historically our components have a lack of any data validation
because the user was able to call peers methods directly. I assume
that such validation should exists already in the peers classes(like
XBaseWindow.xSetBounds()).
--Semyon
On 7/22/2015 3:40 PM, Sergey Bylokhov wrote:
It seems that the bug is in fact that the size of the window is
negative. In a lot of place we assume that it should be >=0.
On 22.07.15 14:28, Semyon Sadetsky wrote:
In setVisible(true) if size is not specified and pack has not
been called yet frame get some initial size depending on the
platform.
That is the purpose of the test : to call pack() after setVisible().
--Semyon
On 7/22/2015 2:03 PM, Alexander Scherbatiy wrote:
On 7/17/2015 5:32 PM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8130892
webrev: http://cr.openjdk.java.net/~ssadetsky/8130892/webrev.00/
On Linux and Solaris platforms the initial frame window width
and height can be negative. So the root view is initialization
trigger was updated to take negative values into account. The
fix was tested on Ubuntu 12, OEL7 and Solaris 11.
It looks strange that the test which does not set explicit
bounds and calls frame.pack() encounters into negative sizes.
In which place does the frame window obtain negative width
and height?
Thanks,
Alexandr.
--Semyon
