Re: Mouse quirks

[Scott Palmer]

The phenomenon that I observed on macOS is specific to NetBeans, though it 
could be all swing apps. (NetBeans is the only Swing UI I’m aware of running.)
Clicks in other applications are fine, so it doesn’t appear to be fixable with 
OS adjustments to the input device sensitivity. 
Clicks in the gutter to set a breakpoint or look at a hint seem to be where it 
is most frustrating.


Scott

> On May 1, 2020, at 3:09 PM, Eric J. Schwarzenbach 
>  wrote:
> 
> 
> I'd offer one suggestion for anyone suffering from double-click problems: you 
> can configure the click delay that determines whether a second click 
> constitutes a double click or a second single-click. I remember this being a 
> setting in the control panel from my Windows days, no idea about Macs, and in 
> Linux you may have to dig into a config file depending on your desktop 
> manager. I'm not positive that the OS setting affects Netbeans, but it might 
> be worth a try.
> 
> 
> 
> On 5/1/20 2:00 AM, James Ostrowick wrote:
>> I’m so glad someone else is having this problem! I thought it was just me.
>> 
>> It drives me nuts trying to create a debug breakpoint as well, sometimes I 
>> have to click several times to get it to acknowledge the breakpoint 
>> insertion.
>> 
>> What I have noticed is that it if you click, pause for about a second and 
>> then click again it acknowledges the second click better. (When creating 
>> breakpoints)
>> I’ve also found that the external mouse is less accurate than the trackpad 
>> for some very strange reason, possibly something to do with the resolution 
>> of the mouse being lower than the trackpad?
>> So, bluetooth apple mouse clicks tend NOT to be recognised as easily as the 
>> trackpad. 
>> 
>> I first noticed this irritation in NB 10, but its persisted into 11 as well 
>> 
>> This is on MacOS X Catalina 10.15.4, NB 11.3
>> 
>> 
>> 
>>> On 01 May 2020, at 07:51, Alan  wrote:
>>> 
>>> 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 

Re: Netbeans should generate Maven projects with latest version

[Ty Young]

On 5/1/20 2:26 PM, Jan Lahoda wrote:
I wonder - is this more about the version of the maven-compiler-plugin 
used, rather than of the Maven binary as such?




maven-compiler-plugin. Sorry for the confusion.


Netbeans creates new projects with 3.6.0, which doesn't support modules. 
The latest version is 3.8.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

Re: Netbeans should generate Maven projects with latest version

[Jan Lahoda]

I wonder - is this more about the version of the maven-compiler-plugin
used, rather than of the Maven binary as such?

Jan

On Thu, Apr 30, 2020 at 9:16 PM 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]

First thing I tried. No change.

On 2020-05-01 15:08, Eric J. Schwarzenbach wrote:


I'd offer one suggestion for anyone suffering from double-click 
problems: you can configure the click delay that determines whether a 
second click constitutes a double click or a second single-click. I 
remember this being a setting in the control panel from my Windows 
days, no idea about Macs, and in Linux you may have to dig into a 
config file depending on your desktop manager. I'm not positive that 
the OS setting affects Netbeans, but it might be worth a try.



On 5/1/20 2:00 AM, James Ostrowick wrote:
I’m so glad someone else is having this problem! I thought it was 
just me.


It drives me nuts trying to create a debug breakpoint as well, 
sometimes I have to click several times to get it to acknowledge the 
breakpoint insertion.


What I have noticed is that it if you click, pause for about a second 
and then click again it acknowledges the second click better. (When 
creating breakpoints)
I’ve also found that the external mouse is less accurate than the 
trackpad for some very strange reason, possibly something to do with 
the resolution of the mouse being lower than the trackpad?
So, bluetooth apple mouse clicks tend NOT to be recognised as easily 
as the trackpad.


I first noticed this irritation in NB 10, but its persisted into 11 
as well


This is on MacOS X Catalina 10.15.4, NB 11.3



On 01 May 2020, at 07:51, Alan > wrote:


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.

Re: Mouse quirks

[Eric J. Schwarzenbach]

I'd offer one suggestion for anyone suffering from double-click 
problems: you can configure the click delay that determines whether a 
second click constitutes a double click or a second single-click. I 
remember this being a setting in the control panel from my Windows days, 
no idea about Macs, and in Linux you may have to dig into a config file 
depending on your desktop manager. I'm not positive that the OS setting 
affects Netbeans, but it might be worth a try.



On 5/1/20 2:00 AM, James Ostrowick wrote:
I’m so glad someone else is having this problem! I thought it was just 
me.


It drives me nuts trying to create a debug breakpoint as well, 
sometimes I have to click several times to get it to acknowledge the 
breakpoint insertion.


What I have noticed is that it if you click, pause for about a second 
and then click again it acknowledges the second click better. (When 
creating breakpoints)
I’ve also found that the external mouse is less accurate than the 
trackpad for some very strange reason, possibly something to do with 
the resolution of the mouse being lower than the trackpad?
So, bluetooth apple mouse clicks tend NOT to be recognised as easily 
as the trackpad.


I first noticed this irritation in NB 10, but its persisted into 11 as 
well


This is on MacOS X Catalina 10.15.4, NB 11.3



On 01 May 2020, at 07:51, Alan > wrote:


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, 

Re: Netbeans should generate Maven projects with latest version

[Geertjan Wielenga]

Sure, that’s true. Just like the latest Payara and GlassFish can be
downloaded.

It would mean we wouldn’t need to bundle enbedded Maven at all.

Gj

On Fri, 1 May 2020 at 20:23, Ty Young  wrote:

>
> On 5/1/20 12:23 AM, Geertjan Wielenga wrote:
>
>
> Well, the user might not have the latest Maven installed. At least we know
> for sure that they have the embedded version.
>
>
> Why can't Netbeans download and use the newest Maven on-the-fly?
>
>
>
> Gj
>
> On Fri, 1 May 2020 at 01:38, Ty Young  wrote:
>
>>
>> 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

[Ty Young]

On 5/1/20 12:23 AM, Geertjan Wielenga wrote:


Well, the user might not have the latest Maven installed. At least we 
know for sure that they have the embedded version.



Why can't Netbeans download and use the newest Maven on-the-fly?




Gj

On Fri, 1 May 2020 at 01:38, Ty Young > wrote:



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 mailto:youngty1...@gmail.com>> 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: NB 11.3 + Gradle 6x + integrationTest and Test File (ctlr-f6)

[Fred Welland]

Thanks!

