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

[Semyon Sadetsky]

On 9/13/2016 8:46 PM, Alexandr Scherbatiy wrote:
> 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().
Sorry, I didn't get how the separator orientation is related to tabbed 
pane border.

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