Re: Mouse quirks

[Alan]

I think Scott is onto something. I've run 20 or so tests where I 
experienced this by leaving my external mouse still and using the button 
on the laptop touchpad to do the clicking, and there were no 
"missed/ignored" clicks. Same story for a similar problem with opening 
files via double-click.


On 2020-04-30 18:39, Alan wrote:


That's a definite possibility... I'm a "drive by clicker", notorious 
for small mouse shifts between down and up. I'll try testing that out.


On 2020-04-30 16:11, Scott Palmer wrote:
Same on macOS. It seems if the mouse moves a single pixel between 
mouse down and mouse up then it may not count as a click.


Scott

On Apr 30, 2020, at 11:59 AM, Darin Miller  
wrote:



I also observe the "ultra precise" mouse behavior. Both on win7 and 
win10 desktops.


 o__
__>/ __
(__)\(__) Darin | 208-991-4421


On Thu, Apr 30, 2020 at 9:52 AM Alan 
> wrote:


Hi Eirik,

No display scaling, everything is 100%. It's also
monitor-independent. The problem is inconsistent, although it's
more prevalent with breakpoints than with the document close.
The highlight box is a good indication that the mouse position
is getting read right, it's the click event that seems to be
problematic.

At this point I'm waiting for a time when I have the presence of
mind to start screen captures. Then maybe I can better
characterize the problem. It doesn't appear to be a consistent
shift. I suspect the location of the actual hostspot is
dependent on screen coordinates. I've had this experience with
all the 11.x series, can't recall if it was there in 10.x or
not, but it's new since 8.2. If it's not "just me" with this
problem I'll see if I can set aside some time to get some more
actionable information.

This is an older machine, ASUS G75 laptop, i7-3630QM CPU, 12GB
RAM, SSD drives. Video card is NVIDIA GeForce GTX 660M, two
external monitors, external mouse Logitech M545. NB is usually
on a LG QHD 2560x1440 monitor.

On 2020-04-30 10:37, Eirik Bakke wrote:

I get the red box hover highlight around the "X" to close a document, but 
unless I click in exactly the right place within that box, the document doesn't close.

