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

[Semyon Sadetsky]

On 9/13/2016 9:03 PM, Alexandr Scherbatiy wrote:
> 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.
It is a default for JTabbedPane but not for the LnF. JTabbedPane always 
has some orientation and it is used in the painter. But I cannot even 
imagine what should be painted if the GTK painter API is called to paint 
TabbedPane without orientation and why. Because orientation is mandatory 
in the corresponding gtk-lib call.

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