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

[Semyon Sadetsky]

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 I were not able to do this because the orientation 
is a required parameter to paint the GTK tab border.

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