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

[Alexandr Scherbatiy]

On 9/13/2016 8:49 PM, Semyon Sadetsky wrote:
> 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.
https://docs.oracle.com/javase/7/docs/api/javax/swing/JTabbedPane.html#setTabPlacement(int)
     The default value, if not set, is SwingConstants.TOP.

   Thanks,
   Alexandr.
>
> --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.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>