You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Jaroslav Tulach <ja...@gmail.com> on 2020/10/25 10:15:19 UTC
API is ... was: https://github.com/apache/netbeans/pull/2482
Dne neděle 25. října 2020 1:47:03 CET, Ernie Rael napsal(a):
> I wasn't under the impression that adding a client property to a
> JComponent is considered API. Is this a new/extended definition of API?
I'd say that "API is everything somebody else can depend on": http://
wiki.apidesign.org/wiki/APITypes
As the whole purpose of the change is to let jVi use it, it is clearly an API
according to my definition.
-jt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: API is ...
Posted by Ernie Rael <er...@raelity.com>.
On 11/1/2020 10:36 PM, Jaroslav Tulach wrote:
> noticed the change and wanted to do it properly.
And I greatly appreciate that; I generally want to do it properly.
If I don't do something properly then I want it to be a choice and not
ignorance.
-ernie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: API is ...
Posted by Jaroslav Tulach <ja...@gmail.com>.
ne 25. 10. 2020 v 20:31 odesílatel Ernie Rael <er...@raelity.com> napsal:
> On 10/25/2020 3:15 AM, Jaroslav Tulach wrote:
> > Dne neděle 25. října 2020 1:47:03 CET, Ernie Rael napsal(a):
> >> I wasn't under the impression that adding a client property to a
> >> JComponent is considered API. Is this a new/extended definition of API?
> > I'd say that "API is everything somebody else can depend on": http://
> > wiki.apidesign.org/wiki/APITypes
>
> I can assure you that jVi would not "depend" on this:-)
Interesting point of view. Yes, jVi would just loosely depend on the
presence of the property and there would be no linkage errors, as the API
type comes from the JDK.
> Were it to
> disappear from NetBeans, things would simply revert to the somewhat
> flaky behavior.
That's what I meant by "depend". Not depend and crash, but depend and
behave differently.
> (There are a variety of things that jVi and my personal
> netbeans.conf use that are probably not documented. Perhaps I'm the only
> one.)
>
No, you are certainly not. I've just noticed the change and wanted to do it
properly. Seeing the outcome I should have rather shut up.
Best regards and thanks for your contributions.
-jt
Re: API is ... was: https://github.com/apache/netbeans/pull/2482
Posted by Ernie Rael <er...@raelity.com>.
On 10/25/2020 3:15 AM, Jaroslav Tulach wrote:
> Dne neděle 25. října 2020 1:47:03 CET, Ernie Rael napsal(a):
>> I wasn't under the impression that adding a client property to a
>> JComponent is considered API. Is this a new/extended definition of API?
> I'd say that "API is everything somebody else can depend on": http://
> wiki.apidesign.org/wiki/APITypes
I can assure you that jVi would not "depend" on this:-) Were it to
disappear from NetBeans, things would simply revert to the somewhat
flaky behavior. (There are a variety of things that jVi and my personal
netbeans.conf use that are probably not documented. Perhaps I'm the only
one.)
I was thinking of adding, to BaseCaret class javadoc, something like
If there is a client property of "HACK_CARET_MIN_WIDTH" with a value
of the correct type then it /might/ be used; see source code for
details.
But it was pointed out that there's '<api group="property"' in arch.xml
(who knew? or is it who remembered).
Some investigation reveals that the problem was most likely introduced
in 2010. The BaseCaret was superseded in 2015 by something without the
capability of drawing a custom caret (some details below).
-ernie
Someone noticed the existing comment
// [TODO] Temporary fix - impl should remember real bounds computed
by paintCustomCaret()
which came from the commit
$ hg log -r 162415
changeset: 162415:656a27790c32
date: Thu Mar 04 20:36:57 2010 +0100
summary: #121357 - New Editor View Hierarchy - initial commit.
which only adds the comment and the hack of using min with a constant of 2.
And there's
$ hg log -r 09ad7431da9a
changeset: 295468:09ad7431da9a
branch: editor_multi_caret
date: Wed Dec 16 02:20:44 2015 +0100
summary: BaseCaret functionality merged into EditorCaret.
BaseCaret reverted into original state.
Further fixes required.
I didn't even know there was a new EditorCaret. The timeframe suggests
this is one of those newer things before Oracle nuked NetBeans.
A quick look at EditorCaret source code shows some private, non
documented, stuff (see BLOCK_CARET) that might be useful for drawing a
custom caret, but as mentioned, it's private and not documented. My
guess is that this stuff never had the opportunity to mature.
>
> As the whole purpose of the change is to let jVi use it, it is clearly an API
> according to my definition.
> -jt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists