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

Semyon Sadetsky semyon.sadetsky at oracle.com
Mon Sep 12 16:52:54 UTC 2016


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. There are a lot of methods that are not over-riden in 
GTKPainter. I even wrote an examples above.

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




More information about the swing-dev mailing list