<Swing Dev> [9] Review request for 8157065: There is no the focus border on the selected tab.
Alexandr Scherbatiy
alexandr.scherbatiy at oracle.com
Wed Sep 21 20:23:51 UTC 2016
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.
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