But we already told about that a dozen iterations ago.
I would suggest to address the negative component size question to a
newly created bug and this specific case can be fixed as proposed.
--Semyon
On 8/3/2015 5:19 PM, Sergey Bylokhov wrote:
Right, this is what I talk about, the problem is general and seems
reproduced by your test on all platforms and components. More
interesting is that it paints correctly but returns incorrect size(at
lest on mac).
On 03.08.15 16:58, Semyon Sadetsky wrote:
The bug's test case passes OSX even without this fix.
The test I sent here just for indication that negative size problem
is more general and does not related to the specific XWindow frame peer.
If you read this thread from beginning, in his review Alexander
suggested to use very exact frame size for the initial frame
layouting, but it cannot be predicted with 100% probability because
it is set by WM.
--Semyon
On 8/3/2015 4:23 PM, Sergey Bylokhov wrote:
On 27.07.15 16:32, Semyon Sadetsky wrote:
Alexander,
you can run the next test on Windows which sets the right frame
size and see that it fails because of the negative size.
This test always fail on macosx even after the fix(the hight is
zero), It fails even if I change the component to JButton. So does
the actual problem in the BasicTextUI? Interesting is that in both
cases the components are painted correctly, but the getHeight return
incorrect value.
import javax.swing.*;
import javax.swing.border.EmptyBorder;
import java.awt.*;
public class bug8001470 {
private static JFrame frame;
private static JTextField textField1;
private static JTextField textField2;
public static void main(String[] args) throws Exception {
SwingUtilities.invokeAndWait(new Runnable() {
@Override
public void run() {
frame = new JFrame("JTextField Test");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JPanel container = (JPanel) frame.getContentPane();
container.setLayout(new GridLayout(2,1));
textField1 = new JTextField("\u0e01");
textField2 = new JTextField("\u0c01");
JPanel panel = new JPanel();
BorderLayout mgr = new BorderLayout();
panel.setLayout(mgr);
container.add(panel);
panel.setBorder(new EmptyBorder(100, 100, 100, 100));
panel.add(textField1);
panel.add(textField2);
frame.setVisible(true);
frame.pack();
}
});
if( textField1.getHeight() < 10 || textField2.getHeight() <
10 )
throw new Exception("Wrong field height");
System.out.println("ok");
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
frame.dispose();
}
});
}
}
--Semyon
On 7/27/2015 2:52 PM, Semyon Sadetsky wrote:
-Alexander Yarmoliskiy
+Alexander Zvegintsev
On 7/27/2015 2:36 PM, Semyon Sadetsky wrote:
It is probably an issue, but even if fix it we cannot guarantee
that insets will be always less then the resulting frame size.
Method guessInsets() which obtains insets in frame's peer is
hinting.
And again layout manager is able to apply negative size to
container regardless the frame size.
--Semyon
On 7/27/2015 1:38 PM, Alexander Scherbatiy wrote:
I see that sun.awt.X11.WindowDimensions class takes insets
into account and sets window size bigger than insets size. It
looks like difference between windows size and insets should be
positive in this case.
Thanks,
Alexandr.
On 7/27/2015 9:56 AM, Semyon Sadetsky wrote:
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
--
Best regards, Sergey.
--
Best regards, Sergey.
