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

[Alexandr Scherbatiy]

On 9/14/2016 11:51 AM, Semyon Sadetsky wrote:
> 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.
   The GTK L&F just tries to paint Swing components in the same way as 
native components.
   It is possible to get a default orientation of a native component to 
which the JTabbedPane corresponds to and use it.

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