Just here:  https://issues.apache.org/jira/projects/NETBEANS/issues  ?   I
have to make an account?   (didn't see add issue button)

FWIW:   Got a reasonable solution that ties me over for now:  made a Task
and just hard coded a specific spec name to that.   It mostly works; and
available right click menu; so speeds up repetitive work on a specific
spec.   Note: the ${selectedClass} macro wouldn't expand for me.  Having
that work, would have been like 3/4ths what I need.  The other 1/4, and
this has probably been missing forever:  comprehensive macro & ide
automation feature triggerable by hot-keys.




On Thu, Apr 30, 2020 at 8:04 PM Laszlo Kishalmi 
wrote:

> 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: Quirks when running Netbeans 11.3 on a laptop

[Peter Steele]

I rolled back to jdk 11 after upgrading Ubuntu to 20.04 (11 is now the
highest openjdk that is packaged) and the issue no longer occurs.

Like with another issue I had it looks like jdk 13 was the issue.

I will be avoiding jdk 13 with netbeans until it works better



On Thu, 30 Apr 2020, 05:35 Peter Steele,  wrote:

> I'm running Ubuntu 19.10, 16 GB ram, hp Spectre x360 (integrated Intel
> graphics), open jdk 13, netbeans 11.3 (downloaded not snap) with no extra
> packages, I use gradle as part of standard package.
>
> On Thu, 30 Apr 2020, 04:43 Laszlo Kishalmi, 
> wrote:
>
>> I think it would be good if you could provide some details of your
>> laptop, like make, video card, OS, RAM, DISK, used JVM used NetBeans
>> package, etc.
>>
>> I myself running NetBeans on my Laptop, which is a System76 GalagoPro,
>> Intel internal and AMD external GPU, using Ubuntu 18.04, 32Gb RAM, have an
>> NVME and a spinning disk.
>>
>> I'm using the Snap distribution of NetBeans. I usually put the Laptop
>> into sleep for overnight and resume it in the morning. Udually I restart
>> NetBeans 1-2 times a week. So far never had such issues.
>> On 4/28/20 11:29 PM, John Brice wrote:
>>
>> I’ve had similar problems on Windows 10, netbeans 11.0 – 11.3 and JDK
>> 12/13. Line numbers disappear and nodes in the Projects pane go missing or
>> become unresponsive.
>>
>>
>>
>> I’ve changed my power settings to ‘never sleep’ but I still get the same
>> issues if I leave netbeans for a long time (1 – 2 hours or more); not every
>> time but often enough. If I use netbeans constantly all day there is no
>> problem.
>>
>>
>>
>> There is nothing obvious (to me) in the IDE log. I’ve cleared cache and
>> user dirs, doesn’t make a difference.
>>
>>
>>
>> John
>>
>>
>>
>>
>>
>> Hi
>>
>>
>>
>> I just wanted to know if people had noticed the following when running
>> netbeans 11.3 on their laptop (not sure if it happens on earlier versions
>> or not)
>>
>>
>>
>> I'm running on Ubuntu and using java 13
>>
>>
>>
>> 1. After closing the laptop lid and letting it suspend (or hibernate,
>> same thing), the line numbers disappear when I re open the laptop and it
>> resumes.
>>
>>
>>
>> 2. After closing the laptop and letting it suspend (or hibernate, same
>> thing), you can't search or search and replace after it resumes. The short
>> cut keys don't work and the menu items are Grey's out.
>>
>>
>>
>> Both the above two are fixed with a netbeans restart.
>>
>>
>>
>> 3. After changing to tablet mode on my laptop, netbeans sometimes gets in
>> to bad state where one window always has the focus no matter which window I
>> try and click in. I can put the mouse pointer in another windows and click
>> and hold to select text but it always does the actions in the window where
>> the focus is stuck
>>
>>
>>
>> This is fixed only by restarting the whole laptop, the problem persists
>> on a restart of netbeans.
>>
>>
>>
>>
>>
>> I appreciate these could be java issues (the last one definitely happened
>> on earlier versions of java and netbeans), but I don't know 100%
>>
>>
>>
>> Thanks
>>
>>
>>
>> Peter
>>
>>
>>
>>

Re: Mouse quirks

[David Gradwell]

Thanks Alan,

I’ve certainly noticed that creating or removing breakpoints can be very tricky 
using (same as you) 11.3 and Mac OS Catalina.

Regards

David Gradwell


From: Alan 
Date: Friday, 1 May 2020 at 07:10
To: "users@netbeans.apache.org" 
Subject: Re: Mouse quirks


It seems there's a fair bit of "I thought it was just me" going around. I've 
made an issue for this.

https://issues.apache.org/jira/browse/NETBEANS-4286
On 2020-05-01 02:00, James Ostrowick wrote:
I’m so glad someone else is having this problem! I thought it was just me.

It drives me nuts trying to create a debug breakpoint as well, sometimes I have 
to click several times to get it to acknowledge the breakpoint insertion.

What I have noticed is that it if you click, pause for about a second and then 
click again it acknowledges the second click better. (When creating breakpoints)
I’ve also found that the external mouse is less accurate than the trackpad for 
some very strange reason, possibly something to do with the resolution of the 
mouse being lower than the trackpad?
So, bluetooth apple mouse clicks tend NOT to be recognised as easily as the 
trackpad.

