<Swing Dev> [9] Review Request for 8130892: Test javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java fails in Solaris Sparcv9
Semyon Sadetsky
semyon.sadetsky at oracle.com
Mon Aug 3 14:37:03 UTC 2015
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150803/2dcaca7d/attachment.html>
More information about the swing-dev
mailing list