date:20160323

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

2016-03-23 Thread Alexander Scherbatiy

On 23/03/16 14:07, Avik Niyogi wrote:

On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy 
> wrote:

On 21/03/16 09:19, Avik Niyogi wrote:

Hi Alexander,
I agree with what you said regarding the look and feel looking 
different. But this bug arrises due to setting of 
TabbedPaneScrollLayout only. If Scroll Layout is not meant for Aqua 
look and feel should not the setting of this parameter instead throw 
a helpful error saying this parameter is not accepted
  According to the JTabbedPane.setTabLayoutPolicy(int 
tabLayoutPolicy) javadoc:
  "Some look and feels might only support a subset of the possible 
layout policies, in which case the value of this property may be 
ignored."

  Aqua L ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and 
always use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.

Actually, it is doing the other way around for Aqua L It is 
defaulting WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still 
setting a subclass of TabbedPaneLayout and not TabbedPaneScrollLayout.

   According to the JTabbedPane javadoc:
  SCROLL_TAB_LAYOUT: Tab layout policy for providing a subset of 
available tabs when all the tabs will not fit within a single run.
  WRAP_TAB_LAYOUT The tab layout policy for wrapping tabs in multiple 
runs when all tabs will not fit within a single run.

   The Aqua L uses only AquaTabbedPaneUI and AquaTabbedPaneContrastUI 
for tabbed pane UI and they both returns AquaTruncatingTabbedPaneLayout 
which has been designed for to place tabs according to the 
SCROLL_TAB_LAYOUT.

  Thanks,
  Alexandr.

  Thanks,
  Alexandr.

instead of absorbing this parameter and letting it render itself 
into a dummy node which does not proceed further with this 
parameter? Maybe we need to discuss what the expected behaviour may 
be. Also, thank you for the inputs regarding how to proceed with 
removing duplicate code.

With Regards,
Avik Niyogi
On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy 
> wrote:

I would think about something like:
-
public class TabbedPaneLayout implements LayoutManager {

protected int basePreferredTabAreaWidth(final int 
tabPlacement, final int height) {

// TabbedPaneLayout preferredTabAreaWidth implementation
}

protected int truncatingPreferredTabAreaWidth(final int 
tabPlacement, final int height) {
if (tabPlacement == SwingConstants.LEFT || tabPlacement 
== SwingConstants.RIGHT) {

return basePreferredTabAreaWidth(tabPlacement, height);
}

return basePreferredTabAreaWidth(tabPlacement, height);
}

protected int preferredTabAreaWidth(final int tabPlacement, 
final int height) {

return basePreferredTabAreaWidth(tabPlacement, height);
}

}

class TabbedPaneScrollLayout extends TabbedPaneLayout {
@Override
protected int basePreferredTabAreaWidth(int tabPlacement, 
int height) {
// TabbedPaneScrollLayout preferredTabAreaWidth 
implementation

}
}

protected class AquaTruncatingTabbedPaneLayout extends 
AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {

@Override
protected int preferredTabAreaWidth(final int tabPlacement, 
final int height) {
return truncatingPreferredTabAreaWidth(tabPlacement, 
height);

}
}

protected class AquaTruncatingTabbedScrollPaneLayout extends 
AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {

@Override
protected int preferredTabAreaWidth(final int tabPlacement, 
final int height) {
return truncatingPreferredTabAreaWidth(tabPlacement, 
height);

}
}
-

I just have one more question. The TabbedPaneScrollLayout is only 
created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use 
AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return 
TabbedPaneScrollLayout.

Are there any real cases when the TabbedPaneScrollLayout is created?

When you enabled the AquaTruncatingTabbedScrollPaneLayout in the 
AquaTabbedPaneUI the JTabbedPane L with SCROLL_TAB_LAYOUT does 
not look similar to Aqua L:

http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png

The AquaTruncatingTabbedPaneLayout already contains arrows for 
hidden tabs navigation.

May be the fix should update the AquaTruncatingTabbedPaneLayout only?

Thanks,
Alexandr.

On 18/03/16 14:21, Avik Niyogi wrote:

Hi Alexander,
Thank you for the inputs. I agree with you and did feel the need 
for removing duplicate code as well. But as per an earlier review 
input, changes to the super call lay outing is not accepted. This 
was the only other feasible solution. Created redundant code in 
this process, but would be maintaining with requirements with code 
impact to superclasses.
Please provide any

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

2016-03-23 Thread Avik Niyogi


> On 23-Mar-2016, at 3:31 pm, Alexander Scherbatiy 
>  wrote:
> 
> On 21/03/16 09:19, Avik Niyogi wrote:
>> Hi Alexander,
>> I agree with what you said regarding the look and feel looking different. 
>> But this bug arrises due to setting of TabbedPaneScrollLayout only. If 
>> Scroll Layout is not meant for Aqua look and feel should not the setting of 
>> this parameter instead throw a helpful error saying this parameter is not 
>> accepted
>   According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) 
> javadoc:  
>   "Some look and feels might only support a subset of the possible layout 
> policies, in which case the value of this property may be ignored."
>   
>   Aqua L ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and always 
> use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.

Actually, it is doing the other way around for Aqua L It is defaulting 
WRAP_TAB_LAYOUT and setting SCROLL_TAB_LAYOUT is still setting a subclass of 
TabbedPaneLayout and not TabbedPaneScrollLayout.

>   Thanks,
>   Alexandr.
> 
>> instead of absorbing this parameter and letting it render itself into a 
>> dummy node which does not proceed further with this parameter? Maybe we need 
>> to discuss what the expected behaviour may be. Also, thank you for the 
>> inputs regarding how to proceed with removing duplicate code.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy 
>>> > 
>>> wrote:
>>> 
>>> 
>>> I would think about something like:
>>> -
>>> public class TabbedPaneLayout implements LayoutManager {
>>> 
>>> protected int basePreferredTabAreaWidth(final int tabPlacement, 
>>> final int height) {
>>> // TabbedPaneLayout preferredTabAreaWidth implementation
>>> }
>>> 
>>> protected int truncatingPreferredTabAreaWidth(final int 
>>> tabPlacement, final int height) {
>>> if (tabPlacement == SwingConstants.LEFT || tabPlacement == 
>>> SwingConstants.RIGHT) {
>>> return basePreferredTabAreaWidth(tabPlacement, height);
>>> }
>>> 
>>> return basePreferredTabAreaWidth(tabPlacement, height);
>>> }
>>> 
>>> protected int preferredTabAreaWidth(final int tabPlacement, final 
>>> int height) {
>>> return basePreferredTabAreaWidth(tabPlacement, height);
>>> }
>>> 
>>> }
>>> 
>>> class TabbedPaneScrollLayout extends TabbedPaneLayout {
>>> @Override
>>> protected int basePreferredTabAreaWidth(int tabPlacement, int 
>>> height) {
>>> // TabbedPaneScrollLayout preferredTabAreaWidth implementation
>>> }
>>> }
>>> 
>>> protected class AquaTruncatingTabbedPaneLayout extends 
>>> AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
>>> 
>>> @Override
>>> protected int preferredTabAreaWidth(final int tabPlacement, final 
>>> int height) {
>>> return truncatingPreferredTabAreaWidth(tabPlacement, height);
>>> }
>>> }
>>> 
>>> protected class AquaTruncatingTabbedScrollPaneLayout extends 
>>> AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
>>> 
>>> @Override
>>> protected int preferredTabAreaWidth(final int tabPlacement, final 
>>> int height) {
>>> return truncatingPreferredTabAreaWidth(tabPlacement, height);
>>> }
>>> }
>>> -
>>> 
>>> I just have one more question. The TabbedPaneScrollLayout is only created 
>>> in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI 
>>> or AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 
>>> 
>>> Are there any real cases when the TabbedPaneScrollLayout is created?
>>> 
>>> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the 
>>> AquaTabbedPaneUI the JTabbedPane L with SCROLL_TAB_LAYOUT does not look 
>>> similar to Aqua L:
>>>   http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png 
>>> 
>>> 
>>> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs 
>>> navigation.
>>> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 18/03/16 14:21, Avik Niyogi wrote:
 Hi Alexander,
 Thank you for the inputs. I agree with you and did feel the need for 
 removing duplicate code as well. But as per an earlier review input, 
 changes to the super call lay outing is not accepted. This was the only 
 other feasible solution. Created redundant code in this process, but would 
 be maintaining with requirements with code impact to superclasses.
 Please provide any insight to a probable compensate to mitigate this 
 dichotomy of code expectation. Thank you in advance.
 
 With Regards,
 Avik Niyogi

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

2016-03-23 Thread Alexander Scherbatiy

On 21/03/16 09:19, Avik Niyogi wrote:

Hi Alexander,
I agree with what you said regarding the look and feel looking 
different. But this bug arrises due to setting of 
TabbedPaneScrollLayout only. If Scroll Layout is not meant for Aqua 
look and feel should not the setting of this parameter instead throw a 
helpful error saying this parameter is not accepted
  According to the JTabbedPane.setTabLayoutPolicy(int tabLayoutPolicy) 
javadoc:
  "Some look and feels might only support a subset of the possible 
layout policies, in which case the value of this property may be ignored."

  Aqua L ignores WRAP_TAB_LAYOUT for JTabbedPane tabs layouting and 
always use SCROLL_TAB_LAYOUT. No exception should be thrown in this case.

  Thanks,
  Alexandr.

instead of absorbing this parameter and letting it render itself into 
a dummy node which does not proceed further with this parameter? Maybe 
we need to discuss what the expected behaviour may be. Also, thank you 
for the inputs regarding how to proceed with removing duplicate code.

With Regards,
Avik Niyogi
On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy 
> wrote:

I would think about something like:
-
public class TabbedPaneLayout implements LayoutManager {

protected int basePreferredTabAreaWidth(final int 
tabPlacement, final int height) {

// TabbedPaneLayout preferredTabAreaWidth implementation
}

protected int truncatingPreferredTabAreaWidth(final int 
tabPlacement, final int height) {
if (tabPlacement == SwingConstants.LEFT || tabPlacement 
== SwingConstants.RIGHT) {

return basePreferredTabAreaWidth(tabPlacement, height);
}

return basePreferredTabAreaWidth(tabPlacement, height);
}

protected int preferredTabAreaWidth(final int tabPlacement, 
final int height) {

return basePreferredTabAreaWidth(tabPlacement, height);
}

}

class TabbedPaneScrollLayout extends TabbedPaneLayout {
@Override
protected int basePreferredTabAreaWidth(int tabPlacement, int 
height) {
// TabbedPaneScrollLayout preferredTabAreaWidth 
implementation

}
}

protected class AquaTruncatingTabbedPaneLayout extends 
AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {

@Override
protected int preferredTabAreaWidth(final int tabPlacement, 
final int height) {

return truncatingPreferredTabAreaWidth(tabPlacement, height);
}
}

protected class AquaTruncatingTabbedScrollPaneLayout extends 
AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {

@Override
protected int preferredTabAreaWidth(final int tabPlacement, 
final int height) {

return truncatingPreferredTabAreaWidth(tabPlacement, height);
}
}
-

I just have one more question. The TabbedPaneScrollLayout is only 
created in AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use 
AquaTabbedPaneUI or AquaTabbedPaneContrastUI which do not return 
TabbedPaneScrollLayout.

Are there any real cases when the TabbedPaneScrollLayout is created?

When you enabled the AquaTruncatingTabbedScrollPaneLayout in the 
AquaTabbedPaneUI the JTabbedPane L with SCROLL_TAB_LAYOUT does not 
look similar to Aqua L:

http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png

The AquaTruncatingTabbedPaneLayout already contains arrows for hidden 
tabs navigation.

May be the fix should update the AquaTruncatingTabbedPaneLayout only?

Thanks,
Alexandr.

On 18/03/16 14:21, Avik Niyogi wrote:

Hi Alexander,
Thank you for the inputs. I agree with you and did feel the need for 
removing duplicate code as well. But as per an earlier review input, 
changes to the super call lay outing is not accepted. This was the 
only other feasible solution. Created redundant code in this 
process, but would be maintaining with requirements with code impact 
to superclasses.
Please provide any insight to a probable compensate to mitigate this 
dichotomy of code expectation. Thank you in advance.

With Regards,
Avik Niyogi
On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy 
> wrote:

It is not usually a good idea to have a duplicated code which 
should be updated every time in several places.

Is it possible to move the  methods used both in 
AquaTruncatingTabbedPaneLayout and 
AquaTruncatingTabbedScrollPaneLayout  to TabbedPaneLayout with 
different names and then reused?

Thanks,
Alexandr.

On 17/03/16 17:17, Avik Niyogi wrote:

Hi Alexander,
The issue only applies for ScrollingTabbedPane and hence this fix.

With Regards,
Avik Niyogi

On 16-Mar-2016, at 4:51 pm, Alexander Scherbatiy 
 wrote:

Does the same issue affects the AquaTabbedPaneContrastUI?

Thanks,
Alexandr.

On 14/03/16 09:04, Avik Niyogi

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

2016-03-23 Thread Avik Niyogi

Hi Alexander,
With inputs (code) provided, it is not possible to accommodate the right 
methods for tabPlacement parameter.
Also, since AquaTabbedPane is copied from BasicUI.java, this implementation if 
moved to TabbedPaneLayout, does not accommodate Awua related changes and hence, 
the redundant code is in effect.
Also, regarding the query about the below:
> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs 
> navigation.
> May be the fix should update the AquaTruncatingTabbedPaneLayout only?

The defect due to the bug is injected only if Scrolling is in effect. The 
non-scrolling values populated for tabbedPaneLayout tried to add another row 
and hence would result in defects.
This was due to the fact that TabbedPaneScrollLayout was not even getting set 
even when the user was trying to set it.
Ideally, it would have been easier to call the super class to manage just the 
layout part but as per inputs received, it will not be accepted even though it 
have no splash impact and would not lead to regressions. 
Due to those reasons, this is the solution seeming fit for this.
I have tried the way suggested in your input code, but it broke the UI and 
different elements not required to be visible were being rendered because it is 
copying those elements from BasicUI.
If a better solution is available without breaking some code apart from fix 
provided, please let me know. Thank you in advance.

With Regards,
Avik Niyogi

> On 19-Mar-2016, at 1:52 am, Alexander Scherbatiy 
>  wrote:
> 
> 
> I would think about something like:
> -
> public class TabbedPaneLayout implements LayoutManager {
> 
> protected int basePreferredTabAreaWidth(final int tabPlacement, final 
> int height) {
> // TabbedPaneLayout preferredTabAreaWidth implementation
> }
> 
> protected int truncatingPreferredTabAreaWidth(final int tabPlacement, 
> final int height) {
> if (tabPlacement == SwingConstants.LEFT || tabPlacement == 
> SwingConstants.RIGHT) {
> return basePreferredTabAreaWidth(tabPlacement, height);
> }
> 
> return basePreferredTabAreaWidth(tabPlacement, height);
> }
> 
> protected int preferredTabAreaWidth(final int tabPlacement, final int 
> height) {
> return basePreferredTabAreaWidth(tabPlacement, height);
> }
> 
> }
> 
> class TabbedPaneScrollLayout extends TabbedPaneLayout {
> @Override
> protected int basePreferredTabAreaWidth(int tabPlacement, int height) 
> {
> // TabbedPaneScrollLayout preferredTabAreaWidth implementation
> }
> }
> 
> protected class AquaTruncatingTabbedPaneLayout extends 
> AquaTabbedPaneCopyFromBasicUI.TabbedPaneLayout {
> 
> @Override
> protected int preferredTabAreaWidth(final int tabPlacement, final int 
> height) {
> return truncatingPreferredTabAreaWidth(tabPlacement, height);
> }
> }
> 
> protected class AquaTruncatingTabbedScrollPaneLayout extends 
> AquaTabbedPaneCopyFromBasicUI.TabbedPaneScrollLayout {
> 
> @Override
> protected int preferredTabAreaWidth(final int tabPlacement, final int 
> height) {
> return truncatingPreferredTabAreaWidth(tabPlacement, height);
> }
> }
> -
> 
> I just have one more question. The TabbedPaneScrollLayout is only created in 
> AquaTabbedPaneCopyFromBasicUI. AquaLookAndFeel only use AquaTabbedPaneUI or 
> AquaTabbedPaneContrastUI which do not return TabbedPaneScrollLayout. 
> 
> Are there any real cases when the TabbedPaneScrollLayout is created?
> 
> When you enabled the AquaTruncatingTabbedScrollPaneLayout in the 
> AquaTabbedPaneUI the JTabbedPane L with SCROLL_TAB_LAYOUT does not look 
> similar to Aqua L:
>   http://cr.openjdk.java.net/~alexsch/8137169/aqua-scrolled-tabbed-pane.png 
> 
> 
> The AquaTruncatingTabbedPaneLayout already contains arrows for hidden tabs 
> navigation.
> May be the fix should update the AquaTruncatingTabbedPaneLayout only?
> 
> Thanks,
> Alexandr.
> 
> On 18/03/16 14:21, Avik Niyogi wrote:
>> Hi Alexander,
>> Thank you for the inputs. I agree with you and did feel the need for 
>> removing duplicate code as well. But as per an earlier review input, changes 
>> to the super call lay outing is not accepted. This was the only other 
>> feasible solution. Created redundant code in this process, but would be 
>> maintaining with requirements with code impact to superclasses.
>> Please provide any insight to a probable compensate to mitigate this 
>> dichotomy of code expectation. Thank you in advance.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 18-Mar-2016, at 2:42 pm, Alexander Scherbatiy 
>>> > 
>>> wrote:
>>> 
>>> 
>>> It is not usually a good idea to

Re: [9] Review request for JDK-8150225 api/javax_swing/text/AbstractWriter/index_indent failed

2016-03-23 Thread Rajeev Chamyal

Hello Sergey,

I had found below link about pre tag which states A P tag is strictly not 
permitted inside PRE, but if a browser encounters one, it should treat it as 
two newlines.
http://www.htmlhelp.com/reference/wilbur/block/pre.html 

Regards,
Rajeev Chamyal

-Original Message-
From: Sergey Bylokhov 
Sent: 22 March 2016 21:58
To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev@openjdk.java.net
Subject: Re:  [9] Review request for JDK-8150225 
api/javax_swing/text/AbstractWriter/index_indent failed

Looks fine to me. But I am not an expert here. And I wonder why the  tag is 
so specific, can we get the similar issue if some other tags will be used 
instead?

On 22.03.16 11:35, Rajeev Chamyal wrote:
> Hello All,
>
> Gentle reminder.
> Please review the fix.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225
> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/
>
> Regards,
> Rajeev Chamyal
>
> -Original Message-
> From: Rajeev Chamyal
> Sent: 09 March 2016 15:58
> To: Sergey Bylokhov; Alexander Scherbatiy; swing-dev@openjdk.java.net
> Subject: Re:  [9] Review request for JDK-8150225 
> api/javax_swing/text/AbstractWriter/index_indent failed
>
> Hello Sergey,
>
> I have run JCK tests for HTMLWriter and AbstractWriter with this fix and all 
> passed.
>
> Regards,
> Rajeev Chamyal
>
> -Original Message-
> From: Sergey Bylokhov
> Sent: 09 March 2016 15:54
> To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev@openjdk.java.net
> Subject: Re:  [9] Review request for JDK-8150225 
> api/javax_swing/text/AbstractWriter/index_indent failed
>
> Hi, Rajeev.
> Please confirm that there are no new issues in the jck after this fix.
>
> On 09.03.16 12:18, Rajeev Chamyal wrote:
>> Hello All,
>>
>> Please review the following fix for Jdk9:
>>
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8150225
>>
>> Webrev: http://cr.openjdk.java.net/~rchamyal/8150225/webrev.00/
>> 
>>
>> Issue : JCK conformance test failed due to fix for bug JDK-7104635
>>
>> Fix: Reverted the fix for JDK-7104635 and added a new method in 
>> HTMLWriter.java to check if P tag is within Pre tag.
>>
>> Decrement indentation is skipped if P tag is with a Pre tag.
>>
>> Regards,
>>
>> Rajeev Chamyal
>>
>
>
> --
> Best regards, Sergey.
>


--
Best regards, Sergey.

Re: CFV: New Swing Group Member: Semyon Sadetsky

2016-03-23 Thread Artem Ananiev



Vote: yes

Artem

On 3/21/16 9:01 AM, Alexander Scherbatiy wrote:


I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to
Membership in the Swing Group.

Semyon is active member of Swing group and contributed a lot of fixes
which include Swing TimerQueue race condition improvement, UndoManager
deadlock resolving, proposing and implementation a public API for
internal Swing functionality which is part of Swing modularization
support for JDK 9, and others (see Semyon’s list OpenJDK changesets [1])

Semyon proposed a big change for the Swing part of the JEP 283 “Enable
GTK 3 on Linux” [2] implementation [3].

Semyon not only provides fixes for Swing issues but also regularly
reviews fixes suggested by other members.

Votes are due by Apr 5, 2016.

Only current Members of the Swing  Group [4] are eligible
to vote on this nomination.

For Lazy Consensus voting instructions, see [5].

Thanks,
Alexandr.

[1]
http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000=author%28%22ssadetsky%22%29

[2] http://openjdk.java.net/jeps/283
[3] http://mail.openjdk.java.net/pipermail/swing-dev/2016-March/005440.html
[4] http://openjdk.java.net/census#swing
[5] http://openjdk.java.net/groups/#member-vote

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

Re: Review Request of 8137169 : [macosx] Incorrect minimal heigh of JTabbedPane with more tabs

Re: [9] Review request for JDK-8150225 api/javax_swing/text/AbstractWriter/index_indent failed

Re: CFV: New Swing Group Member: Semyon Sadetsky

6 matches

Site Navigation

Mail list logo

Footer information