I first noticed this irritation in NB 10, but its persisted into 11 as well

This is on MacOS X Catalina 10.15.4, NB 11.3




On 01 May 2020, at 07:51, Alan 
mailto:netbeans.5zc...@ambitonline.com>> wrote:

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 
mailto:netbeans.5zc...@ambitonline.com>> 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: 

Re: Gradle based project won't load. How to investigate it or see compiler output?

[Emilian Bold]

This was using Gradle 6 and it seems after doing some more builds and then
configuring Gradle in the options NetBeans is able to load the project...

Odd thing is the IDE did detect the Gradle binary correctly so maybe the
repeat build finally produced something on disk?

It's a big project so I don't know / have time to produce a small sample
that reproduces the problem. I think this would be much easier to track
down if the compiler output would be saved somewhere by the Gradle project
support. It was failing in there for some reason but can't know what it
was. Maybe some -D property to dump this in an output window or in the log?

--emi

mie., 29 apr. 2020, 18:15 Peter Steele  a scris:

> Run the build on the command line to see if it's a netbeans issue, if it
> is then run with With --info or --debug (logging levels) or with
> --stacktrace to get the stack trace info of the build failure.
>
> If it works on the command line then you need to setup gradle properly in
> netbeans.
>
> On Wed, 29 Apr 2020, 07:30 Emilian Bold,  wrote:
>
>> Hello,
>>
>> I have a Gradle based project that won't load in any version of
>> NetBeans, including the 12 beta. The notification shown says:
>>
>> > Compilation failed; see the compiler output for details.
>> > Execution failed for task: ''
>> > Execution failed for task: ''
>> > Could not run build action using Gradle installation '> wrapper dists/ folder>'
>>
>> How does one go about investigating this problem?
>>
>> For starters, I don't see anything in the output window or messages.log.
>>
>> Where is the compiler output with the details?
>>
>> A minor issue: the notification itself (being a Swing component) doesn't
>> allow you to copy-paste the error message.
>>
>> --emi
>>
>

Re: Mouse quirks

[Alan]

It seems there's a fair bit of "I thought it was just me" going around. 
I've made an issue for this.


https://issues.apache.org/jira/browse/NETBEANS-4286

On 2020-05-01 02:00, James Ostrowick wrote:
I’m so glad someone else is having this problem! I thought it was just 
me.


It drives me nuts trying to create a debug breakpoint as well, 
sometimes I have to click several times to get it to acknowledge the 
breakpoint insertion.


What I have noticed is that it if you click, pause for about a second 
and then click again it acknowledges the second click better. (When 
creating breakpoints)
I’ve also found that the external mouse is less accurate than the 
trackpad for some very strange reason, possibly something to do with 
the resolution of the mouse being lower than the trackpad?
So, bluetooth apple mouse clicks tend NOT to be recognised as easily 
as the trackpad.


I first noticed this irritation in NB 10, but its persisted into 11 as 
well


This is on MacOS X Catalina 10.15.4, NB 11.3



On 01 May 2020, at 07:51, Alan > wrote:


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:

Re: Mouse quirks

[James Ostrowick]

I’m so glad someone else is having this problem! I thought it was just me.

It drives me nuts trying to create a debug breakpoint as well, sometimes I have 
to click several times to get it to acknowledge the breakpoint insertion.

What I have noticed is that it if you click, pause for about a second and then 
click again it acknowledges the second click better. (When creating breakpoints)
I’ve also found that the external mouse is less accurate than the trackpad for 
some very strange reason, possibly something to do with the resolution of the 
mouse being lower than the trackpad?
So, bluetooth apple mouse clicks tend NOT to be recognised as easily as the 
trackpad. 

I first noticed this irritation in NB 10, but its persisted into 11 as well 

This is on MacOS X Catalina 10.15.4, NB 11.3



> On 01 May 2020, at 07:51, Alan  wrote:
> 
> 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 
> 
>