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

Semyon Sadetsky semyon.sadetsky at oracle.com
Wed Oct 5 09:19:23 UTC 2016



On 10/4/2016 7:18 PM, Alexandr Scherbatiy wrote:
> On 10/3/2016 12:20 PM, Semyon Sadetsky wrote:
>> On 9/21/2016 11:23 PM, Alexandr Scherbatiy wrote:
>>> On 9/20/2016 10:40 AM, Semyon Sadetsky wrote:
>>>> On 9/20/2016 12:00 AM, Alexandr Scherbatiy wrote:
>>>>> 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.
>>>> All orientation are equivalent and should correspond to the 
>>>> component position. Drawing a border for a tab with unknown 
>>>> orientation is senseless.
>>>   https://developer.gnome.org/gtk-tutorial/stable/x1450.html
>>>     void gtk_notebook_set_tab_pos(GtkNotebook *notebook, 
>>> GtkPositionType pos);
>>>     GtkPositionType will be one of the following, which are pretty 
>>> self explanatory: GTK_POS_LEFT, GTK_POS_RIGHT, GTK_POS_TOP, 
>>> GTK_POS_BOTTOM. GTK_POS_TOP is the default.
>> It is default on the widget level. There may not be default on the 
>> painter level because it shall paint the current widget's 
>> orientation. The default could make sense if the painting result were 
>> the same for any orientation.
>   SynthPainter contains two paintTabbedPaneTabBorder(...) methods. One 
> of them has orientation argument and the another does not have.
>   The method with the orientation argument should draw the border 
> according to the provided orientation value.
>   The method which does not have the orientation argument should draw 
> the border with the default orientation.
SynthPainter is a abstract class. Its implementation SynthPainteImpl 
ignores orientation for both  paintTabbedPaneTabBorder() methods.
Really, the GtkPainter extends SynthPainter but it was never a full 
implementation. GtkPainter only implements methods which are used in 
GTK+ LnF. I've alrady provided a lot of examples of other methods that 
are not used in GTK+ LnF and are not implemented in GtkPainter. I still 
did not get the reason to implement one such method in GtkPainter which 
is not being used in GTK+ LnF.
>
>   Thanks,
>   Alexandr.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>> --Semyon
>>>>>
>>>>>   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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>




More information about the swing-dev mailing list