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

[Alexandr Scherbatiy]

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

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