<Swing Dev> [9] Review Request for 8130892: Test javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java fails in Solaris Sparcv9
Sergey Bylokhov
Sergey.Bylokhov at oracle.com
Mon Aug 3 14:59:32 UTC 2015
It seems I missed this suggestion, sorry. Then this fix looks fine.
Please file a separate issues for x11 on why it can have negative size,
and on the layout on why it does not work in some cases.
On 03.08.15 17:37, Semyon Sadetsky wrote:
> 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.
>
--
Best regards, Sergey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150803/29f49d89/attachment.html>
More information about the swing-dev
mailing list