<Swing Dev> [9] Review request for 8157065: There is no the focus border on the selected tab.
Alexandr Scherbatiy
alexandr.scherbatiy at oracle.com
Tue Oct 4 16:18:29 UTC 2016
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.
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