<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