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

[Alexandr Scherbatiy]

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

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