Hmm, odd--I'm on Windows 10 as well, and hadn't had this problem. Do you have HiDPI scaling active 
by any chance? ("Display Settings"->"Change the Size of Text, Apps and Other 
Items")

Will be easier to debug if you can find a way to consistently reproduce the 
problem.

-- Eirik

-Original Message-
From: Alan    
Sent: Thursday, April 30, 2020 12:07 AM

To: NetBeans Mailing List  

Subject: Mouse quirks

The question about odd laptop quirks has reminded me. Does anyone else 
experience this...

Under intermittent circumstances, mouse clicks seem to need to be extremely precise. 
For example on closing a document, I get the red box hover highlight around the 
"X" to close a document, but unless I click in exactly the right place within 
that box, the document doesn't close.
There's no consistency as to where the right spot is, either. This happens 
with sufficient frequency that I'm in the habit of using Crtl-W or right 
clicking and selecting close instead.

I also get this when trying to clear a breakpoint.

Running Windows 10 rev 1909, 64 bit, Java 13.0.2.


-
To unsubscribe, e-mail:users-unsubscr...@netbeans.apache.org  

For additional commands, e-mail:users-h...@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:users-unsubscr...@netbeans.apache.org  

For additional commands, e-mail:users-h...@netbeans.apache.org  


For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: NB 11.3 + Gradle 6x + integrationTest and Test File (ctlr-f6)

[Laszlo Kishalmi]

I'd recommend to add an improvement request into JIRA. I do not think 
that it can be solved in 11.3, some cumbersome workaround could be 
overriding the test action.


Unfortunately 12.0 is almost ready so most probably this can be released 
in August or some daily builds.



On 4/30/20 11:54 AM, Fred Welland wrote:
The older G4NB plugin had smarts or something such that it looked at 
pathing of where a test file was and adjusted the gradle invocation 
accordingly.


So for example, a Spock spec in: 
 src/test/groovy/com/blah/blah/SomeSpec.groovy


would invoke gradle a bit like like:

./gradlew   tests --tests com.blah.blah.SomeSpec

And if the Spock spec was here: 
src/integrationTest/groovy/com/blah/blah/OtherSpec.groovy


would invoke gradle a bit like like:

./gradlew   integrationTest  --tests com.blah.blah.OtherSpec

Basically, it seemed to do some simple matching of the path against 
tasks in the build file and away it went.


Can the 11.3, using builtin gradle support support this kind of 
behavior?   If so how?






-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Netbeans should generate Maven projects with latest version

[Ty Young]

On 4/30/20 6:08 PM, John Mc wrote:
Unless I'm mistaken, NetBeans uses the embedded NetBeans version, 
which for NetBeans 12.0 should have Maven 3.6.3 embedded.


There will be another beta version of 12.0 out soon I believe, so 
maybe confirm this with that version?



What I'm suggesting is to always use the latest version, not just the 
embedded version. Is there any harm in doing so?





Regards

John

On Thu, 30 Apr 2020 at 20:16, Ty Young > wrote:


JIRA: https://issues.apache.org/jira/browse/NETBEANS-4285


Netbeans should, assuming there are no blockers, always use the
latest
Maven release for newly generated projects.


Can this be done? The only issue, IIRC, is that Maven and JUnit don't
work correctly... but that affects older versions anyway too. No one
would be forced to upgrade either, it just affects new projects
created
via Netbeans.


-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org

For additional commands, e-mail: users-h...@netbeans.apache.org


For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Netbeans should generate Maven projects with latest version

[John Mc]

Unless I'm mistaken, NetBeans uses the embedded NetBeans version, which for
NetBeans 12.0 should have Maven 3.6.3 embedded.

There will be another beta version of 12.0 out soon I believe, so maybe
confirm this with that version?

Regards

John

On Thu, 30 Apr 2020 at 20:16, Ty Young  wrote:

> JIRA: https://issues.apache.org/jira/browse/NETBEANS-4285
>
>
> Netbeans should, assuming there are no blockers, always use the latest
> Maven release for newly generated projects.
>
>
> Can this be done? The only issue, IIRC, is that Maven and JUnit don't
> work correctly... but that affects older versions anyway too. No one
> would be forced to upgrade either, it just affects new projects created
> via Netbeans.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>

Re: Mouse quirks

[Alan]

That's a definite possibility... I'm a "drive by clicker", notorious for 
small mouse shifts between down and up. I'll try testing that out.


On 2020-04-30 16:11, Scott Palmer wrote:
Same on macOS. It seems if the mouse moves a single pixel between 
mouse down and mouse up then it may not count as a click.


Scott

On Apr 30, 2020, at 11:59 AM, Darin Miller  
wrote:



I also observe the "ultra precise" mouse behavior. Both on win7 and 
win10 desktops.


 o__
__>/ __
(__)\(__) Darin | 208-991-4421


On Thu, Apr 30, 2020 at 9:52 AM Alan > wrote:


Hi Eirik,

No display scaling, everything is 100%. It's also
monitor-independent. The problem is inconsistent, although it's
more prevalent with breakpoints than with the document close. The
highlight box is a good indication that the mouse position is
getting read right, it's the click event that seems to be
problematic.

At this point I'm waiting for a time when I have the presence of
mind to start screen captures. Then maybe I can better
characterize the problem. It doesn't appear to be a consistent
shift. I suspect the location of the actual hostspot is dependent
on screen coordinates. I've had this experience with all the 11.x
series, can't recall if it was there in 10.x or not, but it's new
since 8.2. If it's not "just me" with this problem I'll see if I
can set aside some time to get some more actionable information.

This is an older machine, ASUS G75 laptop, i7-3630QM CPU, 12GB
RAM, SSD drives. Video card is NVIDIA GeForce GTX 660M, two
external monitors, external mouse Logitech M545. NB is usually on
a LG QHD 2560x1440 monitor.

On 2020-04-30 10:37, Eirik Bakke wrote:

I get the red box hover highlight around the "X" to close a document, but 
unless I click in exactly the right place within that box, the document doesn't close.

Hmm, odd--I'm on Windows 10 as well, and hadn't had this problem. Do you have HiDPI scaling active 
by any chance? ("Display Settings"->"Change the Size of Text, Apps and Other 
Items")

Will be easier to debug if you can find a way to consistently reproduce the 
problem.

-- Eirik

-Original Message-
From: Alan    
Sent: Thursday, April 30, 2020 12:07 AM

To: NetBeans Mailing List  

Subject: Mouse quirks

The question about odd laptop quirks has reminded me. Does anyone else 
experience this...

Under intermittent circumstances, mouse clicks seem to need to be extremely precise. 
For example on closing a document, I get the red box hover highlight around the 
"X" to close a document, but unless I click in exactly the right place within 
that box, the document doesn't close.
There's no consistency as to where the right spot is, either. This happens 
with sufficient frequency that I'm in the habit of using Crtl-W or right 
clicking and selecting close instead.

I also get this when trying to clear a breakpoint.

Running Windows 10 rev 1909, 64 bit, Java 13.0.2.


-
To unsubscribe, e-mail:users-unsubscr...@netbeans.apache.org  

For additional commands, e-mail:users-h...@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:users-unsubscr...@netbeans.apache.org  

For additional commands, e-mail:users-h...@netbeans.apache.org  


For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Mouse quirks

[Scott Palmer]

Same on macOS. It seems if the mouse moves a single pixel between mouse down 
and mouse up then it may not count as a click.

Scott

> On Apr 30, 2020, at 11:59 AM, Darin Miller  wrote:
> 
> 
> I also observe the "ultra precise" mouse behavior. Both on win7 and win10 
> desktops.
> 
>  o__
>   >/  
> ( )\( ) Darin | 208-991-4421
> 
> 
>> On Thu, Apr 30, 2020 at 9:52 AM Alan  wrote:
>> Hi Eirik,
>> 
>> No display scaling, everything is 100%. It's also monitor-independent. The 
>> problem is inconsistent, although it's more prevalent with breakpoints than 
>> with the document close. The highlight box is a good indication that the 
>> mouse position is getting read right, it's the click event that seems to be 
>> problematic.
>> 
>> At this point I'm waiting for a time when I have the presence of mind to 
>> start screen captures. Then maybe I can better characterize the problem. It 
>> doesn't appear to be a consistent shift. I suspect the location of the 
>> actual hostspot is dependent on screen coordinates. I've had this experience 
>> with all the 11.x series, can't recall if it was there in 10.x or not, but 
>> it's new since 8.2. If it's not "just me" with this problem I'll see if I 
>> can set aside some time to get some more actionable information.
>> 
>> This is an older machine, ASUS G75 laptop, i7-3630QM CPU, 12GB RAM, SSD 
>> drives. Video card is NVIDIA GeForce GTX 660M, two external monitors, 
>> external mouse Logitech M545. NB is usually on a LG QHD 2560x1440 monitor.
>> 
>>> On 2020-04-30 10:37, Eirik Bakke wrote:
 I get the red box hover highlight around the "X" to close a document, but 
 unless I click in exactly the right place within that box, the document 
 doesn't close.
>>> Hmm, odd--I'm on Windows 10 as well, and hadn't had this problem. Do you 
>>> have HiDPI scaling active by any chance? ("Display Settings"->"Change the 
>>> Size of Text, Apps and Other Items") 
>>> 
>>> Will be easier to debug if you can find a way to consistently reproduce the 
>>> problem.
>>> 
>>> -- Eirik
>>> 
>>> -Original Message-
>>> From: Alan  
>>> Sent: Thursday, April 30, 2020 12:07 AM
>>> To: NetBeans Mailing List 
>>> Subject: Mouse quirks
>>> 
>>> The question about odd laptop quirks has reminded me. Does anyone else 
>>> experience this...
>>> 
>>> Under intermittent circumstances, mouse clicks seem to need to be extremely 
>>> precise. For example on closing a document, I get the red box hover 
>>> highlight around the "X" to close a document, but unless I click in exactly 
>>> the right place within that box, the document doesn't close. 
>>> There's no consistency as to where the right spot is, either. This happens 
>>> with sufficient frequency that I'm in the habit of using Crtl-W or right 
>>> clicking and selecting close instead.
>>> 
>>> I also get this when trying to clear a breakpoint.
>>> 
>>> Running Windows 10 rev 1909, 64 bit, Java 13.0.2.
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
>>> For additional commands, e-mail: users-h...@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: users-unsubscr...@netbeans.apache.org
>>> For additional commands, e-mail: users-h...@netbeans.apache.org
>>> 
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>> 

Netbeans should generate Maven projects with latest version

[Ty Young]

JIRA: https://issues.apache.org/jira/browse/NETBEANS-4285


Netbeans should, assuming there are no blockers, always use the latest 
Maven release for newly generated projects.



Can this be done? The only issue, IIRC, is that Maven and JUnit don't 
work correctly... but that affects older versions anyway too. No one 
would be forced to upgrade either, it just affects new projects created 
via Netbeans.



-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

NB 11.3 + Gradle 6x + integrationTest and Test File (ctlr-f6)

[Fred Welland]

The older G4NB plugin had smarts or something such that it looked at
pathing of where a test file was and adjusted the gradle invocation
accordingly.

So for example, a Spock spec in:
 src/test/groovy/com/blah/blah/SomeSpec.groovy

would invoke gradle a bit like like:

./gradlew   tests --tests com.blah.blah.SomeSpec

And if the Spock spec was here:
src/integrationTest/groovy/com/blah/blah/OtherSpec.groovy

would invoke gradle a bit like like:

./gradlew   integrationTest  --tests com.blah.blah.OtherSpec

Basically, it seemed to do some simple matching of the path against tasks
in the build file and away it went.

Can the 11.3, using builtin gradle support support this kind of behavior?
 If so how?

Re: location file which saves compole errors

[Peter Steele]

Hi

Quick update, I down graded from java 13 to java 11 and the problem has
gone away so it looks like it is linked to Java 13.

Regards

Peter

On Sun, Apr 5, 2020 at 2:15 PM Peter Steele  wrote:

> Hi
>
> Netbeans seems to cache compile errors and on startup immediate flags
> those compile errors with a red underline and red marker.
>
> I am assuming to be the case if it's wrong then the question will have to
> change slightly.
>
> I am getting incorrect compile errors highlighted in red which persist
> restarts. My program compiles and runs successfully but the code keeps
> getting highlighted as if it was in error. This started off with one error
> but has exploded to a lot of classes having this issue now.
>
> I have had this before and previously deleted the netbeans .netbeans
> folder but I would rather just delete the file necessary to make netbeans
> clear it's cache.
>
> Any help would be appreciated
>
> Thanks
>
> Peter
>
> p.s. this issue isn't easily replicatable as it just happens all of a
> sudden
>
> P.p.s I am on 11.3 but this has happened on all previous netbeans versions
> (can remember if it happened on an oracle version or not though)
>

Re: Mouse quirks

[Darin Miller]

I also observe the "ultra precise" mouse behavior. Both on win7 and win10
desktops.

 o__
  >/
( )\( ) Darin | 208-991-4421


On Thu, Apr 30, 2020 at 9:52 AM Alan 
wrote:

> Hi Eirik,
>
> No display scaling, everything is 100%. It's also monitor-independent. The
> problem is inconsistent, although it's more prevalent with breakpoints than
> with the document close. The highlight box is a good indication that the
> mouse position is getting read right, it's the click event that seems to be
> problematic.
>
> At this point I'm waiting for a time when I have the presence of mind to
> start screen captures. Then maybe I can better characterize the problem. It
> doesn't appear to be a consistent shift. I suspect the location of the
> actual hostspot is dependent on screen coordinates. I've had this
> experience with all the 11.x series, can't recall if it was there in 10.x
> or not, but it's new since 8.2. If it's not "just me" with this problem
> I'll see if I can set aside some time to get some more actionable
> information.
>
> This is an older machine, ASUS G75 laptop, i7-3630QM CPU, 12GB RAM, SSD
> drives. Video card is NVIDIA GeForce GTX 660M, two external monitors,
> external mouse Logitech M545. NB is usually on a LG QHD 2560x1440 monitor.
> On 2020-04-30 10:37, Eirik Bakke wrote:
>
> I get the red box hover highlight around the "X" to close a document, but 
> unless I click in exactly the right place within that box, the document 
> doesn't close.
>
> Hmm, odd--I'm on Windows 10 as well, and hadn't had this problem. Do you have 
> HiDPI scaling active by any chance? ("Display Settings"->"Change the Size of 
> Text, Apps and Other Items")
>
> Will be easier to debug if you can find a way to consistently reproduce the 
> problem.
>
> -- Eirik
>
> -Original Message-
> From: Alan  
> Sent: Thursday, April 30, 2020 12:07 AM
> To: NetBeans Mailing List  
> 
> Subject: Mouse quirks
>
> The question about odd laptop quirks has reminded me. Does anyone else 
> experience this...
>
> Under intermittent circumstances, mouse clicks seem to need to be extremely 
> precise. For example on closing a document, I get the red box hover highlight 
> around the "X" to close a document, but unless I click in exactly the right 
> place within that box, the document doesn't close.
> There's no consistency as to where the right spot is, either. This happens 
> with sufficient frequency that I'm in the habit of using Crtl-W or right 
> clicking and selecting close instead.
>
> I also get this when trying to clear a breakpoint.
>
> Running Windows 10 rev 1909, 64 bit, Java 13.0.2.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@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: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, 
> visit:https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>

Re: Mouse quirks

[Alan]

Hi Eirik,

No display scaling, everything is 100%. It's also monitor-independent. 
The problem is inconsistent, although it's more prevalent with 
breakpoints than with the document close. The highlight box is a good 
indication that the mouse position is getting read right, it's the click 
event that seems to be problematic.


At this point I'm waiting for a time when I have the presence of mind to 
start screen captures. Then maybe I can better characterize the problem. 
It doesn't appear to be a consistent shift. I suspect the location of 
the actual hostspot is dependent on screen coordinates. I've had this 
experience with all the 11.x series, can't recall if it was there in 
10.x or not, but it's new since 8.2. If it's not "just me" with this 
problem I'll see if I can set aside some time to get some more 
actionable information.


This is an older machine, ASUS G75 laptop, i7-3630QM CPU, 12GB RAM, SSD 
drives. Video card is NVIDIA GeForce GTX 660M, two external monitors, 
external mouse Logitech M545. NB is usually on a LG QHD 2560x1440 monitor.


On 2020-04-30 10:37, Eirik Bakke wrote:

I get the red box hover highlight around the "X" to close a document, but 
unless I click in exactly the right place within that box, the document doesn't close.

Hmm, odd--I'm on Windows 10 as well, and hadn't had this problem. Do you have HiDPI scaling active by 
any chance? ("Display Settings"->"Change the Size of Text, Apps and Other 
Items")

Will be easier to debug if you can find a way to consistently reproduce the 
problem.

-- Eirik

-Original Message-
From: Alan 
Sent: Thursday, April 30, 2020 12:07 AM
To: NetBeans Mailing List 
Subject: Mouse quirks

The question about odd laptop quirks has reminded me. Does anyone else 
experience this...

Under intermittent circumstances, mouse clicks seem to need to be extremely precise. For 
example on closing a document, I get the red box hover highlight around the "X" 
to close a document, but unless I click in exactly the right place within that box, the 
document doesn't close.
There's no consistency as to where the right spot is, either. This happens with 
sufficient frequency that I'm in the habit of using Crtl-W or right clicking 
and selecting close instead.

I also get this when trying to clear a breakpoint.

Running Windows 10 rev 1909, 64 bit, Java 13.0.2.


-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@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: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: Mouse quirks

[Eirik Bakke]

> I get the red box hover highlight around the "X" to close a document, but 
> unless I click in exactly the right place within that box, the document 
> doesn't close.

Hmm, odd--I'm on Windows 10 as well, and hadn't had this problem. Do you have 
HiDPI scaling active by any chance? ("Display Settings"->"Change the Size of 
Text, Apps and Other Items") 

Will be easier to debug if you can find a way to consistently reproduce the 
problem.

-- Eirik

-Original Message-
From: Alan  
Sent: Thursday, April 30, 2020 12:07 AM
To: NetBeans Mailing List 
Subject: Mouse quirks

The question about odd laptop quirks has reminded me. Does anyone else 
experience this...

Under intermittent circumstances, mouse clicks seem to need to be extremely 
precise. For example on closing a document, I get the red box hover highlight 
around the "X" to close a document, but unless I click in exactly the right 
place within that box, the document doesn't close. 
There's no consistency as to where the right spot is, either. This happens with 
sufficient frequency that I'm in the habit of using Crtl-W or right clicking 
and selecting close instead.

I also get this when trying to clear a breakpoint.

Running Windows 10 rev 1909, 64 bit, Java 13.0.2.


-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists