<Swing Dev> [9] Review request for 8157065: There is no the focus border on the selected tab.

Tue Sep 20 07:40:16 UTC 2016


On 9/20/2016 12:00 AM, Alexandr Scherbatiy wrote:
> On 9/14/2016 11:51 AM, Semyon Sadetsky wrote:
>> On 9/13/2016 9:03 PM, Alexandr Scherbatiy wrote:
>>> On 9/13/2016 8:49 PM, Semyon Sadetsky wrote:
>>>> On 9/13/2016 8:46 PM, Alexandr Scherbatiy wrote:
>>>>> On 9/13/2016 8:34 PM, Semyon Sadetsky wrote:
>>>>>>
>>>>>> On 9/13/2016 8:25 PM, Alexandr Scherbatiy wrote:
>>>>>>> On 9/13/2016 7:38 PM, Semyon Sadetsky wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/13/2016 7:21 PM, Alexandr Scherbatiy wrote:
>>>>>>>>> On 9/12/2016 10:42 PM, Semyon Sadetsky wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote:
>>>>>>>>>>> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>>>> GTKPainter does not implement a lot of methods which can 
>>>>>>>>>>>>>> be accessed by public API. Could you, please, explain, 
>>>>>>>>>>>>>> why this specific method is more important than, for 
>>>>>>>>>>>>>> example, paintToolBarContentBackground() or 
>>>>>>>>>>>>>> paintToggleButtonBorder(), or all other unimplemented?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In general, how do you separate public API methods of the 
>>>>>>>>>>>>>> SynthPainter class into two sets: the first set that 
>>>>>>>>>>>>>> *should be* over-riden and the second set of methods that 
>>>>>>>>>>>>>> *should not be* overr-riden? Are there any systematic 
>>>>>>>>>>>>>> criterium for that differentiation?
>>>>>>>>>>>>>   All the same methods with different number of arguments 
>>>>>>>>>>>>> which do not fall to overridden implementation should be 
>>>>>>>>>>>>> overridden to provide proper implementation.
>>>>>>>>>>>> Where I can read about this rule for SynthPainter? And it 
>>>>>>>>>>>> obviously is not true.
>>>>>>>>>>>   This is a usual rule for public methods which can be used 
>>>>>>>>>>> by an external application.
>>>>>>>>>>>> There are a lot of methods that are not over-riden in 
>>>>>>>>>>>> GTKPainter. I even wrote an examples above.
>>>>>>>>>>>   The SynthPainter.paintToolBarContentBackground(..., 
>>>>>>>>>>> orientation) calls 
>>>>>>>>>>> SynthPainter.paintToolBarContentBackground(...) without the 
>>>>>>>>>>> orientation and the GTKPainter 
>>>>>>>>>>> .paintToolBarContentBackground overrides the method without 
>>>>>>>>>>> the orientation.  So calls to 
>>>>>>>>>>> gtkPainter.paintToolBarContentBackground(..., orientation) 
>>>>>>>>>>> falls down to the overriden method in GTKPainter.
>>>>>>>>>>>
>>>>>>>>>>>  The same is for 
>>>>>>>>>>> SynthPainter.paintProgressBarBackground(..., orientation) 
>>>>>>>>>>> and paintScrollBarBackground(..., orientation) methods.
>>>>>>>>>>>
>>>>>>>>>>>  The SynthPainter has only one paintToggleButtonBorder() 
>>>>>>>>>>> method.
>>>>>>>>>> Interesting rule... I thought that more specific method 
>>>>>>>>>> version may have different implementation.
>>>>>>>>>   It was done for historical reason. For example before the 
>>>>>>>>> fix JDK-5033822 "Synth ScrollBar paintTrack() dosn't support 
>>>>>>>>> orientation"
>>>>>>>>>   there was only paintScrollBarBackground() method without the 
>>>>>>>>> orientation in the SynthPainter class.
>>>>>>>>>   After the fix the paintScrollBarBackground() method with the 
>>>>>>>>> orientation is added which default implementation just calls 
>>>>>>>>> the same method without the orientation because old user's 
>>>>>>>>> subclasses can override the method without the orientation an 
>>>>>>>>> not be aware about new method version.
>>>>>>>>>
>>>>>>>>>> What would you say about paintSeparatorBackground() ?
>>>>>>>>>> It's (..., orientation) version is over-ridden while the 
>>>>>>>>>> generic version is not over-ridden.
>>>>>>>>>    I guess that it is just a bug.
>>>>>>>> Not sure. GTKPainter has never been providing a systematic API 
>>>>>>>> from the beginning. It is not for an arbitrary external use, 
>>>>>>>> because the resulting painting will be unpredictable. I 
>>>>>>>> explained this in this thread many times. And even if I would 
>>>>>>>> like to provide this useless method implementation 
>>>>>>>   It is a part of the public SynthPainter API and can be called 
>>>>>>> by an external application.
>>>>>> I can be called without any predictable result.  This is the 
>>>>>> current state. It cannot be changed by the change you are 
>>>>>> proposing to add.
>>>>>   The result is described in the public method javadoc.
>>>>>>>> I were not able to do this because the orientation is a 
>>>>>>>> required parameter to paint the GTK tab border.
>>>>>>>   The overridden method without the orientation can just call 
>>>>>>> the overridden method with orientation passing a default 
>>>>>>> orientation value.
>>>>>> And what the default value is? It is not defined.
>>>>> https://docs.oracle.com/javase/7/docs/api/javax/swing/JSeparator.html
>>>>> Creates a new horizontal separator: Constructor JSeparator().
>>>> Sorry, I didn't get how the separator orientation is related to 
>>>> tabbed pane border.
>>> https://docs.oracle.com/javase/7/docs/api/javax/swing/JTabbedPane.html#setTabPlacement(int) 
>>>
>>>     The default value, if not set, is SwingConstants.TOP.
>> It is a default for JTabbedPane but not for the LnF. JTabbedPane 
>> always has some orientation and it is used in the painter. But I 
>> cannot even imagine what should be painted if the GTK painter API is 
>> called to paint TabbedPane without orientation and why. Because 
>> orientation is mandatory in the corresponding gtk-lib call.
>   The GTK L&F just tries to paint Swing components in the same way as 
> native components.
>   It is possible to get a default orientation of a native component to 
> which the JTabbedPane corresponds to and use it.
All orientation are equivalent and should correspond to the component 
position. Drawing a border for a tab with unknown orientation is senseless.
--Semyon
>
>   Thanks,
>   Alexandr.
>>
>> --Semyon
>>>
>>>   Thanks,
>>>   Alexandr.
>>>>
>>>> --Semyon
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>>
>>>>>> --Semyon
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>>  Thanks,
>>>>>>>>>>>  Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote:
>>>>>>>>>>>>>>> The paintTabbedPaneTabBorder() without orientation 
>>>>>>>>>>>>>>> should be implemented as well because it can be accessed 
>>>>>>>>>>>>>>> by public API.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote:
>>>>>>>>>>>>>>>>>>> What reason? Why it is not public? since I provided 
>>>>>>>>>>>>>>>>>>> the code example
>>>>>>>>>>>>>>>>>>> where these methods are accessed by the user?
>>>>>>>>>>>>>>>>>> GTK toollkit painting sequence is very different.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What does it mean "different"? Even in this fix you 
>>>>>>>>>>>>>>>>> implement one of the method according to the spec and 
>>>>>>>>>>>>>>>>> skip the same method for some unknown reason.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I still did not get why an overload method should 
>>>>>>>>>>>>>>>>>>>> have the same behavior
>>>>>>>>>>>>>>>>>>>> as its associates. This is a brand new design 
>>>>>>>>>>>>>>>>>>>> principle I've never heard
>>>>>>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ...........
>>>>>>>>>>>>>>>>>> That's nice...
>>>>>>>>>>>>>>>>>> Do you have any other concerns?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I still do not understand why the first method with 
>>>>>>>>>>>>>>>>> default orientation is not implemented.
>>>>>>>>>>>>>>>> I guess you meant "is not over-ridden". :) Once again: 
>>>>>>>>>>>>>>>> because it is never used.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>