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.
--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.