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

[Semyon Sadetsky]

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.
>> 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.

--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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>