On 9/20/2016 12:00 AM, Alexandr Scherbatiy wrote:
All orientation are equivalent and should correspond to the component
position. Drawing a border for a tab with unknown orientation is senseless.
On 9/14/2016 11:51 AM, Semyon Sadetsky wrote:
The GTK L&F just tries to paint Swing components in the same way as
It is possible to get a default orientation of a native component to
which the JTabbedPane corresponds to and use it.
On 9/13/2016 9:03 PM, Alexandr Scherbatiy wrote:
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.
On 9/13/2016 8:49 PM, Semyon Sadetsky wrote:
On 9/13/2016 8:46 PM, Alexandr Scherbatiy wrote:
Sorry, I didn't get how the separator orientation is related to
tabbed pane border.
On 9/13/2016 8:34 PM, Semyon Sadetsky wrote:
On 9/13/2016 8:25 PM, Alexandr Scherbatiy wrote:
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.
On 9/13/2016 7:38 PM, Semyon Sadetsky wrote:
It is a part of the public SynthPainter API and can be called
by an external application.
On 9/13/2016 7:21 PM, Alexandr Scherbatiy wrote:
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
On 9/12/2016 10:42 PM, Semyon Sadetsky wrote:
It was done for historical reason. For example before the
fix JDK-5033822 "Synth ScrollBar paintTrack() dosn't support
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.
On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote:
Interesting rule... I thought that more specific method
version may have different implementation.
On 9/12/2016 7:52 PM, Semyon Sadetsky wrote:
This is a usual rule for public methods which can be used
by an external application.
On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote:
Where I can read about this rule for SynthPainter? And it
obviously is not true.
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?
All the same methods with different number of arguments
which do not fall to overridden implementation should be
overridden to provide proper implementation.
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?
There are a lot of methods that are not over-riden in
GTKPainter. I even wrote an examples above.
SynthPainter.paintToolBarContentBackground(...) without the
orientation and the GTKPainter
.paintToolBarContentBackground overrides the method without
the orientation. So calls to
falls down to the overriden method in GTKPainter.
The same is for
and paintScrollBarBackground(..., orientation) methods.
The SynthPainter has only one paintToggleButtonBorder()
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.
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
And what the default value is? It is not defined.
Creates a new horizontal separator: Constructor JSeparator().
The default value, if not set, is SwingConstants.TOP.
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.
On 6/3/2016 10:54 PM, Semyon Sadetsky wrote:
On 6/3/2016 10:34 PM, Sergey Bylokhov wrote:
I guess you meant "is not over-ridden". :) Once again:
because it is never used.
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
Do you have any other concerns?
I still do not understand why the first method with
default orientation is not implemented.