from:"Eirik Bakke $Jira$"

[jira] [Comment Edited] (NETBEANS-585) Clicking in Output Window places caret in wrong position

2023-12-17 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798005#comment-17798005
 ] 

Eirik Bakke edited comment on NETBEANS-585 at 12/18/23 4:52 AM:


Ah, I can definitively observe the bug now. In this case I am actually working 
without HiDPI scaling (i.e. using 100% HiDPI scaling), though a different 
scaling level was active when the current Windows 11 session was logged in 
(which sometimes matter when it comes to HiDPI bugs). Making a selection in the 
output pane distorts the text:

!screenshot-1.png!

(Edit: Oh, actually, this is the bug at 
[https://github.com/apache/netbeans/issues/6300] . Clicking by itself appears 
to put the cursor in the correct place. But I bet these two bugs have the same 
cause.)


was (Author: ebakke):
Ah, I can definitively observe the bug now. In this case I am actually working 
without HiDPI scaling (i.e. using 100% HiDPI scaling), though a different 
scaling level was active when the current Windows 11 session was logged in 
(which sometimes matter when it comes to HiDPI bugs). Making a selection in the 
output pane distorts the text:

!screenshot-1.png!

> Clicking in Output Window places caret in wrong position
> 
>
> Key: NETBEANS-585
> URL: https://issues.apache.org/jira/browse/NETBEANS-585
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Output Window
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-245-on-20180327)
> Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11
> Runtime: Java(TM) SE Runtime Environment 9.0.4+11
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb)
> User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev
> Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev
>Reporter: Gili
>Priority: Major
>  Labels: HiDPI
> Attachments: screenshot-1.png
>
>
> Repro steps:
> 1. Run a Java Maven application that outputs to the console
> 2. Click somewhere in a line of text in the Output Window (wrap-text is 
> disabled)
> 3. Notice that the caret lands many characters to the left of where you click
> It is extremely difficult to copy/paste text because we cannot control where 
> the caret begins copy/pasting from.
> This issue might be related to NETBEANS-235



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

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

[jira] [Commented] (NETBEANS-585) Clicking in Output Window places caret in wrong position

2023-12-17 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798005#comment-17798005
 ] 

Eirik Bakke commented on NETBEANS-585:
--

Ah, I can definitively observe the bug now. In this case I am actually working 
without HiDPI scaling (i.e. using 100% HiDPI scaling), though a different 
scaling level was active when the current Windows 11 session was logged in 
(which sometimes matter when it comes to HiDPI bugs). Making a selection in the 
output pane distorts the text:

!screenshot-1.png!

> Clicking in Output Window places caret in wrong position
> 
>
> Key: NETBEANS-585
> URL: https://issues.apache.org/jira/browse/NETBEANS-585
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Output Window
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-245-on-20180327)
> Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11
> Runtime: Java(TM) SE Runtime Environment 9.0.4+11
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb)
> User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev
> Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev
>Reporter: Gili
>Priority: Major
>  Labels: HiDPI
> Attachments: screenshot-1.png
>
>
> Repro steps:
> 1. Run a Java Maven application that outputs to the console
> 2. Click somewhere in a line of text in the Output Window (wrap-text is 
> disabled)
> 3. Notice that the caret lands many characters to the left of where you click
> It is extremely difficult to copy/paste text because we cannot control where 
> the caret begins copy/pasting from.
> This issue might be related to NETBEANS-235



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

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

[jira] [Updated] (NETBEANS-585) Clicking in Output Window places caret in wrong position

2023-12-17 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-585:
-
Attachment: screenshot-1.png

> Clicking in Output Window places caret in wrong position
> 
>
> Key: NETBEANS-585
> URL: https://issues.apache.org/jira/browse/NETBEANS-585
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Output Window
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-245-on-20180327)
> Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11
> Runtime: Java(TM) SE Runtime Environment 9.0.4+11
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb)
> User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev
> Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev
>Reporter: Gili
>Priority: Major
>  Labels: HiDPI
> Attachments: screenshot-1.png
>
>
> Repro steps:
> 1. Run a Java Maven application that outputs to the console
> 2. Click somewhere in a line of text in the Output Window (wrap-text is 
> disabled)
> 3. Notice that the caret lands many characters to the left of where you click
> It is extremely difficult to copy/paste text because we cannot control where 
> the caret begins copy/pasting from.
> This issue might be related to NETBEANS-235



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

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

[jira] [Commented] (NETBEANS-585) Clicking in Output Window places caret in wrong position

2023-12-08 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794834#comment-17794834
 ] 

Eirik Bakke commented on NETBEANS-585:
--

Hmm, at the moment I can't reproduce the issue anymore, even though it was 
there for a very long time. I'm on Windows 11 with 150% HiDPI scaling, on 
NetBeans 18 and Java 17.0.9. It's possible something changed in recent JDK 
versions that impacted font metrics.

Maybe good to hear if others are observing the bug still.

> Clicking in Output Window places caret in wrong position
> 
>
> Key: NETBEANS-585
> URL: https://issues.apache.org/jira/browse/NETBEANS-585
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Output Window
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-245-on-20180327)
> Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11
> Runtime: Java(TM) SE Runtime Environment 9.0.4+11
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb)
> User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev
> Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev
>Reporter: Gili
>Priority: Major
>  Labels: HiDPI
>
> Repro steps:
> 1. Run a Java Maven application that outputs to the console
> 2. Click somewhere in a line of text in the Output Window (wrap-text is 
> disabled)
> 3. Notice that the caret lands many characters to the left of where you click
> It is extremely difficult to copy/paste text because we cannot control where 
> the caret begins copy/pasting from.
> This issue might be related to NETBEANS-235



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

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

[jira] [Resolved] (NETBEANS-1582) HiDPI icons for window system icons on default Linux LAF

2022-12-29 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANS-1582.
---
Resolution: Not A Problem

With FlatLAF now being the default LAF on all platforms, NetBeans automatically 
gets scalable icons by default on Linux. Closing the issue.

> HiDPI icons for window system icons on default Linux LAF
> 
>
> Key: NETBEANS-1582
> URL: https://issues.apache.org/jira/browse/NETBEANS-1582
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Window System
> Environment: Linux
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
>
> To look good on HiDPI displays on Linux, the various icons that are part of 
> NetBeans' window system must be made scalable to arbitrary resolutions. This 
> includes, for instance, the "X" button that is used to close tabs and the "_" 
> button that collapses a sidebar. These icons reside in the tabcontrol and 
> openide.awt modules.
> The pull request at [https://github.com/apache/incubator-netbeans/pull/859] 
> already did this work for the MacOS and Windows LAFs (see NETBEANS-1260 and 
> NETBEANS-1238, respectively). Using the same approach, it should now be 
> relatively easy to do the same on Linux. Or more specifically, whichever LAF 
> is the default on, say, Ubuntu (I'm not sure myself).
> This issue does _not_ cover the equivalent work on the Darcula plugin; that 
> would be a separate effort (see 
> [https://github.com/Revivius/nb-darcula/issues/160] ).
> (The author of the PR above does not have a Linux machine handily available, 
> and so only did the work for Windows and MacOS. Note that these icons are 
> more or less the only ones that are different from one LAF to another.)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

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

[jira] [Resolved] (NETBEANS-5928) Proposed improvements to FlatLAF tab components+borders/margins

2022-07-10 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANS-5928.
---
Resolution: Fixed

Resolved by the following PRs:

https://github.com/apache/netbeans/pull/3992
https://github.com/apache/netbeans/pull/4286
https://github.com/apache/netbeans/pull/4335
https://github.com/apache/netbeans/pull/4349


> Proposed improvements to FlatLAF tab components+borders/margins
> ---
>
> Key: NETBEANS-5928
> URL: https://issues.apache.org/jira/browse/NETBEANS-5928
> Project: NetBeans
>  Issue Type: Improvement
>  Components: FlatLaf
>Affects Versions: 12.4
> Environment: Windows, MacOS, and Linux with FlatLAF Light and FlatLAF 
> Dark
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, pull-request-available
> Attachments: flatlaf-dark-1-before.png, flatlaf-dark-2-after.png, 
> flatlaf-light-1-before.png, flatlaf-light-2-after.png
>
>  Time Spent: 9h 50m
>  Remaining Estimate: 0h
>
> In a previous PR ( https://github.com/apache/netbeans/pull/2967 ), the tab 
> components in the NetBeans window system were redesigned and modernized for 
> the Windows LAF. This PR ports related tabcontrol improvements back into 
> FlatLAF, and proposes a similar tab style for FlatLAF. See the attached 
> screenshots.
> The proposed style, compared to the current FlatLAF style, makes the selected 
> tab look like an actual "tab" with an actual rectangular border around it, 
> while keeping the much simpler "separators only" look for unselected tabs. 
> The proposed style also tightens up vertical space significantly, like in 
> other LAFs. See the attached screenshots. The new tab controls work well on 
> all HiDPI scaling levels, and on all platforms (Windows, Linux, MacOS).
> Advantages of the proposed tabcontrol style:
> * Other applications that have tabs as part of their window system still tend 
> to render at least the active window system tab as an actual "tabs", e.g. 
> Chrome, Excel, Photoshop, Unity.
> * Personally, I find it hard to orient my eyes around the old FlatLAF tab 
> style; the drawn selected tab seems to fix this. (Hard to explain in a fully 
> objective way!)
> * The tab content areas (contents of editor, projects pane, navigator pane 
> etc.) has borders around them, so it is logical that the border continues 
> around the tab that is associated with them.
> * Conserve vertical space. Modern monitors have tended to become wider but 
> not taller. With e.g. 2x HiDPI scaling (as on all MacBooks), there may 
> actually be _fewer_ logical pixels available in the vertical direction than 
> on older laptop screens.
> This PR also removes an extraneous border around the editor area, and 
> introduces a little bit of extra space in the toolbar area.
> I've been using FlatLAF as the default LAF on Linux for my NetBeans Platform 
> application. It handles HiDPI scaling very well, and it's getting really 
> solid--thanks to @DevCharly for all his work on it!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

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

[jira] [Resolved] (NETBEANS-2360) HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux

2022-04-19 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANS-2360.
---
Resolution: Fixed

PR was merged; closing issue.

> HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux
> ---
>
> Key: NETBEANS-2360
> URL: https://issues.apache.org/jira/browse/NETBEANS-2360
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 11.0, 12.2
> Environment: Kubuntu 18.03
> Oracle JDK 11.0.2
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, Linux, pull-request-available
> Attachments: CheckHiDpi.java, image-2021-09-12-21-01-33-807.png, 
> image-2021-09-12-21-05-06-852.png, kubunt.jpg
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Running NetBeans 11 on Kubuntu 18.03, GUI text size does not seem to take 
> into account the system's default HiDPI scaling. This was reported in a 
> Twitter thread on https://twitter.com/nicktail/status/1114789604337405952 . 
> Note that Window decorations seem to be the correct size.
> Setting the GDK_SCALE environment variable seems to fix the problem, if I 
> understand the originally reporter correctly. This could probably be done 
> easily from the NetBeans launcher script (netbeans/bin). But it wouldn't fix 
> the problem in multi-monitor setups. We should investigate what could be done 
> to make scaling work properly in multi-monitor setups involving one HiDPI 
> screen and one non-HiDPI screen.
> Before merging a patch to the launcher script, it should be tested on a 
> couple of different Linux environments, using both HiDPI and non-HiDPI 
> screens. Note that the UNIX launcher script is also used on MacOS.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

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

[jira] [Commented] (NETBEANS-2360) HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux

2022-04-19 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524597#comment-17524597
 ] 

Eirik Bakke commented on NETBEANS-2360:
---

Thanks, [~hlavki]! With the PR merged, I'll close this issue as I think the 
script now does as much auto-detection as is possible on the various platforms.

> HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux
> ---
>
> Key: NETBEANS-2360
> URL: https://issues.apache.org/jira/browse/NETBEANS-2360
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 11.0, 12.2
> Environment: Kubuntu 18.03
> Oracle JDK 11.0.2
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, Linux, pull-request-available
> Attachments: CheckHiDpi.java, image-2021-09-12-21-01-33-807.png, 
> image-2021-09-12-21-05-06-852.png, kubunt.jpg
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Running NetBeans 11 on Kubuntu 18.03, GUI text size does not seem to take 
> into account the system's default HiDPI scaling. This was reported in a 
> Twitter thread on https://twitter.com/nicktail/status/1114789604337405952 . 
> Note that Window decorations seem to be the correct size.
> Setting the GDK_SCALE environment variable seems to fix the problem, if I 
> understand the originally reporter correctly. This could probably be done 
> easily from the NetBeans launcher script (netbeans/bin). But it wouldn't fix 
> the problem in multi-monitor setups. We should investigate what could be done 
> to make scaling work properly in multi-monitor setups involving one HiDPI 
> screen and one non-HiDPI screen.
> Before merging a patch to the launcher script, it should be tested on a 
> couple of different Linux environments, using both HiDPI and non-HiDPI 
> screens. Note that the UNIX launcher script is also used on MacOS.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

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

[jira] [Commented] (NETBEANS-2360) HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux

2022-04-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517388#comment-17517388
 ] 

Eirik Bakke commented on NETBEANS-2360:
---

Thanks, Javier. I suppose the xdpyinfo DPI probably comes from the screen 
itself rather than the global scale.

> HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux
> ---
>
> Key: NETBEANS-2360
> URL: https://issues.apache.org/jira/browse/NETBEANS-2360
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 11.0, 12.2
> Environment: Kubuntu 18.03
> Oracle JDK 11.0.2
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, Linux, pull-request-available
> Attachments: CheckHiDpi.java, image-2021-09-12-21-01-33-807.png, 
> image-2021-09-12-21-05-06-852.png, kubunt.jpg
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Running NetBeans 11 on Kubuntu 18.03, GUI text size does not seem to take 
> into account the system's default HiDPI scaling. This was reported in a 
> Twitter thread on https://twitter.com/nicktail/status/1114789604337405952 . 
> Note that Window decorations seem to be the correct size.
> Setting the GDK_SCALE environment variable seems to fix the problem, if I 
> understand the originally reporter correctly. This could probably be done 
> easily from the NetBeans launcher script (netbeans/bin). But it wouldn't fix 
> the problem in multi-monitor setups. We should investigate what could be done 
> to make scaling work properly in multi-monitor setups involving one HiDPI 
> screen and one non-HiDPI screen.
> Before merging a patch to the launcher script, it should be tested on a 
> couple of different Linux environments, using both HiDPI and non-HiDPI 
> screens. Note that the UNIX launcher script is also used on MacOS.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-2360) HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux

2022-04-03 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516604#comment-17516604
 ] 

Eirik Bakke commented on NETBEANS-2360:
---

Hi, Javier!

As you may have noticed, Java only supports either 1x or 2x HiDPI scaling on 
Linux. So the script I provided only applies the 2x scaling when the desktop's 
scaling is exactly 2x (192 dots per inch). In your case it seems you have 
configured a 162/96=1.6875x scaling factor? Could this be right?

Could you try setting your desktop's HiDPI scaling to exactly 200%, and then 
see if the script picks up on that?

(I suppose I could change the script to scale NetBeans to 2x if the desktop's 
scaling level is more than 1.5x, or perhaps some higher threshold. But I 
figured it was better to let the user increase their font size instead in these 
cases.)

-- Eirik


> HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux
> ---
>
> Key: NETBEANS-2360
> URL: https://issues.apache.org/jira/browse/NETBEANS-2360
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 11.0, 12.2
> Environment: Kubuntu 18.03
> Oracle JDK 11.0.2
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, Linux, pull-request-available
> Attachments: CheckHiDpi.java, image-2021-09-12-21-01-33-807.png, 
> image-2021-09-12-21-05-06-852.png, kubunt.jpg
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Running NetBeans 11 on Kubuntu 18.03, GUI text size does not seem to take 
> into account the system's default HiDPI scaling. This was reported in a 
> Twitter thread on https://twitter.com/nicktail/status/1114789604337405952 . 
> Note that Window decorations seem to be the correct size.
> Setting the GDK_SCALE environment variable seems to fix the problem, if I 
> understand the originally reporter correctly. This could probably be done 
> easily from the NetBeans launcher script (netbeans/bin). But it wouldn't fix 
> the problem in multi-monitor setups. We should investigate what could be done 
> to make scaling work properly in multi-monitor setups involving one HiDPI 
> screen and one non-HiDPI screen.
> Before merging a patch to the launcher script, it should be tested on a 
> couple of different Linux environments, using both HiDPI and non-HiDPI 
> screens. Note that the UNIX launcher script is also used on MacOS.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Resolved] (NETBEANSINFRA-263) NetBeans Module plugin fails to wrap Java 17 JARs

2022-02-26 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANSINFRA-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANSINFRA-263.
---
Resolution: Fixed

Already fixed in nbm-maven-plugin 4.7.

> NetBeans Module plugin fails to wrap Java 17 JARs
> -
>
> Key: NETBEANSINFRA-263
> URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-263
> Project: Apache NetBeans Infra
>  Issue Type: Bug
>  Components: MU - Apache NetBeans NBM maven plugin
> Environment: OpenJDK 17.0.2
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: pom.xml
>
>
> The nbm-maven-plugin seems to have trouble wrapping JARs that have Java 17 
> level class files in them. To reproduce, create an empty folder containing 
> the attached pom.xml file and run "mvn install". The following error appears:
> "Failed to execute goal 
> org.apache.netbeans.utilities:nbm-maven-plugin:4.6:manifest 
> (default-manifest) on project jdbc-mssql: Execution default-manifest of goal 
> org.apache.netbeans.utilities:nbm-maven-plugin:4.6:manifest failed: 
> Unsupported class file major version 61 -> [Help 1]"
> Changing the external JAR version from 10.2.0.jre17 to 10.2.0.jre11 makes the 
> build succeed.
> (Per the readme on 
> https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin , and since 
> this is a different JIRA project, submitting this bug via JIRA rather than on 
> GitHub.)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANSINFRA-263) NetBeans Module plugin fails to wrap Java 17 JARs

2022-02-26 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANSINFRA-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498486#comment-17498486
 ] 

Eirik Bakke commented on NETBEANSINFRA-263:
---

Ah, great! I tested my POM with the MSSQL JDBC driver version 10.2.0.jre17 and 
the latest nbm-maven-plugin version 4.7, and it works. Thanks!

> NetBeans Module plugin fails to wrap Java 17 JARs
> -
>
> Key: NETBEANSINFRA-263
> URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-263
> Project: Apache NetBeans Infra
>  Issue Type: Bug
>  Components: MU - Apache NetBeans NBM maven plugin
> Environment: OpenJDK 17.0.2
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: pom.xml
>
>
> The nbm-maven-plugin seems to have trouble wrapping JARs that have Java 17 
> level class files in them. To reproduce, create an empty folder containing 
> the attached pom.xml file and run "mvn install". The following error appears:
> "Failed to execute goal 
> org.apache.netbeans.utilities:nbm-maven-plugin:4.6:manifest 
> (default-manifest) on project jdbc-mssql: Execution default-manifest of goal 
> org.apache.netbeans.utilities:nbm-maven-plugin:4.6:manifest failed: 
> Unsupported class file major version 61 -> [Help 1]"
> Changing the external JAR version from 10.2.0.jre17 to 10.2.0.jre11 makes the 
> build succeed.
> (Per the readme on 
> https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin , and since 
> this is a different JIRA project, submitting this bug via JIRA rather than on 
> GitHub.)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Created] (NETBEANSINFRA-263) NetBeans Module plugin fails to wrap Java 17 JARs

2022-02-22 Thread Eirik Bakke (Jira)

Eirik Bakke created NETBEANSINFRA-263:
-

 Summary: NetBeans Module plugin fails to wrap Java 17 JARs
 Key: NETBEANSINFRA-263
 URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-263
 Project: Apache NetBeans Infra
  Issue Type: Bug
  Components: MU - Apache NetBeans NBM maven plugin
 Environment: OpenJDK 17.0.2
Reporter: Eirik Bakke
 Attachments: pom.xml

The nbm-maven-plugin seems to have trouble wrapping JARs that have Java 17 
level class files in them. To reproduce, create an empty folder containing the 
attached pom.xml file and run "mvn install". The following error appears:

"Failed to execute goal 
org.apache.netbeans.utilities:nbm-maven-plugin:4.6:manifest (default-manifest) 
on project jdbc-mssql: Execution default-manifest of goal 
org.apache.netbeans.utilities:nbm-maven-plugin:4.6:manifest failed: Unsupported 
class file major version 61 -> [Help 1]"

Changing the external JAR version from 10.2.0.jre17 to 10.2.0.jre11 makes the 
build succeed.

(Per the readme on 
https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin , and since this 
is a different JIRA project, submitting this bug via JIRA rather than on 
GitHub.)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-2360) HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux

2022-02-20 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17495209#comment-17495209
 ] 

Eirik Bakke commented on NETBEANS-2360:
---

Thanks, Michal! I have updated the NetBeans launcher script at 
https://github.com/apache/netbeans/pull/3113 to try to detect the condition you 
described. Could you try to see if it works?

Specifically, could you:
1) Try to launch NetBeans with the new version of the launcher script, and see 
if the "Detected 192 DPI on all screens in xdpyinfo" message is shown and 
NetBeans is now scaled appropriately?
2) Temporarily turn off 2x HiDPI scaling on your window system, and relaunch 
NetBeans, confirming that the message above no longer appears and NetBeans no 
longer scales 2x?
3) Turn 2x HIDPI scaling back on on your window system, and relaunch NetBeans, 
and seeing that the message once again appears and NetBeans is scaled 
appropriately?

Thanks for your help!

-- Eirik


> HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux
> ---
>
> Key: NETBEANS-2360
> URL: https://issues.apache.org/jira/browse/NETBEANS-2360
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 11.0, 12.2
> Environment: Kubuntu 18.03
> Oracle JDK 11.0.2
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, Linux, pull-request-available
> Attachments: CheckHiDpi.java, image-2021-09-12-21-01-33-807.png, 
> image-2021-09-12-21-05-06-852.png, kubunt.jpg
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Running NetBeans 11 on Kubuntu 18.03, GUI text size does not seem to take 
> into account the system's default HiDPI scaling. This was reported in a 
> Twitter thread on https://twitter.com/nicktail/status/1114789604337405952 . 
> Note that Window decorations seem to be the correct size.
> Setting the GDK_SCALE environment variable seems to fix the problem, if I 
> understand the originally reporter correctly. This could probably be done 
> easily from the NetBeans launcher script (netbeans/bin). But it wouldn't fix 
> the problem in multi-monitor setups. We should investigate what could be done 
> to make scaling work properly in multi-monitor setups involving one HiDPI 
> screen and one non-HiDPI screen.
> Before merging a patch to the launcher script, it should be tested on a 
> couple of different Linux environments, using both HiDPI and non-HiDPI 
> screens. Note that the UNIX launcher script is also used on MacOS.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Updated] (NETBEANS-6468) Windows LAF does not work properly on Windows 11 with Java 17

2022-02-19 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-6468:
--
Environment: Windows 11 and Java 17, when running NetBeans with the Windows 
LAF.  (was: Windows 11 and Java 17.)

> Windows LAF does not work properly on Windows 11 with Java 17
> -
>
> Key: NETBEANS-6468
> URL: https://issues.apache.org/jira/browse/NETBEANS-6468
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 12.6
> Environment: Windows 11 and Java 17, when running NetBeans with the 
> Windows LAF.
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: 220219 LAF Detection Problem.png
>
>
> Various NetBeans LAF-related code reverts to an older look if the "os.name" 
> system property does not contain the string "Windows 10". With Java 17, the 
> "os.name" property may now return "Windows 11", leading to odd-looking UI tab 
> components on NetBeans when running on the Windows LAF.
> I'll submit a PR to fix this.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Updated] (NETBEANS-6468) Windows LAF does not work properly on Windows 11 with Java 17

2022-02-19 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-6468:
--
Attachment: 220219 LAF Detection Problem.png

> Windows LAF does not work properly on Windows 11 with Java 17
> -
>
> Key: NETBEANS-6468
> URL: https://issues.apache.org/jira/browse/NETBEANS-6468
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 12.6
> Environment: Windows 11 and Java 17.
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: 220219 LAF Detection Problem.png
>
>
> Various NetBeans LAF-related code reverts to an older look if the "os.name" 
> system property does not contain the string "Windows 10". With Java 17, the 
> "os.name" property may now return "Windows 11", leading to odd-looking UI tab 
> components on NetBeans when running on the Windows LAF.
> I'll submit a PR to fix this.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Created] (NETBEANS-6468) Windows LAF does not work properly on Windows 11 with Java 17

2022-02-19 Thread Eirik Bakke (Jira)

Eirik Bakke created NETBEANS-6468:
-

 Summary: Windows LAF does not work properly on Windows 11 with 
Java 17
 Key: NETBEANS-6468
 URL: https://issues.apache.org/jira/browse/NETBEANS-6468
 Project: NetBeans
  Issue Type: Bug
  Components: platform - Window System
Affects Versions: 12.6
 Environment: Windows 11 and Java 17.
Reporter: Eirik Bakke


Various NetBeans LAF-related code reverts to an older look if the "os.name" 
system property does not contain the string "Windows 10". With Java 17, the 
"os.name" property may now return "Windows 11", leading to odd-looking UI tab 
components on NetBeans when running on the Windows LAF.

I'll submit a PR to fix this.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-5896) Missing "com.sun.tools.javac.comp.Enter.unenter" with vanilla javac

2022-02-08 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488944#comment-17488944
 ] 

Eirik Bakke commented on NETBEANS-5896:
---

[~jtulach] Thanks! That's useful.

> Missing "com.sun.tools.javac.comp.Enter.unenter" with vanilla javac
> ---
>
> Key: NETBEANS-5896
> URL: https://issues.apache.org/jira/browse/NETBEANS-5896
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Compiler
>Affects Versions: 12.4
> Environment: Java 11.0.11 on Windows 10 on NetBeans 12.4 with vanilla 
> javac (nb-javac _not_ installed)
>Reporter: Eirik Bakke
>Assignee: Jan Lahoda
>Priority: Major
>
> Working with Compile-on-Save enabled on a Maven-based NetBeans Platform 
> project, with vanilla javac (nb-javac _not_ installed), I frequently get the 
> following stack trace:
> {noformat}
> java.lang.NoSuchMethodException: 
> com.sun.tools.javac.comp.Enter.unenter(com.sun.tools.javac.tree.JCTree$JCCompilationUnit,
>  com.sun.tools.javac.tree.JCTree)
>   at java.base/java.lang.Class.getDeclaredMethod(Class.java:2475)
>   at 
> org.netbeans.api.java.source.TreeUtilities.unenter(TreeUtilities.java:927)
>   at 
> org.netbeans.api.java.source.TreeUtilities.attributeTree(TreeUtilities.java:916)
>   at 
> org.netbeans.api.java.source.TreeUtilities.attributeTree(TreeUtilities.java:845)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$1.run(DeclarativeHintsParser.java:502)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$1.run(DeclarativeHintsParser.java:477)
>   at 
> org.netbeans.modules.java.source.parsing.MimeTask.run(MimeTask.java:60)
>   at 
> org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
>   at 
> org.netbeans.modules.parsing.api.ParserManager$MimeTaskAction.run(ParserManager.java:357)
>   at 
> org.netbeans.modules.parsing.api.ParserManager$MimeTaskAction.run(ParserManager.java:340)
>   at 
> org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
>   at 
> org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
>   at 
> org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
>   at 
> org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
>   at 
> org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
>   at 
> org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
>   at 
> org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
>   at 
> org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:311)
>   at 
> org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:431)
>   at 
> org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:423)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser.resolve(DeclarativeHintsParser.java:477)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser.access$000(DeclarativeHintsParser.java:83)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseCondition(DeclarativeHintsParser.java:311)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseConditions(DeclarativeHintsParser.java:258)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseRule(DeclarativeHintsParser.java:215)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseInput(DeclarativeHintsParser.java:184)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.access$200(DeclarativeHintsParser.java:90)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser.parse(DeclarativeHintsParser.java:395)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintRegistry.parseHints(DeclarativeHintRegistry.java:263)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintRegistry.parseHintFile(DeclarativeHintRegistry.java:239)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintRegistry.readHints(DeclarativeHintRegistry.java:128)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintRegistry.computeHints(DeclarativeHintRegistry.java:111)
>   at 
> org.netbeans.modules.java.hints.spiimpl.RulesManagerImpl.readHints(RulesManagerImpl.java:139)
>   at 
> org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:133)
>   at 
>

[jira] [Commented] (NETBEANS-5896) Missing "com.sun.tools.javac.comp.Enter.unenter" with vanilla javac

2022-02-07 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488492#comment-17488492
 ] 

Eirik Bakke commented on NETBEANS-5896:
---

OK, that's very informative. Thank you!

> Missing "com.sun.tools.javac.comp.Enter.unenter" with vanilla javac
> ---
>
> Key: NETBEANS-5896
> URL: https://issues.apache.org/jira/browse/NETBEANS-5896
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Compiler
>Affects Versions: 12.4
> Environment: Java 11.0.11 on Windows 10 on NetBeans 12.4 with vanilla 
> javac (nb-javac _not_ installed)
>Reporter: Eirik Bakke
>Assignee: Jan Lahoda
>Priority: Major
>
> Working with Compile-on-Save enabled on a Maven-based NetBeans Platform 
> project, with vanilla javac (nb-javac _not_ installed), I frequently get the 
> following stack trace:
> {noformat}
> java.lang.NoSuchMethodException: 
> com.sun.tools.javac.comp.Enter.unenter(com.sun.tools.javac.tree.JCTree$JCCompilationUnit,
>  com.sun.tools.javac.tree.JCTree)
>   at java.base/java.lang.Class.getDeclaredMethod(Class.java:2475)
>   at 
> org.netbeans.api.java.source.TreeUtilities.unenter(TreeUtilities.java:927)
>   at 
> org.netbeans.api.java.source.TreeUtilities.attributeTree(TreeUtilities.java:916)
>   at 
> org.netbeans.api.java.source.TreeUtilities.attributeTree(TreeUtilities.java:845)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$1.run(DeclarativeHintsParser.java:502)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$1.run(DeclarativeHintsParser.java:477)
>   at 
> org.netbeans.modules.java.source.parsing.MimeTask.run(MimeTask.java:60)
>   at 
> org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
>   at 
> org.netbeans.modules.parsing.api.ParserManager$MimeTaskAction.run(ParserManager.java:357)
>   at 
> org.netbeans.modules.parsing.api.ParserManager$MimeTaskAction.run(ParserManager.java:340)
>   at 
> org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
>   at 
> org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
>   at 
> org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
>   at 
> org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
>   at 
> org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
>   at 
> org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
>   at 
> org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
>   at 
> org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:311)
>   at 
> org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:431)
>   at 
> org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:423)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser.resolve(DeclarativeHintsParser.java:477)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser.access$000(DeclarativeHintsParser.java:83)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseCondition(DeclarativeHintsParser.java:311)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseConditions(DeclarativeHintsParser.java:258)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseRule(DeclarativeHintsParser.java:215)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseInput(DeclarativeHintsParser.java:184)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.access$200(DeclarativeHintsParser.java:90)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser.parse(DeclarativeHintsParser.java:395)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintRegistry.parseHints(DeclarativeHintRegistry.java:263)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintRegistry.parseHintFile(DeclarativeHintRegistry.java:239)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintRegistry.readHints(DeclarativeHintRegistry.java:128)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintRegistry.computeHints(DeclarativeHintRegistry.java:111)
>   at 
> org.netbeans.modules.java.hints.spiimpl.RulesManagerImpl.readHints(RulesManagerImpl.java:139)
>   at 
> org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:133)
>   at 
>

[jira] [Commented] (NETBEANS-5896) Missing "com.sun.tools.javac.comp.Enter.unenter" with vanilla javac

2022-02-07 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488397#comment-17488397
 ] 

Eirik Bakke commented on NETBEANS-5896:
---

OK, good to know. What's the latest long-term plan for nb-javac vs. vanilla 
javac? Is nb-javac going to be the recommended solution for the next few years? 
Or were we trying to migrate away from it?

> Missing "com.sun.tools.javac.comp.Enter.unenter" with vanilla javac
> ---
>
> Key: NETBEANS-5896
> URL: https://issues.apache.org/jira/browse/NETBEANS-5896
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Compiler
>Affects Versions: 12.4
> Environment: Java 11.0.11 on Windows 10 on NetBeans 12.4 with vanilla 
> javac (nb-javac _not_ installed)
>Reporter: Eirik Bakke
>Assignee: Jan Lahoda
>Priority: Major
>
> Working with Compile-on-Save enabled on a Maven-based NetBeans Platform 
> project, with vanilla javac (nb-javac _not_ installed), I frequently get the 
> following stack trace:
> {noformat}
> java.lang.NoSuchMethodException: 
> com.sun.tools.javac.comp.Enter.unenter(com.sun.tools.javac.tree.JCTree$JCCompilationUnit,
>  com.sun.tools.javac.tree.JCTree)
>   at java.base/java.lang.Class.getDeclaredMethod(Class.java:2475)
>   at 
> org.netbeans.api.java.source.TreeUtilities.unenter(TreeUtilities.java:927)
>   at 
> org.netbeans.api.java.source.TreeUtilities.attributeTree(TreeUtilities.java:916)
>   at 
> org.netbeans.api.java.source.TreeUtilities.attributeTree(TreeUtilities.java:845)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$1.run(DeclarativeHintsParser.java:502)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$1.run(DeclarativeHintsParser.java:477)
>   at 
> org.netbeans.modules.java.source.parsing.MimeTask.run(MimeTask.java:60)
>   at 
> org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
>   at 
> org.netbeans.modules.parsing.api.ParserManager$MimeTaskAction.run(ParserManager.java:357)
>   at 
> org.netbeans.modules.parsing.api.ParserManager$MimeTaskAction.run(ParserManager.java:340)
>   at 
> org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
>   at 
> org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
>   at 
> org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
>   at 
> org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
>   at 
> org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
>   at 
> org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
>   at 
> org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
>   at 
> org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:311)
>   at 
> org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:431)
>   at 
> org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:423)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser.resolve(DeclarativeHintsParser.java:477)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser.access$000(DeclarativeHintsParser.java:83)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseCondition(DeclarativeHintsParser.java:311)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseConditions(DeclarativeHintsParser.java:258)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseRule(DeclarativeHintsParser.java:215)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseInput(DeclarativeHintsParser.java:184)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.access$200(DeclarativeHintsParser.java:90)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser.parse(DeclarativeHintsParser.java:395)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintRegistry.parseHints(DeclarativeHintRegistry.java:263)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintRegistry.parseHintFile(DeclarativeHintRegistry.java:239)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintRegistry.readHints(DeclarativeHintRegistry.java:128)
>   at 
> org.netbeans.modules.java.hints.declarative.DeclarativeHintRegistry.computeHints(DeclarativeHintRegistry.java:111)
>   at 
>

[jira] [Commented] (NETBEANS-585) Clicking in Output Window places caret in wrong position

2022-01-30 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484455#comment-17484455
 ] 

Eirik Bakke commented on NETBEANS-585:
--

[~ebresie] I think the specific classes mentioned in NETBEANS-4166 are not used 
in the Output pane; it seems to roll its own thing (maybe because it's supposed 
to handle millions of lines etc.).

> Clicking in Output Window places caret in wrong position
> 
>
> Key: NETBEANS-585
> URL: https://issues.apache.org/jira/browse/NETBEANS-585
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Output Window
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-245-on-20180327)
> Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11
> Runtime: Java(TM) SE Runtime Environment 9.0.4+11
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb)
> User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev
> Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev
>Reporter: Gili
>Priority: Major
>  Labels: HiDPI
>
> Repro steps:
> 1. Run a Java Maven application that outputs to the console
> 2. Click somewhere in a line of text in the Output Window (wrap-text is 
> disabled)
> 3. Notice that the caret lands many characters to the left of where you click
> It is extremely difficult to copy/paste text because we cannot control where 
> the caret begins copy/pasting from.
> This issue might be related to NETBEANS-235



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-585) Clicking in Output Window places caret in wrong position

2022-01-30 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484384#comment-17484384
 ] 

Eirik Bakke commented on NETBEANS-585:
--

[~ebresie] I don't think Maven vs. Ant should make a difference here, but there 
might be certain differences that cause the bug to be more or less visible, 
e.g. default zoom level in the output window, line wrapping enabled or 
disabled, which monitor the output window first opened on, or the actual 
contents of the output pane, or things like that.

> Clicking in Output Window places caret in wrong position
> 
>
> Key: NETBEANS-585
> URL: https://issues.apache.org/jira/browse/NETBEANS-585
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Output Window
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-245-on-20180327)
> Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11
> Runtime: Java(TM) SE Runtime Environment 9.0.4+11
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb)
> User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev
> Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev
>Reporter: Gili
>Priority: Major
>  Labels: HiDPI
>
> Repro steps:
> 1. Run a Java Maven application that outputs to the console
> 2. Click somewhere in a line of text in the Output Window (wrap-text is 
> disabled)
> 3. Notice that the caret lands many characters to the left of where you click
> It is extremely difficult to copy/paste text because we cannot control where 
> the caret begins copy/pasting from.
> This issue might be related to NETBEANS-235



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Comment Edited] (NETBEANS-585) Clicking in Output Window places caret in wrong position

2022-01-30 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484382#comment-17484382
 ] 

Eirik Bakke edited comment on NETBEANS-585 at 1/30/22, 4:49 PM:


My best guess is that some hit testing and/or selection painting code is 
assuming integer character advances in the output window. This could cause 
trouble on Windows even when HiDPI scaling is disabled, since character 
advances on Windows are calculated in 1/3rd pixel increments due to sub-pixel 
rendering. See https://github.com/apache/netbeans/pull/2076 for a similar type 
of bug in the main code editor.

(As mentioned on the mailing list, the problem is probably somewhere around 
o.n.core.output2.OutputEditorKit.)


was (Author: ebakke):
My best guess is that some hit testing and/or selection painting code is 
assuming integer character advances in the output window. This could cause 
trouble on Windows even when HiDPI scaling is disabled, since character 
advances on Windows are calculated in 1/3rd pixel increments due to sub-pixel 
rendering. See https://github.com/apache/netbeans/pull/2076 for a similar type 
of bug in the editor code.

(As mentioned on the mailing list, the problem is probably somewhere around 
o.n.core.output2.OutputEditorKit.)

> Clicking in Output Window places caret in wrong position
> 
>
> Key: NETBEANS-585
> URL: https://issues.apache.org/jira/browse/NETBEANS-585
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Output Window
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-245-on-20180327)
> Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11
> Runtime: Java(TM) SE Runtime Environment 9.0.4+11
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb)
> User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev
> Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev
>Reporter: Gili
>Priority: Major
>  Labels: HiDPI
>
> Repro steps:
> 1. Run a Java Maven application that outputs to the console
> 2. Click somewhere in a line of text in the Output Window (wrap-text is 
> disabled)
> 3. Notice that the caret lands many characters to the left of where you click
> It is extremely difficult to copy/paste text because we cannot control where 
> the caret begins copy/pasting from.
> This issue might be related to NETBEANS-235



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-585) Clicking in Output Window places caret in wrong position

2022-01-30 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484382#comment-17484382
 ] 

Eirik Bakke commented on NETBEANS-585:
--

My best guess is that some hit testing and/or selection painting code is 
assuming integer character advances in the output window. This could cause 
trouble on Windows even when HiDPI scaling is disabled, since character 
advances on Windows are calculated in 1/3rd pixel increments due to sub-pixel 
rendering. See https://github.com/apache/netbeans/pull/2076 for a similar type 
of bug in the editor code.

(As mentioned on the mailing list, the problem is probably somewhere around 
o.n.core.output2.OutputEditorKit.)

> Clicking in Output Window places caret in wrong position
> 
>
> Key: NETBEANS-585
> URL: https://issues.apache.org/jira/browse/NETBEANS-585
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Output Window
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-245-on-20180327)
> Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11
> Runtime: Java(TM) SE Runtime Environment 9.0.4+11
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb)
> User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev
> Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev
>Reporter: Gili
>Priority: Major
>  Labels: HiDPI
>
> Repro steps:
> 1. Run a Java Maven application that outputs to the console
> 2. Click somewhere in a line of text in the Output Window (wrap-text is 
> disabled)
> 3. Notice that the caret lands many characters to the left of where you click
> It is extremely difficult to copy/paste text because we cannot control where 
> the caret begins copy/pasting from.
> This issue might be related to NETBEANS-235



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-2617) Redraw common icons in SVG

2022-01-19 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478829#comment-17478829
 ] 

Eirik Bakke commented on NETBEANS-2617:
---

And here's a screencast of the icon drawing process that was used for the first 
50 icons: https://vimeo.com/manage/videos/667860571

> Redraw common icons in SVG
> --
>
> Key: NETBEANS-2617
> URL: https://issues.apache.org/jira/browse/NETBEANS-2617
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 11.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: 210604 Icons Overview Cropped.png, 211228 Consolidated 
> Icons.ai, 220101 Updated Dark Filter Test.png, ScreenshotExample.png, 
> ide.editor.bookmarks.ai, ide.editor.macros.ai, ide.seperator.breadcrumbs.ai, 
> image-2022-01-19-14-41-29-967.png, netbeans_icons_illustrator_template.ai, 
> style example (dark filter).png, style example.png
>
>
> Once NETBEANS-2604 is done, we should start replacing commonly seen NetBeans 
> icons with SVG versions, for improved appearance on Retina/HiDPI displays.
> h2. UPDATE: 
> [Here|https://docs.google.com/spreadsheets/d/1U_pj-I3hk9Wj_7lvHcUDsZfFfBSyCkSGqBuv0qt_qXw/edit?usp=sharing]
>  is a Google Sheet where we can track progress of contributions and 
> prioritization of icons.
> With some practice, it takes on average 30 minutes to create an SVG version 
> of a typical icon in Adobe Illustrator. See the attached illustration and 
> Illustrator template. The Illustrator template includes a few icons which 
> have already been converted.
> In NETBEANS-2605, a prioritized list of icons to convert was produced (now 
> migrated to the Google Sheet above). By redrawing the most commonly seen 
> icons first, we can get the greatest "bang for the buck" in terms of 
> improving NetBeans' appearance on HiDPI displays. Once we have a batch of 
> icons ready to integrate into the NetBeans repository, Eirik will redo the 
> duplicate detection and ensure the SVGs end up in all relevant locations, and 
> start creating pull requests.
> See also the overview page for HiDPI improvements on 
> https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements
>  .
> If you wish to contribute to this effort, comment here; Eirik will coordinate 
> to make sure multiple people are not working on the same icons.
> h2. Proposed Style Guide for Vectorized Icons
> *[See tutorial video here.|https://vimeo.com/667860571]*
> * Vector icons should be drawn in Adobe Illustrator, or alternatively 
> Inkscape or another free tool. In Illustrator, each icon should be one named 
> artboard, sized to the correct size in pixels. See the attached Illustrator 
> template. (Adobe Illustrator comes with a free 7-day trial, after which it's 
> $35/month. If cost is a problem but you want to contribute your time to draw 
> icons, ask Eirik...)
> * If you prefer to use Inkscape instead, and want to contribute icons, that's 
> fine; just make sure to follow the same consistent style as the other icons. 
> If using Inkscape, perhaps pick another group of icons than the ones that are 
> currently being drawn in Illustrator. It's best to draw all similar-looking 
> icons in the same tool.
> * For each icon to be vectorized, place the old bitmap version of the icon in 
> a separate layer ("Old Bitmap Icons" in the Illustrator template). You can 
> then draw the vectorized version on top.
> * Since most of the existing NetBeans icons follow a quite consistent visual 
> style, and to simplify the job of creating new icons, it is best to keep the 
> shape of the new vectorized icons the same as in the old bitmap icons. For 
> instance, a rectangle of size 5x4px in the bitmap icon should probably become 
> a rectangle of 5x4px in the vector version.
> * Keep the same general colors in vectorized icons as in the corresponding 
> old bitmap icons.
> * Some of the old bitmap icons use grays with a slightly blue tint (e.g. the 
> [file 
> icons|https://raw.githubusercontent.com/apache/netbeans/master/java/refactoring.java/src/org/netbeans/modules/refactoring/java/resources/newFile.png]).
>  This style is out of fashion (resembling 1990s Solaris GUIs etc.); use 
> neutral greys instead.
> * If the old bitmap icon is complex, it is fine to simplify it a bit when 
> drawing vectorized versions.
> * Omit gradients, bevels, and unnecessary drop shadows. They take more time 
> to draw, and with "flat design", they are now out of fashion in any case.
> * Use a stroke width of 1px around the main shapes in the icon, like in the 
> existing bitmap icons. The new icons should look consistent with the existing 
> bitmap icons, especially since we may see bitmap icons and vector

[jira] [Commented] (NETBEANS-2617) Redraw common icons in SVG

2022-01-19 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478828#comment-17478828
 ] 

Eirik Bakke commented on NETBEANS-2617:
---

I hadn't seen Affinity Designer! Perhaps a future contributor will want to use 
it. It usually takes some time to get used to any one drawing tool, so once you 
have learned it, it's hard to swtich.

Regarding colors, the initial idea is to stay with the same color scheme as the 
existing bitmaps, until a significant number of icons have been drawn. In the 
illustrator file, there's a layer underneath that shows the old icons. Later we 
can make more creative improvements, once most of the important icons have been 
drawn. (It's quick to change colors in Illustrator once the shapes are already 
there.)

> Redraw common icons in SVG
> --
>
> Key: NETBEANS-2617
> URL: https://issues.apache.org/jira/browse/NETBEANS-2617
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 11.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: 210604 Icons Overview Cropped.png, 211228 Consolidated 
> Icons.ai, 220101 Updated Dark Filter Test.png, ScreenshotExample.png, 
> ide.editor.bookmarks.ai, ide.editor.macros.ai, ide.seperator.breadcrumbs.ai, 
> image-2022-01-19-14-41-29-967.png, netbeans_icons_illustrator_template.ai, 
> style example (dark filter).png, style example.png
>
>
> Once NETBEANS-2604 is done, we should start replacing commonly seen NetBeans 
> icons with SVG versions, for improved appearance on Retina/HiDPI displays.
> h2. UPDATE: 
> [Here|https://docs.google.com/spreadsheets/d/1U_pj-I3hk9Wj_7lvHcUDsZfFfBSyCkSGqBuv0qt_qXw/edit?usp=sharing]
>  is a Google Sheet where we can track progress of contributions and 
> prioritization of icons.
> With some practice, it takes on average 30 minutes to create an SVG version 
> of a typical icon in Adobe Illustrator. See the attached illustration and 
> Illustrator template. The Illustrator template includes a few icons which 
> have already been converted.
> In NETBEANS-2605, a prioritized list of icons to convert was produced (now 
> migrated to the Google Sheet above). By redrawing the most commonly seen 
> icons first, we can get the greatest "bang for the buck" in terms of 
> improving NetBeans' appearance on HiDPI displays. Once we have a batch of 
> icons ready to integrate into the NetBeans repository, Eirik will redo the 
> duplicate detection and ensure the SVGs end up in all relevant locations, and 
> start creating pull requests.
> See also the overview page for HiDPI improvements on 
> https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements
>  .
> If you wish to contribute to this effort, comment here; Eirik will coordinate 
> to make sure multiple people are not working on the same icons.
> h2. Proposed Style Guide for Vectorized Icons
> *[See tutorial video here.|https://vimeo.com/667860571]*
> * Vector icons should be drawn in Adobe Illustrator, or alternatively 
> Inkscape or another free tool. In Illustrator, each icon should be one named 
> artboard, sized to the correct size in pixels. See the attached Illustrator 
> template. (Adobe Illustrator comes with a free 7-day trial, after which it's 
> $35/month. If cost is a problem but you want to contribute your time to draw 
> icons, ask Eirik...)
> * If you prefer to use Inkscape instead, and want to contribute icons, that's 
> fine; just make sure to follow the same consistent style as the other icons. 
> If using Inkscape, perhaps pick another group of icons than the ones that are 
> currently being drawn in Illustrator. It's best to draw all similar-looking 
> icons in the same tool.
> * For each icon to be vectorized, place the old bitmap version of the icon in 
> a separate layer ("Old Bitmap Icons" in the Illustrator template). You can 
> then draw the vectorized version on top.
> * Since most of the existing NetBeans icons follow a quite consistent visual 
> style, and to simplify the job of creating new icons, it is best to keep the 
> shape of the new vectorized icons the same as in the old bitmap icons. For 
> instance, a rectangle of size 5x4px in the bitmap icon should probably become 
> a rectangle of 5x4px in the vector version.
> * Keep the same general colors in vectorized icons as in the corresponding 
> old bitmap icons.
> * Some of the old bitmap icons use grays with a slightly blue tint (e.g. the 
> [file 
> icons|https://raw.githubusercontent.com/apache/netbeans/master/java/refactoring.java/src/org/netbeans/modules/refactoring/java/resources/newFile.png]).
>  This style is out of fashion (resembling 1990s Solaris GUIs etc.); use 
> neutral greys instead.
> * If the old

[jira] [Updated] (NETBEANS-2617) Redraw common icons in SVG

2022-01-19 Thread Eirik Bakke (Jira)

[
https://issues.apache.org/jira/browse/NETBEANS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Eirik Bakke updated NETBEANS-2617:
--
Description:
Once NETBEANS-2604 is done, we should start replacing commonly seen NetBeans
icons with SVG versions, for improved appearance on Retina/HiDPI displays.

h2. UPDATE:
[Here|https://docs.google.com/spreadsheets/d/1U_pj-I3hk9Wj_7lvHcUDsZfFfBSyCkSGqBuv0qt_qXw/edit?usp=sharing]
is a Google Sheet where we can track progress of contributions and
prioritization of icons.

With some practice, it takes on average 30 minutes to create an SVG version of
a typical icon in Adobe Illustrator. See the attached illustration and
Illustrator template. The Illustrator template includes a few icons which have
already been converted.

In NETBEANS-2605, a prioritized list of icons to convert was produced (now
migrated to the Google Sheet above). By redrawing the most commonly seen icons
first, we can get the greatest "bang for the buck" in terms of improving
NetBeans' appearance on HiDPI displays. Once we have a batch of icons ready to
integrate into the NetBeans repository, Eirik will redo the duplicate detection
and ensure the SVGs end up in all relevant locations, and start creating pull
requests.

See also the overview page for HiDPI improvements on
https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements
.

If you wish to contribute to this effort, comment here; Eirik will coordinate
to make sure multiple people are not working on the same icons.

h2. Proposed Style Guide for Vectorized Icons
*[See tutorial video here.|https://vimeo.com/667860571]*

* Vector icons should be drawn in Adobe Illustrator, or alternatively Inkscape
or another free tool. In Illustrator, each icon should be one named artboard,
sized to the correct size in pixels. See the attached Illustrator template.
(Adobe Illustrator comes with a free 7-day trial, after which it's $35/month.
If cost is a problem but you want to contribute your time to draw icons, ask
Eirik...)
* If you prefer to use Inkscape instead, and want to contribute icons, that's
fine; just make sure to follow the same consistent style as the other icons. If
using Inkscape, perhaps pick another group of icons than the ones that are
currently being drawn in Illustrator. It's best to draw all similar-looking
icons in the same tool.
* For each icon to be vectorized, place the old bitmap version of the icon in a
separate layer ("Old Bitmap Icons" in the Illustrator template). You can then
draw the vectorized version on top.
* Since most of the existing NetBeans icons follow a quite consistent visual
style, and to simplify the job of creating new icons, it is best to keep the
shape of the new vectorized icons the same as in the old bitmap icons. For
instance, a rectangle of size 5x4px in the bitmap icon should probably become a
rectangle of 5x4px in the vector version.
* Keep the same general colors in vectorized icons as in the corresponding old
bitmap icons.
* Some of the old bitmap icons use grays with a slightly blue tint (e.g. the
[file
icons|https://raw.githubusercontent.com/apache/netbeans/master/java/refactoring.java/src/org/netbeans/modules/refactoring/java/resources/newFile.png]).
This style is out of fashion (resembling 1990s Solaris GUIs etc.); use neutral
greys instead.
* If the old bitmap icon is complex, it is fine to simplify it a bit when
drawing vectorized versions.
* Omit gradients, bevels, and unnecessary drop shadows. They take more time to
draw, and with "flat design", they are now out of fashion in any case.
* Use a stroke width of 1px around the main shapes in the icon, like in the
existing bitmap icons. The new icons should look consistent with the existing
bitmap icons, especially since we may see bitmap icons and vector icons
side-by-side for a long time. Within shapes, 0.5px strokes can be used for
finer details. (0.5px strokes become 1 device pixel on Retina screens, which
have a 2x scaling.)
* The 1px strokes that outline the icon's shapes should typically be 33%
transparent black on top of the shape's background color, or of similar
darkness. See the examples in the attached "style example.png" file.
* When the same shape occurs in different icons but at different sizes (e.g.
the small magnifying glass in find_selection.png vs. the large magnifying glass
in zoom_in.png), strokes and borders should still remain at the same thickness
(1px for external borders and 0.5px for internal strokes).
* Horizontal and vertical strokes must be aligned to the pixel grid.
* While it may sometimes be necessary to "outline" strokes for the purposes of
applying boolean operations (e.g. subtracting another shape from the stroke
only), strokes should be left as strokes whenever possible, as this leads to
smaller SVG files, and makes shapes within the icon easier to modify.
* For icons in

[jira] [Updated] (NETBEANS-2617) Redraw common icons in SVG

2022-01-19 Thread Eirik Bakke (Jira)

[
https://issues.apache.org/jira/browse/NETBEANS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

See also the overview page for HiDPI improvements on
https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements
.

If you wish to contribute to this effort, comment here; Eirik will coordinate
to make sure multiple people are not working on the same icons.

h2. Proposed Style Guide for Vectorized Icons
[See this tutorial video.|https://vimeo.com/667860571].

[jira] [Commented] (NETBEANS-6358) Font style regression: badly readable font style

2022-01-11 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472796#comment-17472796
 ] 

Eirik Bakke commented on NETBEANS-6358:
---

The reported OpenJDK bug is now listed at 
https://bugs.openjdk.java.net/browse/JDK-8279666


> Font style regression: badly readable font style
> 
>
> Key: NETBEANS-6358
> URL: https://issues.apache.org/jira/browse/NETBEANS-6358
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Navigation, ide - UI, java - Navigation
>Affects Versions: 12.6
> Environment: NB 12.6
> Win10
>Reporter: S. M.
>Assignee: Eirik Bakke
>Priority: Minor
> Attachments: ClearType Tahoma vs. Segoe.png, NetBeans 12.6 Project 
> Font on Windows 11.png, bold.png, regular.png
>
>
> The font style changed in 12.6 in a way that makes it less readable. The 
> following fonts are bold now: 
> - The name of the source files in the source-code-tab 
> - The project names in the projects windows (and all its child nodes)
> This bulky use of bold fonts makes the text badly readable. Please use a 
> regular font instead! The source-code names in the source-window-tab used to 
> be bold only when the file had unsaved changes, which seems to be a good 
> thing to me.
> It might seem to be a 'minor' problem, but the font as part of the 
> ergonomically usability is quite important.
> Thanks a lot!
> Here the comparison:
> Bulky and badly readable: New bold style
> !bold.png!
> Clear and readable: Old regular style
> !regular.png!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Comment Edited] (NETBEANS-6358) Font style regression: badly readable font style

2022-01-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469293#comment-17469293
 ] 

Eirik Bakke edited comment on NETBEANS-6358 at 1/5/22, 1:10 PM:


I submitted an OpenJDK bug report for this ("Segoe UI font renders too heavy 
when ClearType is disabled"). I'll post the OpenJDK JIRA ticket URL once it 
goes through review.

Meanwhile, if you'd like, I could add code to the NetBeans Windows LAF to 
revert to Tahoma 11 when ClearType is disabled, if you think this is a good 
workaround.



was (Author: ebakke):
I submitted an OpenJDK bug report for this ("Segoe UI font renders too heavy 
when ClearType is disabled"). I'll post the OpenJDK JIRA ticket URL once it 
goes through the review.

Meanwhile, if you'd like, I could add code to the Windows LAF to revert to 
Tahoma 11 when ClearType is disabled, if you think this is a good workaround.


> Font style regression: badly readable font style
> 
>
> Key: NETBEANS-6358
> URL: https://issues.apache.org/jira/browse/NETBEANS-6358
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Navigation, ide - UI, java - Navigation
>Affects Versions: 12.6
> Environment: NB 12.6
> Win10
>Reporter: S. M.
>Assignee: Eirik Bakke
>Priority: Minor
> Attachments: ClearType Tahoma vs. Segoe.png, NetBeans 12.6 Project 
> Font on Windows 11.png, bold.png, regular.png
>
>
> The font style changed in 12.6 in a way that makes it less readable. The 
> following fonts are bold now: 
> - The name of the source files in the source-code-tab 
> - The project names in the projects windows (and all its child nodes)
> This bulky use of bold fonts makes the text badly readable. Please use a 
> regular font instead! The source-code names in the source-window-tab used to 
> be bold only when the file had unsaved changes, which seems to be a good 
> thing to me.
> It might seem to be a 'minor' problem, but the font as part of the 
> ergonomically usability is quite important.
> Thanks a lot!
> Here the comparison:
> Bulky and badly readable: New bold style
> !bold.png!
> Clear and readable: Old regular style
> !regular.png!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-6358) Font style regression: badly readable font style

2022-01-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469293#comment-17469293
 ] 

Eirik Bakke commented on NETBEANS-6358:
---

I submitted an OpenJDK bug report for this ("Segoe UI font renders too heavy 
when ClearType is disabled"). I'll post the OpenJDK JIRA ticket URL once it 
goes through the review.

Meanwhile, if you'd like, I could add code to the Windows LAF to revert to 
Tahoma 11 when ClearType is disabled, if you think this is a good workaround.


> Font style regression: badly readable font style
> 
>
> Key: NETBEANS-6358
> URL: https://issues.apache.org/jira/browse/NETBEANS-6358
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Navigation, ide - UI, java - Navigation
>Affects Versions: 12.6
> Environment: NB 12.6
> Win10
>Reporter: S. M.
>Assignee: Eirik Bakke
>Priority: Minor
> Attachments: ClearType Tahoma vs. Segoe.png, NetBeans 12.6 Project 
> Font on Windows 11.png, bold.png, regular.png
>
>
> The font style changed in 12.6 in a way that makes it less readable. The 
> following fonts are bold now: 
> - The name of the source files in the source-code-tab 
> - The project names in the projects windows (and all its child nodes)
> This bulky use of bold fonts makes the text badly readable. Please use a 
> regular font instead! The source-code names in the source-window-tab used to 
> be bold only when the file had unsaved changes, which seems to be a good 
> thing to me.
> It might seem to be a 'minor' problem, but the font as part of the 
> ergonomically usability is quite important.
> Thanks a lot!
> Here the comparison:
> Bulky and badly readable: New bold style
> !bold.png!
> Clear and readable: Old regular style
> !regular.png!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-6358) Font style regression: badly readable font style

2022-01-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469272#comment-17469272
 ] 

Eirik Bakke commented on NETBEANS-6358:
---

My conclusion: This is a JDK bug, where the Segoe UI font renders too heavy 
when ClearType is disabled. (It's not actually bold--the bold style is even 
heavier.)

I tried to fix it by changing RenderingHints.KEY_TEXT_LCD_CONTRAST in 
UIDefaults, but this setting seems to be ignored. One could set 
KEY_TEXT_ANTIALIASING to VALUE_TEXT_ANTIALIAS_OFF, but this affects all fonts 
at all sizes, which is not correct. (When ClearType is off, 
RenderingHints.VALUE_TEXT_ANTIALIAS_GASP is set, which means the font is 
supposed to specify which sizes it should be anti-aliased for. For example, 
Tahoma is antialiased at larger sizes only. But Segoe UI always wants to be 
antialiased. Which is OK and what other Windows apps do as well, except it ends 
up too heavy in Java...)

I think the solution is to have NetBeans Windows LAF detect when ClearType is 
disabled (when 
RenderingHints.KEY_TEXT_ANTIALIASING==RenderingHints.VALUE_TEXT_ANTIALIAS_GASP),
 and then use Tahoma 11 in that case instead of Segoe UI.

Ideally FlatLAF should do the same, but that would have to be a change made in 
the FlatLAF library.

Meanwhile we could also file an OpenJDK bug report.

> Font style regression: badly readable font style
> 
>
> Key: NETBEANS-6358
> URL: https://issues.apache.org/jira/browse/NETBEANS-6358
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Navigation, ide - UI, java - Navigation
>Affects Versions: 12.6
> Environment: NB 12.6
> Win10
>Reporter: S. M.
>Assignee: Eirik Bakke
>Priority: Minor
> Attachments: ClearType Tahoma vs. Segoe.png, NetBeans 12.6 Project 
> Font on Windows 11.png, bold.png, regular.png
>
>
> The font style changed in 12.6 in a way that makes it less readable. The 
> following fonts are bold now: 
> - The name of the source files in the source-code-tab 
> - The project names in the projects windows (and all its child nodes)
> This bulky use of bold fonts makes the text badly readable. Please use a 
> regular font instead! The source-code names in the source-window-tab used to 
> be bold only when the file had unsaved changes, which seems to be a good 
> thing to me.
> It might seem to be a 'minor' problem, but the font as part of the 
> ergonomically usability is quite important.
> Thanks a lot!
> Here the comparison:
> Bulky and badly readable: New bold style
> !bold.png!
> Clear and readable: Old regular style
> !regular.png!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Comment Edited] (NETBEANS-6358) Font style regression: badly readable font style

2022-01-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469272#comment-17469272
 ] 

Eirik Bakke edited comment on NETBEANS-6358 at 1/5/22, 12:32 PM:
-

My conclusion: This is a JDK bug, where the Segoe UI font renders too heavy 
when ClearType is disabled. (It's not actually bold--the bold style is even 
heavier.)

I tried to fix it by changing RenderingHints.KEY_TEXT_LCD_CONTRAST in 
UIDefaults, but this setting seems to be ignored. One could set 
KEY_TEXT_ANTIALIASING to VALUE_TEXT_ANTIALIAS_OFF, but this affects all fonts 
at all sizes, which is not correct. (When ClearType is off, 
RenderingHints.VALUE_TEXT_ANTIALIAS_GASP is set, which means the font is 
supposed to specify which sizes it should be anti-aliased for. For example, 
Tahoma is antialiased at larger sizes only. But Segoe UI always wants to be 
antialiased. Which is OK and what other Windows apps do as well, except it ends 
up too heavy in Java...)

I think the solution is to have NetBeans Windows LAF detect when ClearType is 
disabled (when 
RenderingHints.KEY_TEXT_ANTIALIASING==RenderingHints.VALUE_TEXT_ANTIALIAS_GASP),
 and then use the old Tahoma 11 in that case instead of Segoe UI 12.

Ideally FlatLAF should do the same, but that would have to be a change made in 
the FlatLAF library.

Meanwhile we could also file an OpenJDK bug report.


was (Author: ebakke):
My conclusion: This is a JDK bug, where the Segoe UI font renders too heavy 
when ClearType is disabled. (It's not actually bold--the bold style is even 
heavier.)

I tried to fix it by changing RenderingHints.KEY_TEXT_LCD_CONTRAST in 
UIDefaults, but this setting seems to be ignored. One could set 
KEY_TEXT_ANTIALIASING to VALUE_TEXT_ANTIALIAS_OFF, but this affects all fonts 
at all sizes, which is not correct. (When ClearType is off, 
RenderingHints.VALUE_TEXT_ANTIALIAS_GASP is set, which means the font is 
supposed to specify which sizes it should be anti-aliased for. For example, 
Tahoma is antialiased at larger sizes only. But Segoe UI always wants to be 
antialiased. Which is OK and what other Windows apps do as well, except it ends 
up too heavy in Java...)

I think the solution is to have NetBeans Windows LAF detect when ClearType is 
disabled (when 
RenderingHints.KEY_TEXT_ANTIALIASING==RenderingHints.VALUE_TEXT_ANTIALIAS_GASP),
 and then use Tahoma 11 in that case instead of Segoe UI.

Ideally FlatLAF should do the same, but that would have to be a change made in 
the FlatLAF library.

Meanwhile we could also file an OpenJDK bug report.

> Font style regression: badly readable font style
> 
>
> Key: NETBEANS-6358
> URL: https://issues.apache.org/jira/browse/NETBEANS-6358
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Navigation, ide - UI, java - Navigation
>Affects Versions: 12.6
> Environment: NB 12.6
> Win10
>Reporter: S. M.
>Assignee: Eirik Bakke
>Priority: Minor
> Attachments: ClearType Tahoma vs. Segoe.png, NetBeans 12.6 Project 
> Font on Windows 11.png, bold.png, regular.png
>
>
> The font style changed in 12.6 in a way that makes it less readable. The 
> following fonts are bold now: 
> - The name of the source files in the source-code-tab 
> - The project names in the projects windows (and all its child nodes)
> This bulky use of bold fonts makes the text badly readable. Please use a 
> regular font instead! The source-code names in the source-window-tab used to 
> be bold only when the file had unsaved changes, which seems to be a good 
> thing to me.
> It might seem to be a 'minor' problem, but the font as part of the 
> ergonomically usability is quite important.
> Thanks a lot!
> Here the comparison:
> Bulky and badly readable: New bold style
> !bold.png!
> Clear and readable: Old regular style
> !regular.png!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Comment Edited] (NETBEANS-6358) Font style regression: badly readable font style

2022-01-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469246#comment-17469246
 ] 

Eirik Bakke edited comment on NETBEANS-6358 at 1/5/22, 12:00 PM:
-

OK, the problem is definitively related to ClearType being disabled. The Segoe 
UI font, on Swing, renders too heavy when ClearType is disabled, while Tahoma 
reverts to a completely un-antialiased look:

 !ClearType Tahoma vs. Segoe.png!

This is also a problem in the regular menu bar on standalone Swing apps (where 
Segoe UI 12 is used automatically, as seen above), and on FlatLAF prior to 
either of the recent patches mentioned above (since FlatLAF always used Segoe 
UI 12 on Windows). For example, NetBeans 12.2 has the same problem when 
ClearType is disabled, when run with FlatLAF Light. But except in the menu 
bars, the Windows LAF previously avoided the problem by using Tahoma 11, which 
ended up non-antialiased.

The immediate workaround is to enable ClearType in the Windows control panel. 
But ideally we'd want NetBeans to look good even when ClearType is disabled. 
Let me investigate the best way to achieve this...


was (Author: ebakke):
OK, the problem is definitively related to ClearType being disabled. The Segoe 
UI font, on Swing, renders too heavy when ClearType is disabled, while Tahoma 
reverts to a completely un-antialiased look:

 !ClearType Tahoma vs. Segoe.png!

This is also a problem in the regular menu bar on standalone Swing apps (where 
Segoe UI 12 is used automatically), and on FlatLAF prior to either of the 
recent patches mentioned above (since FlatLAF always used Segoe UI 12 on 
Windows). For example, NetBeans 12.2 has the same problem when ClearType is 
disabled, when run with FlatLAF Light. But except in the menu bars, the Windows 
LAF previously avoided the problem by using Tahoma 11, which ended up 
non-antialiased.

The immediate workaround is to enable ClearType in the Windows control panel. 
But ideally we'd want NetBeans to look good even when it is disabled. Let me 
investigate the best way to achieve this...

> Font style regression: badly readable font style
> 
>
> Key: NETBEANS-6358
> URL: https://issues.apache.org/jira/browse/NETBEANS-6358
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Navigation, ide - UI, java - Navigation
>Affects Versions: 12.6
> Environment: NB 12.6
> Win10
>Reporter: S. M.
>Assignee: Eirik Bakke
>Priority: Minor
> Attachments: ClearType Tahoma vs. Segoe.png, NetBeans 12.6 Project 
> Font on Windows 11.png, bold.png, regular.png
>
>
> The font style changed in 12.6 in a way that makes it less readable. The 
> following fonts are bold now: 
> - The name of the source files in the source-code-tab 
> - The project names in the projects windows (and all its child nodes)
> This bulky use of bold fonts makes the text badly readable. Please use a 
> regular font instead! The source-code names in the source-window-tab used to 
> be bold only when the file had unsaved changes, which seems to be a good 
> thing to me.
> It might seem to be a 'minor' problem, but the font as part of the 
> ergonomically usability is quite important.
> Thanks a lot!
> Here the comparison:
> Bulky and badly readable: New bold style
> !bold.png!
> Clear and readable: Old regular style
> !regular.png!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-6358) Font style regression: badly readable font style

2022-01-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469246#comment-17469246
 ] 

Eirik Bakke commented on NETBEANS-6358:
---

OK, the problem is definitively related to ClearType being disabled. The Segoe 
UI font, on Swing, renders too heavy when ClearType is disabled, while Tahoma 
reverts to a completely un-antialiased look:

 !ClearType Tahoma vs. Segoe.png!

This is also a problem in the regular menu bar on standalone Swing apps (where 
Segoe UI 12 is used automatically), and on FlatLAF prior to either of the 
recent patches mentioned above (since FlatLAF always used Segoe UI 12 on 
Windows). For example, NetBeans 12.2 has the same problem when ClearType is 
disabled, when run with FlatLAF Light. But except in the menu bars, the Windows 
LAF previously avoided the problem by using Tahoma 11, which ended up 
non-antialiased.

The immediate workaround is to enable ClearType in the Windows control panel. 
But ideally we'd want NetBeans to look good even when it is disabled. Let me 
investigate the best way to achieve this...

> Font style regression: badly readable font style
> 
>
> Key: NETBEANS-6358
> URL: https://issues.apache.org/jira/browse/NETBEANS-6358
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Navigation, ide - UI, java - Navigation
>Affects Versions: 12.6
> Environment: NB 12.6
> Win10
>Reporter: S. M.
>Assignee: Eirik Bakke
>Priority: Minor
> Attachments: ClearType Tahoma vs. Segoe.png, NetBeans 12.6 Project 
> Font on Windows 11.png, bold.png, regular.png
>
>
> The font style changed in 12.6 in a way that makes it less readable. The 
> following fonts are bold now: 
> - The name of the source files in the source-code-tab 
> - The project names in the projects windows (and all its child nodes)
> This bulky use of bold fonts makes the text badly readable. Please use a 
> regular font instead! The source-code names in the source-window-tab used to 
> be bold only when the file had unsaved changes, which seems to be a good 
> thing to me.
> It might seem to be a 'minor' problem, but the font as part of the 
> ergonomically usability is quite important.
> Thanks a lot!
> Here the comparison:
> Bulky and badly readable: New bold style
> !bold.png!
> Clear and readable: Old regular style
> !regular.png!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Updated] (NETBEANS-6358) Font style regression: badly readable font style

2022-01-05 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-6358:
--
Attachment: ClearType Tahoma vs. Segoe.png

> Font style regression: badly readable font style
> 
>
> Key: NETBEANS-6358
> URL: https://issues.apache.org/jira/browse/NETBEANS-6358
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Navigation, ide - UI, java - Navigation
>Affects Versions: 12.6
> Environment: NB 12.6
> Win10
>Reporter: S. M.
>Assignee: Eirik Bakke
>Priority: Minor
> Attachments: ClearType Tahoma vs. Segoe.png, NetBeans 12.6 Project 
> Font on Windows 11.png, bold.png, regular.png
>
>
> The font style changed in 12.6 in a way that makes it less readable. The 
> following fonts are bold now: 
> - The name of the source files in the source-code-tab 
> - The project names in the projects windows (and all its child nodes)
> This bulky use of bold fonts makes the text badly readable. Please use a 
> regular font instead! The source-code names in the source-window-tab used to 
> be bold only when the file had unsaved changes, which seems to be a good 
> thing to me.
> It might seem to be a 'minor' problem, but the font as part of the 
> ergonomically usability is quite important.
> Thanks a lot!
> Here the comparison:
> Bulky and badly readable: New bold style
> !bold.png!
> Clear and readable: Old regular style
> !regular.png!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Comment Edited] (NETBEANS-6358) Font style regression: badly readable font style

2022-01-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469218#comment-17469218
 ] 

Eirik Bakke edited comment on NETBEANS-6358 at 1/5/22, 11:22 AM:
-

Here's what the Projects pane looks like on my machine (which is on Windows 11 
with Java 11.0.11, here showing Windows LAF with no HiDPI scaling):
 !NetBeans 12.6 Project Font on Windows 11.png!


was (Author: ebakke):
Here's what the Projects pane looks like on my machine (which is on Windows 11 
with Java 11.0.11):
 !NetBeans 12.6 Project Font on Windows 11.png!

> Font style regression: badly readable font style
> 
>
> Key: NETBEANS-6358
> URL: https://issues.apache.org/jira/browse/NETBEANS-6358
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Navigation, ide - UI, java - Navigation
>Affects Versions: 12.6
> Environment: NB 12.6
> Win10
>Reporter: S. M.
>Assignee: Eirik Bakke
>Priority: Minor
> Attachments: NetBeans 12.6 Project Font on Windows 11.png, bold.png, 
> regular.png
>
>
> The font style changed in 12.6 in a way that makes it less readable. The 
> following fonts are bold now: 
> - The name of the source files in the source-code-tab 
> - The project names in the projects windows (and all its child nodes)
> This bulky use of bold fonts makes the text badly readable. Please use a 
> regular font instead! The source-code names in the source-window-tab used to 
> be bold only when the file had unsaved changes, which seems to be a good 
> thing to me.
> It might seem to be a 'minor' problem, but the font as part of the 
> ergonomically usability is quite important.
> Thanks a lot!
> Here the comparison:
> Bulky and badly readable: New bold style
> !bold.png!
> Clear and readable: Old regular style
> !regular.png!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-6358) Font style regression: badly readable font style

2022-01-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469218#comment-17469218
 ] 

Eirik Bakke commented on NETBEANS-6358:
---

Here's what the Projects pane looks like on my machine (which is on Windows 11 
with Java 11.0.11):
 !NetBeans 12.6 Project Font on Windows 11.png!

> Font style regression: badly readable font style
> 
>
> Key: NETBEANS-6358
> URL: https://issues.apache.org/jira/browse/NETBEANS-6358
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Navigation, ide - UI, java - Navigation
>Affects Versions: 12.6
> Environment: NB 12.6
> Win10
>Reporter: S. M.
>Assignee: Eirik Bakke
>Priority: Minor
> Attachments: NetBeans 12.6 Project Font on Windows 11.png, bold.png, 
> regular.png
>
>
> The font style changed in 12.6 in a way that makes it less readable. The 
> following fonts are bold now: 
> - The name of the source files in the source-code-tab 
> - The project names in the projects windows (and all its child nodes)
> This bulky use of bold fonts makes the text badly readable. Please use a 
> regular font instead! The source-code names in the source-window-tab used to 
> be bold only when the file had unsaved changes, which seems to be a good 
> thing to me.
> It might seem to be a 'minor' problem, but the font as part of the 
> ergonomically usability is quite important.
> Thanks a lot!
> Here the comparison:
> Bulky and badly readable: New bold style
> !bold.png!
> Clear and readable: Old regular style
> !regular.png!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Updated] (NETBEANS-6358) Font style regression: badly readable font style

2022-01-05 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-6358:
--
Attachment: NetBeans 12.6 Project Font on Windows 11.png

> Font style regression: badly readable font style
> 
>
> Key: NETBEANS-6358
> URL: https://issues.apache.org/jira/browse/NETBEANS-6358
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Navigation, ide - UI, java - Navigation
>Affects Versions: 12.6
> Environment: NB 12.6
> Win10
>Reporter: S. M.
>Assignee: Eirik Bakke
>Priority: Minor
> Attachments: NetBeans 12.6 Project Font on Windows 11.png, bold.png, 
> regular.png
>
>
> The font style changed in 12.6 in a way that makes it less readable. The 
> following fonts are bold now: 
> - The name of the source files in the source-code-tab 
> - The project names in the projects windows (and all its child nodes)
> This bulky use of bold fonts makes the text badly readable. Please use a 
> regular font instead! The source-code names in the source-window-tab used to 
> be bold only when the file had unsaved changes, which seems to be a good 
> thing to me.
> It might seem to be a 'minor' problem, but the font as part of the 
> ergonomically usability is quite important.
> Thanks a lot!
> Here the comparison:
> Bulky and badly readable: New bold style
> !bold.png!
> Clear and readable: Old regular style
> !regular.png!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-6358) Font style regression: badly readable font style

2022-01-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469203#comment-17469203
 ] 

Eirik Bakke commented on NETBEANS-6358:
---

Which Java version is NetBeans running on, for each of the two screenshots? And 
which old NetBeans version are you comparing against? I'd like to be able to 
reproduce this on my own machine...

The old/new difference seems to be that anti-aliasing was disabled previously 
and is now enabled. The bug might actually be that anti-aliasing was _not_ 
previously enabled, which might have been fixed by 
https://github.com/apache/netbeans/pull/3116 .

I'm wondering how your old NetBeans version ended up without anti-aliasing. 
Have you customized netbeans.conf at any point? I also see that you have 
disabled ClearType. If you type "ClearType" in the start menu search bar and 
select "Adjust ClearType Text", and enable ClearType, and then restart 
NetBeans, I suspect you will see better results.

> Font style regression: badly readable font style
> 
>
> Key: NETBEANS-6358
> URL: https://issues.apache.org/jira/browse/NETBEANS-6358
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Navigation, ide - UI, java - Navigation
>Affects Versions: 12.6
> Environment: NB 12.6
> Win10
>Reporter: S. M.
>Assignee: Eirik Bakke
>Priority: Minor
> Attachments: bold.png, regular.png
>
>
> The font style changed in 12.6 in a way that makes it less readable. The 
> following fonts are bold now: 
> - The name of the source files in the source-code-tab 
> - The project names in the projects windows (and all its child nodes)
> This bulky use of bold fonts makes the text badly readable. Please use a 
> regular font instead! The source-code names in the source-window-tab used to 
> be bold only when the file had unsaved changes, which seems to be a good 
> thing to me.
> It might seem to be a 'minor' problem, but the font as part of the 
> ergonomically usability is quite important.
> Thanks a lot!
> Here the comparison:
> Bulky and badly readable: New bold style
> !bold.png!
> Clear and readable: Old regular style
> !regular.png!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Updated] (NETBEANS-2617) Redraw common icons in SVG

2022-01-01 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-2617:
--
Attachment: 220101 Updated Dark Filter Test.png

> Redraw common icons in SVG
> --
>
> Key: NETBEANS-2617
> URL: https://issues.apache.org/jira/browse/NETBEANS-2617
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 11.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: 210604 Icons Overview Cropped.png, 211228 Consolidated 
> Icons.ai, 220101 Updated Dark Filter Test.png, ScreenshotExample.png, 
> ide.editor.bookmarks.ai, ide.editor.macros.ai, ide.seperator.breadcrumbs.ai, 
> netbeans_icons_illustrator_template.ai, style example (dark filter).png, 
> style example.png
>
>
> Once NETBEANS-2604 is done, we should start replacing commonly seen NetBeans 
> icons with SVG versions, for improved appearance on Retina/HiDPI displays.
> h2. UPDATE: 
> [Here|https://docs.google.com/spreadsheets/d/1U_pj-I3hk9Wj_7lvHcUDsZfFfBSyCkSGqBuv0qt_qXw/edit?usp=sharing]
>  is a Google Sheet where we can track progress of contributions and 
> prioritization of icons.
> With some practice, it takes on average 30 minutes to create an SVG version 
> of a typical icon in Adobe Illustrator. See the attached illustration and 
> Illustrator template. The Illustrator template includes a few icons which 
> have already been converted.
> In NETBEANS-2605, a prioritized list of icons to convert was produced (now 
> migrated to the Google Sheet above). By redrawing the most commonly seen 
> icons first, we can get the greatest "bang for the buck" in terms of 
> improving NetBeans' appearance on HiDPI displays. Once we have a batch of 
> icons ready to integrate into the NetBeans repository, Eirik will redo the 
> duplicate detection and ensure the SVGs end up in all relevant locations, and 
> start creating pull requests.
> See also the overview page for HiDPI improvements on 
> https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements
>  .
> If you wish to contribute to this effort, comment here; Eirik will coordinate 
> to make sure multiple people are not working on the same icons.
> h2. Proposed Style Guide for Vectorized Icons
> * Vector icons should be drawn in Adobe Illustrator, or alternatively 
> Inkscape or another free tool. In Illustrator, each icon should be one named 
> artboard, sized to the correct size in pixels. See the attached Illustrator 
> template. (Adobe Illustrator comes with a free 7-day trial, after which it's 
> $35/month. If cost is a problem but you want to contribute your time to draw 
> icons, ask Eirik...)
> * If you prefer to use Inkscape instead, and want to contribute icons, that's 
> fine; just make sure to follow the same consistent style as the other icons. 
> If using Inkscape, perhaps pick another group of icons than the ones that are 
> currently being drawn in Illustrator. It's best to draw all similar-looking 
> icons in the same tool.
> * For each icon to be vectorized, place the old bitmap version of the icon in 
> a separate layer ("Old Bitmap Icons" in the Illustrator template). You can 
> then draw the vectorized version on top.
> * Since most of the existing NetBeans icons follow a quite consistent visual 
> style, and to simplify the job of creating new icons, it is best to keep the 
> shape of the new vectorized icons the same as in the old bitmap icons. For 
> instance, a rectangle of size 5x4px in the bitmap icon should probably become 
> a rectangle of 5x4px in the vector version.
> * Keep the same general colors in vectorized icons as in the corresponding 
> old bitmap icons.
> * Some of the old bitmap icons use grays with a slightly blue tint (e.g. the 
> [file 
> icons|https://raw.githubusercontent.com/apache/netbeans/master/java/refactoring.java/src/org/netbeans/modules/refactoring/java/resources/newFile.png]).
>  This style is out of fashion (resembling 1990s Solaris GUIs etc.); use 
> neutral greys instead.
> * If the old bitmap icon is complex, it is fine to simplify it a bit when 
> drawing vectorized versions.
> * Omit gradients, bevels, and unnecessary drop shadows. They take more time 
> to draw, and with "flat design", they are now out of fashion in any case.
> * Use a stroke width of 1px around the main shapes in the icon, like in the 
> existing bitmap icons. The new icons should look consistent with the existing 
> bitmap icons, especially since we may see bitmap icons and vector icons 
> side-by-side for a long time. Within shapes, 0.5px strokes can be used for 
> finer details. (0.5px strokes become 1 device pixel on Retina screens, which 
> have a 2x scaling.)
> * The 1px strokes that outline

[jira] [Comment Edited] (NETBEANS-765) HiDPI resolution of 3840x2160 results in tiny icons and text fields that are too small for the text within (Linux)

2021-12-30 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466751#comment-17466751
 ] 

Eirik Bakke edited comment on NETBEANS-765 at 12/30/21, 8:59 AM:
-

[~khoek] You can enable 2x HiDPI scaling by setting the environment variable 
GDK_SCALE=2 and using FlatLAF as the Look & Feel.

Can you see if this solves the problem?

(There is also a Pull Request for making NetBeans set GDK_SCALE automatically 
in the future; see https://github.com/apache/netbeans/pull/3113 . Future 
NetBeans versions will also have FlatLAF as the default LAF, as it works well 
with HiDPI scaling enabled.)


was (Author: ebakke):
[~khoek] You can enable 2x HiDPI scaling by setting the environment variable 
GDK_SCALE=2 and using FlatLAF as the Look & Feel.

Can you see if this solves the problem?

(There is also a Pull Request for making NetBeans set GDK_SCALE automatically 
in the future; see https://github.com/apache/netbeans/pull/3113 )

> HiDPI resolution of 3840x2160 results in tiny icons and text fields that are 
> too small for the text within (Linux)
> --
>
> Key: NETBEANS-765
> URL: https://issues.apache.org/jira/browse/NETBEANS-765
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - UI
>Affects Versions: 9.0
>Reporter: Sidney Lins
>Priority: Major
>  Labels: HiDPI
> Attachments: Screenshot from 2018-05-28 19-29-19.png, Screenshot from 
> 2018-05-28 19-29-19.png, Screenshot from 2018-05-28 19-40-36.png, Screenshot 
> from 2018-07-07 21-21-32.jpg, Screenshot from 2018-08-26 10-10-34.png, 
> Screenshot from 2021-12-27 14-11-40.png, Screenshot from 2021-12-27 
> 14-14-18.png
>
>
> Please, refer to [https://netbeans.org/bugzilla/show_bug.cgi?id=252452] to 
> get more information.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-765) HiDPI resolution of 3840x2160 results in tiny icons and text fields that are too small for the text within (Linux)

2021-12-30 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466751#comment-17466751
 ] 

Eirik Bakke commented on NETBEANS-765:
--

[~khoek] You can enable 2x HiDPI scaling by setting the environment variable 
GDK_SCALE=2 and using FlatLAF as the Look & Feel.

Can you see if this solves the problem?

(There is also a Pull Request for making NetBeans do this automatically in the 
future; see https://github.com/apache/netbeans/pull/3113 )

> HiDPI resolution of 3840x2160 results in tiny icons and text fields that are 
> too small for the text within (Linux)
> --
>
> Key: NETBEANS-765
> URL: https://issues.apache.org/jira/browse/NETBEANS-765
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - UI
>Affects Versions: 9.0
>Reporter: Sidney Lins
>Priority: Major
>  Labels: HiDPI
> Attachments: Screenshot from 2018-05-28 19-29-19.png, Screenshot from 
> 2018-05-28 19-29-19.png, Screenshot from 2018-05-28 19-40-36.png, Screenshot 
> from 2018-07-07 21-21-32.jpg, Screenshot from 2018-08-26 10-10-34.png, 
> Screenshot from 2021-12-27 14-11-40.png, Screenshot from 2021-12-27 
> 14-14-18.png
>
>
> Please, refer to [https://netbeans.org/bugzilla/show_bug.cgi?id=252452] to 
> get more information.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Comment Edited] (NETBEANS-765) HiDPI resolution of 3840x2160 results in tiny icons and text fields that are too small for the text within (Linux)

2021-12-30 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466751#comment-17466751
 ] 

Eirik Bakke edited comment on NETBEANS-765 at 12/30/21, 8:58 AM:
-

[~khoek] You can enable 2x HiDPI scaling by setting the environment variable 
GDK_SCALE=2 and using FlatLAF as the Look & Feel.

Can you see if this solves the problem?

(There is also a Pull Request for making NetBeans set GDK_SCALE automatically 
in the future; see https://github.com/apache/netbeans/pull/3113 )


was (Author: ebakke):
[~khoek] You can enable 2x HiDPI scaling by setting the environment variable 
GDK_SCALE=2 and using FlatLAF as the Look & Feel.

Can you see if this solves the problem?

(There is also a Pull Request for making NetBeans do this automatically in the 
future; see https://github.com/apache/netbeans/pull/3113 )

> HiDPI resolution of 3840x2160 results in tiny icons and text fields that are 
> too small for the text within (Linux)
> --
>
> Key: NETBEANS-765
> URL: https://issues.apache.org/jira/browse/NETBEANS-765
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - UI
>Affects Versions: 9.0
>Reporter: Sidney Lins
>Priority: Major
>  Labels: HiDPI
> Attachments: Screenshot from 2018-05-28 19-29-19.png, Screenshot from 
> 2018-05-28 19-29-19.png, Screenshot from 2018-05-28 19-40-36.png, Screenshot 
> from 2018-07-07 21-21-32.jpg, Screenshot from 2018-08-26 10-10-34.png, 
> Screenshot from 2021-12-27 14-11-40.png, Screenshot from 2021-12-27 
> 14-14-18.png
>
>
> Please, refer to [https://netbeans.org/bugzilla/show_bug.cgi?id=252452] to 
> get more information.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-2617) Redraw common icons in SVG

2021-12-28 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466097#comment-17466097
 ] 

Eirik Bakke commented on NETBEANS-2617:
---

I attached "211228 Consolidated Icons.ai", which is the latest version of the 
Illustrator file containing the current SVG icons in NetBeans, with artboards 
prepared for the next 167 icons or so to be prioritized.

> Redraw common icons in SVG
> --
>
> Key: NETBEANS-2617
> URL: https://issues.apache.org/jira/browse/NETBEANS-2617
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 11.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: 210604 Icons Overview Cropped.png, 211228 Consolidated 
> Icons.ai, ScreenshotExample.png, ide.editor.bookmarks.ai, 
> ide.editor.macros.ai, ide.seperator.breadcrumbs.ai, 
> netbeans_icons_illustrator_template.ai, style example (dark filter).png, 
> style example.png
>
>
> Once NETBEANS-2604 is done, we should start replacing commonly seen NetBeans 
> icons with SVG versions, for improved appearance on Retina/HiDPI displays.
> h2. UPDATE: 
> [Here|https://docs.google.com/spreadsheets/d/1U_pj-I3hk9Wj_7lvHcUDsZfFfBSyCkSGqBuv0qt_qXw/edit?usp=sharing]
>  is a Google Sheet where we can track progress of contributions and 
> prioritization of icons.
> With some practice, it takes on average 30 minutes to create an SVG version 
> of a typical icon in Adobe Illustrator. See the attached illustration and 
> Illustrator template. The Illustrator template includes a few icons which 
> have already been converted.
> In NETBEANS-2605, a prioritized list of icons to convert was produced (now 
> migrated to the Google Sheet above). By redrawing the most commonly seen 
> icons first, we can get the greatest "bang for the buck" in terms of 
> improving NetBeans' appearance on HiDPI displays. Once we have a batch of 
> icons ready to integrate into the NetBeans repository, Eirik will redo the 
> duplicate detection and ensure the SVGs end up in all relevant locations, and 
> start creating pull requests.
> See also the overview page for HiDPI improvements on 
> https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements
>  .
> If you wish to contribute to this effort, comment here; Eirik will coordinate 
> to make sure multiple people are not working on the same icons.
> h2. Proposed Style Guide for Vectorized Icons
> * Vector icons should be drawn in Adobe Illustrator, or alternatively 
> Inkscape or another free tool. In Illustrator, each icon should be one named 
> artboard, sized to the correct size in pixels. See the attached Illustrator 
> template. (Adobe Illustrator comes with a free 7-day trial, after which it's 
> $35/month. If cost is a problem but you want to contribute your time to draw 
> icons, ask Eirik...)
> * If you prefer to use Inkscape instead, and want to contribute icons, that's 
> fine; just make sure to follow the same consistent style as the other icons. 
> If using Inkscape, perhaps pick another group of icons than the ones that are 
> currently being drawn in Illustrator. It's best to draw all similar-looking 
> icons in the same tool.
> * For each icon to be vectorized, place the old bitmap version of the icon in 
> a separate layer ("Old Bitmap Icons" in the Illustrator template). You can 
> then draw the vectorized version on top.
> * Since most of the existing NetBeans icons follow a quite consistent visual 
> style, and to simplify the job of creating new icons, it is best to keep the 
> shape of the new vectorized icons the same as in the old bitmap icons. For 
> instance, a rectangle of size 5x4px in the bitmap icon should probably become 
> a rectangle of 5x4px in the vector version.
> * Keep the same general colors in vectorized icons as in the corresponding 
> old bitmap icons.
> * Some of the old bitmap icons use grays with a slightly blue tint (e.g. the 
> [file 
> icons|https://raw.githubusercontent.com/apache/netbeans/master/java/refactoring.java/src/org/netbeans/modules/refactoring/java/resources/newFile.png]).
>  This style is out of fashion (resembling 1990s Solaris GUIs etc.); use 
> neutral greys instead.
> * If the old bitmap icon is complex, it is fine to simplify it a bit when 
> drawing vectorized versions.
> * Omit gradients, bevels, and unnecessary drop shadows. They take more time 
> to draw, and with "flat design", they are now out of fashion in any case.
> * Use a stroke width of 1px around the main shapes in the icon, like in the 
> existing bitmap icons. The new icons should look consistent with the existing 
> bitmap icons, especially since we may see bitmap icons and vector icons 
> side-by-side for a long time. Within shapes,

[jira] [Updated] (NETBEANS-2617) Redraw common icons in SVG

2021-12-28 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-2617:
--
Attachment: 211228 Consolidated Icons.ai

> Redraw common icons in SVG
> --
>
> Key: NETBEANS-2617
> URL: https://issues.apache.org/jira/browse/NETBEANS-2617
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 11.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: 210604 Icons Overview Cropped.png, 211228 Consolidated 
> Icons.ai, ScreenshotExample.png, ide.editor.bookmarks.ai, 
> ide.editor.macros.ai, ide.seperator.breadcrumbs.ai, 
> netbeans_icons_illustrator_template.ai, style example (dark filter).png, 
> style example.png
>
>
> Once NETBEANS-2604 is done, we should start replacing commonly seen NetBeans 
> icons with SVG versions, for improved appearance on Retina/HiDPI displays.
> h2. UPDATE: 
> [Here|https://docs.google.com/spreadsheets/d/1U_pj-I3hk9Wj_7lvHcUDsZfFfBSyCkSGqBuv0qt_qXw/edit?usp=sharing]
>  is a Google Sheet where we can track progress of contributions and 
> prioritization of icons.
> With some practice, it takes on average 30 minutes to create an SVG version 
> of a typical icon in Adobe Illustrator. See the attached illustration and 
> Illustrator template. The Illustrator template includes a few icons which 
> have already been converted.
> In NETBEANS-2605, a prioritized list of icons to convert was produced (now 
> migrated to the Google Sheet above). By redrawing the most commonly seen 
> icons first, we can get the greatest "bang for the buck" in terms of 
> improving NetBeans' appearance on HiDPI displays. Once we have a batch of 
> icons ready to integrate into the NetBeans repository, Eirik will redo the 
> duplicate detection and ensure the SVGs end up in all relevant locations, and 
> start creating pull requests.
> See also the overview page for HiDPI improvements on 
> https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements
>  .
> If you wish to contribute to this effort, comment here; Eirik will coordinate 
> to make sure multiple people are not working on the same icons.
> h2. Proposed Style Guide for Vectorized Icons
> * Vector icons should be drawn in Adobe Illustrator, or alternatively 
> Inkscape or another free tool. In Illustrator, each icon should be one named 
> artboard, sized to the correct size in pixels. See the attached Illustrator 
> template. (Adobe Illustrator comes with a free 7-day trial, after which it's 
> $35/month. If cost is a problem but you want to contribute your time to draw 
> icons, ask Eirik...)
> * If you prefer to use Inkscape instead, and want to contribute icons, that's 
> fine; just make sure to follow the same consistent style as the other icons. 
> If using Inkscape, perhaps pick another group of icons than the ones that are 
> currently being drawn in Illustrator. It's best to draw all similar-looking 
> icons in the same tool.
> * For each icon to be vectorized, place the old bitmap version of the icon in 
> a separate layer ("Old Bitmap Icons" in the Illustrator template). You can 
> then draw the vectorized version on top.
> * Since most of the existing NetBeans icons follow a quite consistent visual 
> style, and to simplify the job of creating new icons, it is best to keep the 
> shape of the new vectorized icons the same as in the old bitmap icons. For 
> instance, a rectangle of size 5x4px in the bitmap icon should probably become 
> a rectangle of 5x4px in the vector version.
> * Keep the same general colors in vectorized icons as in the corresponding 
> old bitmap icons.
> * Some of the old bitmap icons use grays with a slightly blue tint (e.g. the 
> [file 
> icons|https://raw.githubusercontent.com/apache/netbeans/master/java/refactoring.java/src/org/netbeans/modules/refactoring/java/resources/newFile.png]).
>  This style is out of fashion (resembling 1990s Solaris GUIs etc.); use 
> neutral greys instead.
> * If the old bitmap icon is complex, it is fine to simplify it a bit when 
> drawing vectorized versions.
> * Omit gradients, bevels, and unnecessary drop shadows. They take more time 
> to draw, and with "flat design", they are now out of fashion in any case.
> * Use a stroke width of 1px around the main shapes in the icon, like in the 
> existing bitmap icons. The new icons should look consistent with the existing 
> bitmap icons, especially since we may see bitmap icons and vector icons 
> side-by-side for a long time. Within shapes, 0.5px strokes can be used for 
> finer details. (0.5px strokes become 1 device pixel on Retina screens, which 
> have a 2x scaling.)
> * The 1px strokes that outline the icon's shapes should typically be 33% 
>

[jira] [Updated] (NETBEANS-2617) Redraw common icons in SVG

2021-11-23 Thread Eirik Bakke (Jira)

[
https://issues.apache.org/jira/browse/NETBEANS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

See also the overview page for HiDPI improvements on
https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements
.

If you wish to contribute to this effort, comment here; Eirik will coordinate
to make sure multiple people are not working on the same icons.

h2. Proposed Style Guide for Vectorized Icons
* Vector icons should be drawn in Adobe Illustrator, or alternatively Inkscape
or another free tool. In Illustrator, each icon should be one named artboard,
sized to the correct size in pixels. See the attached Illustrator template.
(Adobe Illustrator comes with a free 7-day trial, after which it's $35/month.
If cost is a problem but you want to contribute your time to draw icons, ask
Eirik...)
* If you prefer to use Inkscape instead, and want to contribute icons, that's
fine; just make sure to follow the same consistent style as the other icons. If
using Inkscape, perhaps pick another group of icons than the ones that are
currently being drawn in Illustrator. It's best to draw all similar-looking
icons in the same tool.
* For each icon to be vectorized, place the old bitmap version of the icon in a
separate layer ("Old Bitmap Icons" in the Illustrator template). You can then
draw the vectorized version on top.
* Since most of the existing NetBeans icons follow a quite consistent visual
style, and to simplify the job of creating new icons, it is best to keep the
shape of the new vectorized icons the same as in the old bitmap icons. For
instance, a rectangle of size 5x4px in the bitmap icon should probably become a
rectangle of 5x4px in the vector version.
* Keep the same general colors in vectorized icons as in the corresponding old
bitmap icons.
* Some of the old bitmap icons use grays with a slightly blue tint (e.g. the
[file
icons|https://raw.githubusercontent.com/apache/netbeans/master/java/refactoring.java/src/org/netbeans/modules/refactoring/java/resources/newFile.png]).
This style is out of fashion (resembling 1990s Solaris GUIs etc.); use neutral
greys instead.
* If the old bitmap icon is complex, it is fine to simplify it a bit when
drawing vectorized versions.
* Omit gradients, bevels, and unnecessary drop shadows. They take more time to
draw, and with "flat design", they are now out of fashion in any case.
* Use a stroke width of 1px around the main shapes in the icon, like in the
existing bitmap icons. The new icons should look consistent with the existing
bitmap icons, especially since we may see bitmap icons and vector icons
side-by-side for a long time. Within shapes, 0.5px strokes can be used for
finer details. (0.5px strokes become 1 device pixel on Retina screens, which
have a 2x scaling.)
* The 1px strokes that outline the icon's shapes should typically be 33%
transparent black on top of the shape's background color, or of similar
darkness. See the examples in the attached "style example.png" file.
* When the same shape occurs in different icons but at different sizes (e.g.
the small magnifying glass in find_selection.png vs. the large magnifying glass
in zoom_in.png), strokes and borders should still remain at the same thickness
(1px for external borders and 0.5px for internal strokes).
* Horizontal and vertical strokes must be aligned to the pixel grid.
* While it may sometimes be necessary to "outline" strokes for the purposes of
applying boolean operations (e.g. subtracting another shape from the stroke
only), strokes should be left as strokes whenever possible, as this leads to
smaller SVG files, and makes shapes within the icon easier to modify.
* For icons in the main IDE toolbar (as opposed to the editor toolbar),

[jira] [Commented] (NETBEANS-4135) FlatLaf on Windows does not render all Unicode characters

2021-11-17 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-4135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445642#comment-17445642
 ] 

Eirik Bakke commented on NETBEANS-4135:
---

Using StyleContext.getDefaultStyleContext().getFont was a nice trick! It seems 
to make a difference for physical fonts such as "Segoe UI" or "Consolas", but 
not for the logical Java fonts such as "Monospaced" or "Dialog", which are 
always loaded as composite fonts.

I tried using this call from the NetBeans editor libraries as well, and it 
successfully makes e.g. Chinese and Japanese characters displayable in the 
editor even when a physical font that does not support them is selected (e.g. 
"Consolas"). I might make a PR out of that later, as a solution for 
NETBEANS-904.

> FlatLaf on Windows does not render all Unicode characters
> -
>
> Key: NETBEANS-4135
> URL: https://issues.apache.org/jira/browse/NETBEANS-4135
> Project: NetBeans
>  Issue Type: Bug
>  Components: FlatLaf
>Affects Versions: 11.3
>Reporter: Karl Tauber
>Assignee: Karl Tauber
>Priority: Major
> Fix For: 12.0
>
>
> reported here [https://github.com/JFormDesigner/FlatLaf/issues/81]
> On Windows, FlatLaf components can not render all Unicode characters because 
> the used font "Segoe UI" does not contain all characters and FlatLaf does not 
> create a Swing "composite font", which could render all Unicode characters.
> On Linux, FlatLaf already creates a composite font.
> On Mac, the used font seems to contain all (or more) Unicode characters.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Comment Edited] (NETBEANS-904) Support fallback font options

2021-11-17 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445460#comment-17445460
 ] 

Eirik Bakke edited comment on NETBEANS-904 at 11/17/21, 7:47 PM:
-

(Assuming you are on Windows, from one of your screenshots...)

Looking at the standard JDK fontconfig.properties.src file, the logical font 
"Monospaced" should defer to a font called "GulimChe" for Korean. Is this font 
installed as a Windows font, available in other apps?

It should also be possible to edit fontconfig.properties.src in the JDK's "lib" 
directory to point to e.g. Noto, as an alternate font for Monospaced. Note that 
in NetBeans, this currently only works when one of the standard Java "logical" 
fonts are selected (e.g. Monospaced).


was (Author: ebakke):
Looking at the standard JDK fontconfig.properties.src file, the logical font 
"Monospaced" should defer to a font called "GulimChe" for Korean. Is this font 
installed on your Windows machine?

It should also be possible to edit fontconfig.properties.src in the JDK's "lib" 
directory to point to e.g. Noto, as an alternate font for Monospaced. Note that 
in NetBeans, this currently only works when one of the standard Java "logical" 
fonts are selected (e.g. Monospaced).

> Support fallback font options
> -
>
> Key: NETBEANS-904
> URL: https://issues.apache.org/jira/browse/NETBEANS-904
> Project: NetBeans
>  Issue Type: Improvement
>  Components: editor - Options
>Affects Versions: 8.2, 9.0, 10.0
>Reporter: NDelt
>Priority: Major
> Attachments: 2018_10_01_netbeans_snapshot_monospaced.png, 
> 2018_10_01_netbeans_snapshot_noto_sans_mono_cjk_kr_regular.png, 
> DejaVu-Sans-Mono-15.png, Source-Code-Pro-Medium-15.png
>
>
> Currently I can't type text that the font cannot represents.(It is displayed 
> as broken text)
> I would like to use back-up font options like _Fallback Fonts_ in IntelliJ 
> IDEA.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-904) Support fallback font options

2021-11-17 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445460#comment-17445460
 ] 

Eirik Bakke commented on NETBEANS-904:
--

Looking at the standard JDK fontconfig.properties.src file, the logical font 
"Monospaced" should defer to a font called "GulimChe" for Korean. Is this font 
installed?

It should also be possible to edit fontconfig.properties.src in the JDK's "lib" 
directory to point to e.g. Noto, as an alternate font for Monospaced. Note that 
in NetBeans, this currently only works when one of the standard Java "logical" 
fonts are selected (e.g. Monospaced).

> Support fallback font options
> -
>
> Key: NETBEANS-904
> URL: https://issues.apache.org/jira/browse/NETBEANS-904
> Project: NetBeans
>  Issue Type: Improvement
>  Components: editor - Options
>Affects Versions: 8.2, 9.0, 10.0
>Reporter: NDelt
>Priority: Major
> Attachments: 2018_10_01_netbeans_snapshot_monospaced.png, 
> 2018_10_01_netbeans_snapshot_noto_sans_mono_cjk_kr_regular.png, 
> DejaVu-Sans-Mono-15.png, Source-Code-Pro-Medium-15.png
>
>
> Currently I can't type text that the font cannot represents.(It is displayed 
> as broken text)
> I would like to use back-up font options like _Fallback Fonts_ in IntelliJ 
> IDEA.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Comment Edited] (NETBEANS-904) Support fallback font options

2021-11-17 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445460#comment-17445460
 ] 

Eirik Bakke edited comment on NETBEANS-904 at 11/17/21, 7:45 PM:
-

Looking at the standard JDK fontconfig.properties.src file, the logical font 
"Monospaced" should defer to a font called "GulimChe" for Korean. Is this font 
installed on your Windows machine?

It should also be possible to edit fontconfig.properties.src in the JDK's "lib" 
directory to point to e.g. Noto, as an alternate font for Monospaced. Note that 
in NetBeans, this currently only works when one of the standard Java "logical" 
fonts are selected (e.g. Monospaced).


was (Author: ebakke):
Looking at the standard JDK fontconfig.properties.src file, the logical font 
"Monospaced" should defer to a font called "GulimChe" for Korean. Is this font 
installed?

It should also be possible to edit fontconfig.properties.src in the JDK's "lib" 
directory to point to e.g. Noto, as an alternate font for Monospaced. Note that 
in NetBeans, this currently only works when one of the standard Java "logical" 
fonts are selected (e.g. Monospaced).

> Support fallback font options
> -
>
> Key: NETBEANS-904
> URL: https://issues.apache.org/jira/browse/NETBEANS-904
> Project: NetBeans
>  Issue Type: Improvement
>  Components: editor - Options
>Affects Versions: 8.2, 9.0, 10.0
>Reporter: NDelt
>Priority: Major
> Attachments: 2018_10_01_netbeans_snapshot_monospaced.png, 
> 2018_10_01_netbeans_snapshot_noto_sans_mono_cjk_kr_regular.png, 
> DejaVu-Sans-Mono-15.png, Source-Code-Pro-Medium-15.png
>
>
> Currently I can't type text that the font cannot represents.(It is displayed 
> as broken text)
> I would like to use back-up font options like _Fallback Fonts_ in IntelliJ 
> IDEA.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Resolved] (NETBEANS-3196) Calling Children.LEAF.getNodesCount() changes lazy loading behavior globally

2021-11-11 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANS-3196.
---
Resolution: Fixed

PR was merged; marking resolved.

> Calling Children.LEAF.getNodesCount() changes lazy loading behavior globally
> 
>
> Key: NETBEANS-3196
> URL: https://issues.apache.org/jira/browse/NETBEANS-3196
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Nodes
>Affects Versions: 11.0
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> There's a small bug in org.openide.nodes.Node.setChildren(Children). The 
> logic goes something like this:
> {code:java}
> protected final void setChildren(final Children ch) {
>   boolean wasInited = hierarchy.isInitialized();
>   boolean wasLeaf = hierarchy == Children.LEAF;
>   // ...
>   hierarchy = ch;
>   // ...
>   if (wasInited && hierarchy != Children.LEAF) {
>   // init new children if old was inited
>   hierarchy.getNodesCount();
> {code}
> If a Node's children was originally Children.LEAF, and is then changed to a 
> different instance, the resulting behavior now becomes dependent on the 
> result of Children.LEAF.isInitialized(). The latter is a global piece of 
> state which may return false for a long time until _any_ module anywhere in 
> the IDE or in a platform application calls Children.LEAF.getNodesCount(), 
> after which Children.LEAF.isInitialized() will forever after return true.
> Once Children.LEAF.getNodesCount() has been called, from any module, Node 
> implementations that switch from Children.LEAF to another Children 
> implementation will no longer get lazy loading behavior.
> The fix is simple; the condition should be "wasInited && !wasLeaf && 
> hierarchy != Children.LEAF)".
> It might be good to ensure that Children.LEAF is always initialized as well, 
> to prevent accidentally sharing mutable global state. (Actually, I tried 
> calling Children.LEAF.getNodesCount() on LEAF's initial construction, but 
> this caused a failure on startup. So don't bother.)
> (This bug was found in a NetBeans Platform application that relies heavily on 
> lazy loading of nodes.)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Resolved] (NETBEANS-5656) Various smaller fixes in the database New Connection wizard

2021-11-11 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANS-5656.
---
Resolution: Fixed

PR was merged; marking resolved.

> Various smaller fixes in the database New Connection wizard
> ---
>
> Key: NETBEANS-5656
> URL: https://issues.apache.org/jira/browse/NETBEANS-5656
> Project: NetBeans
>  Issue Type: Improvement
>  Components: db - DB schema
>Affects Versions: 12.2
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Issue for a PR with various small UI improvements to the database module's 
> "New Connection" wizard.
> Details:
> * Refactor the 'Add Connection' wizard to avoid depending on hardcoded wizard 
> panel indexes.
>  * Improve two error messages in "New Connection" wizard.
>  * Avoid a spurious 'Specified class is not a driver' warning in certain 
> situations.
>  * When detecting the Microsoft SQL Server JDBC driver, avoid showing an 
> ancient version number.
>  * Add a default port number for Microsoft SQL Server.
>  * Tidy up presentation names in the JDBC URL format dropdown.
>  * Decrease the timeout of the connection validation step.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Resolved] (NETBEANS-5927) Switch Windows LAF to the now-standard "Segoe UI" font

2021-11-11 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANS-5927.
---
Resolution: Fixed

PR was merged; marking fixed.

> Switch Windows LAF to the now-standard "Segoe UI" font
> --
>
> Key: NETBEANS-5927
> URL: https://issues.apache.org/jira/browse/NETBEANS-5927
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Other
>Affects Versions: 12.4
> Environment: NetBeans 12.4 with Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: pull-request-available
> Attachments: fontchange-1-before.png, fontchange-2-after.png
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> For the last 14 years (since Windows Vista), the default UI font on Windows 
> has been Segoe UI 12. But Swing's Windows LAF stayed with Tahoma 11, for 
> reasons of backwards compatibility only (see JDK-6669448). This makes 
> NetBeans look a little dated, and the font size smaller than in other Windows 
> application. In the words of one blogger: "On a related note, this is one of 
> the bigger visual deficiencies of NetBeans running on Vista – the smaller 
> Tahoma font makes it less visually appealing that it could have been." 
> https://www.pushing-pixels.org/page/213?m
> This PR switches the NetBeans Windows LAF to the newer Segoe font, by 
> borrowing logic from FlatLAF to get the actual Windows default font from the 
> "win.messagebox.font" desktop property, which is initialized from the Win32 
> API. This also avoids one of the problems that were fixed in the earlier 
> https://github.com/apache/netbeans/pull/1777 , with the Swing Windows LAF 
> using incorrect font sizes on certain HiDPI configurations.
> Segoe UI 12 looks similar to Tahoma 11, but with ascenders and descenders 
> that extend one pixel farther up/down. Letters like "j" and "y" have some 
> differences in their shapes.
> Note that certain UI elements, notably the menu bar, were already using Segoe 
> UI 12. And FlatLAF is already using Segoe UI 12 on Windows. Note also that 
> this PR should not affect the main code editor font.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Resolved] (NETBEANS-6172) NetBeans screen scaling with Windows 10

2021-11-11 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANS-6172.
---
Resolution: Not A Bug

> NetBeans screen scaling with Windows 10 
> 
>
> Key: NETBEANS-6172
> URL: https://issues.apache.org/jira/browse/NETBEANS-6172
> Project: NetBeans
>  Issue Type: Improvement
>  Components: javaee - Hibernate
>Affects Versions: 12.4
> Environment: Windows 10, NetBeans 12.0
>Reporter: Sergio García
>Assignee: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: LoginScaled.png, LoginScaled_Real.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
>  
>  In the latest versions of Netbeans I have been able to verify that the 
> Netbeans IDE is rescaled according to the latent configuration in Windows 10 
> (dpi); this new behavior is fine and improves the development environment. 
> However it is also a problem as it also visually rescales the GUIs in the 
> debugging process; i'm using Maven to compile and execute the program.
>  In my case, having a GUI adapted to the real size of my monitor screen is 
> important. I have tried to solve this problem by parameterizing the java with 
> commands like "-Dsun.java2d.uiScale = 1.0" or by disabling the windows 
> rescaling option that exists in the "java.exe" and "javaw.exe" properties but 
> this does not work for NetBeans. It also doesn't work to change the Netbeans 
> setting with the parameter "-J-Dsun.java2d.dpiaware = true".
>   
>  *It would be interesting to have a clear and functional way to avoid 
> rescaling windows to facilitate the visual design of the GUIs.*



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-6172) NetBeans screen scaling with Windows 10

2021-11-10 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17441955#comment-17441955
 ] 

Eirik Bakke commented on NETBEANS-6172:
---

In that case the current behavior is as intended.

You should be able to do add a runtime parameter "-Dsun.java2d.uiScale=1" to 
get small fonts (works on my machine on both Java 9 and Java 16). Just make 
sure the parameter is actually passed.

> NetBeans screen scaling with Windows 10 
> 
>
> Key: NETBEANS-6172
> URL: https://issues.apache.org/jira/browse/NETBEANS-6172
> Project: NetBeans
>  Issue Type: Improvement
>  Components: javaee - Hibernate
>Affects Versions: 12.4
> Environment: Windows 10, NetBeans 12.0
>Reporter: Sergio García
>Assignee: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: LoginScaled.png, LoginScaled_Real.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
>  
>  In the latest versions of Netbeans I have been able to verify that the 
> Netbeans IDE is rescaled according to the latent configuration in Windows 10 
> (dpi); this new behavior is fine and improves the development environment. 
> However it is also a problem as it also visually rescales the GUIs in the 
> debugging process; i'm using Maven to compile and execute the program.
>  In my case, having a GUI adapted to the real size of my monitor screen is 
> important. I have tried to solve this problem by parameterizing the java with 
> commands like "-Dsun.java2d.uiScale = 1.0" or by disabling the windows 
> rescaling option that exists in the "java.exe" and "javaw.exe" properties but 
> this does not work for NetBeans. It also doesn't work to change the Netbeans 
> setting with the parameter "-J-Dsun.java2d.dpiaware = true".
>   
>  *It would be interesting to have a clear and functional way to avoid 
> rescaling windows to facilitate the visual design of the GUIs.*



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Updated] (NETBEANS-3746) [FlatLaF] Restartless theme changing for FlatLaF

2021-11-07 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-3746:
--
Summary: [FlatLaF] Restartless theme changing for FlatLaF  (was: [FlatLaF] 
Change theme for FlatLaF)

> [FlatLaF] Restartless theme changing for FlatLaF
> 
>
> Key: NETBEANS-3746
> URL: https://issues.apache.org/jira/browse/NETBEANS-3746
> Project: NetBeans
>  Issue Type: New Feature
>  Components: FlatLaf, ide - UI, platform - OptionsSettings
> Environment: Product Version: Apache NetBeans IDE 11.1
> Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
> Java: 11.0.2; Java HotSpot(TM) 64-Bit Server VM 11.0.2+9-LTS
> Runtime: Java(TM) SE Runtime Environment 11.0.2+9-LTS
> System: Windows 10 version 10.0 running on amd64; Cp1252; de_DE (nb)
> User directory: C:\Users\Chrl\AppData\Roaming\NetBeans\11.1
> Cache directory: C:\Users\Chrl\AppData\Local\NetBeans\Cache\11.1
>Reporter: Christian Lenz
>Assignee: Karl Tauber
>Priority: Major
>  Labels: Look, theme
> Attachments: flat-laf-changing-theme.gif
>
>
> As far as I know, there ia theming option for FlatLaF inside the FlatLaF 
> demo. See my screencapture for more info. So it is possible via JSON to theme 
> the LaF easy and restartless. IntelliJ is doing that and it works like a 
> charm.
> The problem of NetBeans changing LaF is you often need to restart, because 
> not all components are repainted correctly. But it seems that theming of 
> FlatLaF is independent from NetBeans.
> So it would be nice, if we can switch the FlatLaF theme easy via NetBeans as 
> it is possible in the FlatLaF demo which is located here: 
> https://github.com/JFormDesigner/FlatLaf
> I already asked here: https://github.com/JFormDesigner/FlatLaf/issues/29



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-3746) [FlatLaF] Change theme for FlatLaF

2021-11-06 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439884#comment-17439884
 ] 

Eirik Bakke commented on NETBEANS-3746:
---

> there is no difference between swing L switching theme and that what 
> FlatLaF does

The difference is that NetBeans FlatLAF code has been developed by a single 
person, who has been keeping the LAF switching (and theme switching) scenario 
in mind and tested it frequently. In constrast, other LAF-related code in 
NetBeans has been developed over years by many different people, who have all 
assumed that the LAF will never change at runtime.

There's a lot of isAqua(), isWindowsLaF(), isGTK() calls etc. spread around the 
NetBeans codebase, each being read only once as a component is initialized or 
such ( https://github.com/apache/netbeans/search?q=isaqua ). Each of these 
would cause a bug if the LAF was switched without a restart. But it wouldn't be 
a problem if merely switching the FlatLAF theme, since isFlatLAF() would just 
keep returning true.

> [FlatLaF] Change theme for FlatLaF
> --
>
> Key: NETBEANS-3746
> URL: https://issues.apache.org/jira/browse/NETBEANS-3746
> Project: NetBeans
>  Issue Type: New Feature
>  Components: FlatLaf, ide - UI, platform - OptionsSettings
> Environment: Product Version: Apache NetBeans IDE 11.1
> Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
> Java: 11.0.2; Java HotSpot(TM) 64-Bit Server VM 11.0.2+9-LTS
> Runtime: Java(TM) SE Runtime Environment 11.0.2+9-LTS
> System: Windows 10 version 10.0 running on amd64; Cp1252; de_DE (nb)
> User directory: C:\Users\Chrl\AppData\Roaming\NetBeans\11.1
> Cache directory: C:\Users\Chrl\AppData\Local\NetBeans\Cache\11.1
>Reporter: Christian Lenz
>Assignee: Karl Tauber
>Priority: Major
>  Labels: Look, theme
> Attachments: flat-laf-changing-theme.gif
>
>
> As far as I know, there ia theming option for FlatLaF inside the FlatLaF 
> demo. See my screencapture for more info. So it is possible via JSON to theme 
> the LaF easy and restartless. IntelliJ is doing that and it works like a 
> charm.
> The problem of NetBeans changing LaF is you often need to restart, because 
> not all components are repainted correctly. But it seems that theming of 
> FlatLaF is independent from NetBeans.
> So it would be nice, if we can switch the FlatLaF theme easy via NetBeans as 
> it is possible in the FlatLaF demo which is located here: 
> https://github.com/JFormDesigner/FlatLaf
> I already asked here: https://github.com/JFormDesigner/FlatLaf/issues/29



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

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

[jira] [Commented] (NETBEANS-5728) ETable/OutlineView drag-and-drop selects spurious nodes

2021-11-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439510#comment-17439510
 ] 

Eirik Bakke commented on NETBEANS-5728:
---

(I have a workaround for this one but haven't yet made a PR of it...)

> ETable/OutlineView drag-and-drop selects spurious nodes
> ---
>
> Key: NETBEANS-5728
> URL: https://issues.apache.org/jira/browse/NETBEANS-5728
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - OutlineTreeTable
>Affects Versions: 12.2
> Environment: Primarily MacOS, but also occasionally on Windows.
>Reporter: Eirik Bakke
>Priority: Major
>
> In an OutlineView with multiple selection enabled, if the user tries to drag 
> one row to a different position (e.g. to reorder rows when the underlying 
> nodes support it), additional rows will be selected as the mouse moves over 
> them during the drag operation. On MacOS, it happens 100% of the time. On 
> Windows, I've seen this bug happen in the past as well, though much less 
> frequently. On Windows the bug is merely annoying, but on MacOS the bug makes 
> OutlineView's drag-and-drop feature unusable.
> To reproduce:
> 1) One place in the IDE where the OutlineView is used is the "Search Results" 
> tab. While this node tree doesn't really support reordering results, the 
> OutlineView can still be used to exhibit the bug. Open some project, 
> right-click the project node, click "Find..." and search for something that 
> will bring up multiple (~5 or more) results.
> 2) Drag the first result row a couple of rows down, holding the left mouse 
> button down to observe the bug. If the bug does not appear, let go and try 
> again until it does. On Windows, you may need to start dragging from the 
> lower part of the row you're trying to drag, and the dragged mouse cursor may 
> need to exit onto the next row within a certain time period from when the 
> left mouse button was pressed. On MacOS, the bug happens every time, 
> regardless of how long I wait hovering over the original row while holding 
> down the mouse button before beginning to drag across other rows.
> Because the bug appears in both Windows and MacOS, albeit more rarely on 
> Windows, I suspect a fix that works in Windows would also fix the issue on 
> MacOS. Because of the timing aspect when reproducing the bug in Windows, 
> there appears to be some kind of race condition. Maybe there's some kind of 
> "selection rectangle" concept that doesn't get properly turned off in the 
> OutlineView.
> The problem is in JTable (see 
> https://stackoverflow.com/questions/5969258/how-to-make-jtable-click-on-unselected-do-a-drag-instead-of-a-select
>  ), but can be worked around in OutlineView.
> (This report is a revival of the old BugZilla issue 
> https://bz.apache.org/netbeans/show_bug.cgi?id=230690 )



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Commented] (NETBEANS-6172) NetBeans screen scaling with Windows 10

2021-11-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439401#comment-17439401
 ] 

Eirik Bakke commented on NETBEANS-6172:
---

NetBeans uses the same scaling configuration as java.exe and javaw.exe (see 
https://github.com/apache/netbeans/pull/883/files ). Normally this means that 
both NetBeans and other Java apps will be scaled up and appear sharp. But if 
you have previously changed the EXE file settings in Windows Explorer via 
Properties->Compatibility, that may cause the behavior to change.

See also my previous question--are you trying to make the application appear at 
1x scale ("unscaled") despite the Windows being configured to e.g. 200%? This 
would make your application look very small on your screen compared to other 
apps. Is that what you need?

> NetBeans screen scaling with Windows 10 
> 
>
> Key: NETBEANS-6172
> URL: https://issues.apache.org/jira/browse/NETBEANS-6172
> Project: NetBeans
>  Issue Type: Improvement
>  Components: javaee - Hibernate
>Affects Versions: 12.4
> Environment: Windows 10, NetBeans 12.0
>Reporter: Sergio García
>Assignee: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: LoginScaled.png, LoginScaled_Real.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
>  
>  In the latest versions of Netbeans I have been able to verify that the 
> Netbeans IDE is rescaled according to the latent configuration in Windows 10 
> (dpi); this new behavior is fine and improves the development environment. 
> However it is also a problem as it also visually rescales the GUIs in the 
> debugging process; i'm using Maven to compile and execute the program.
>  In my case, having a GUI adapted to the real size of my monitor screen is 
> important. I have tried to solve this problem by parameterizing the java with 
> commands like "-Dsun.java2d.uiScale = 1.0" or by disabling the windows 
> rescaling option that exists in the "java.exe" and "javaw.exe" properties but 
> this does not work for NetBeans. It also doesn't work to change the Netbeans 
> setting with the parameter "-J-Dsun.java2d.dpiaware = true".
>   
>  *It would be interesting to have a clear and functional way to avoid 
> rescaling windows to facilitate the visual design of the GUIs.*



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Commented] (NETBEANS-6172) NetBeans screen scaling with Windows 10

2021-11-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439316#comment-17439316
 ] 

Eirik Bakke commented on NETBEANS-6172:
---

> The desired behavior is that , when debugging , the swing components (Frames 
> Panels) are not rescaled according to the windows configuration (DPI).
In this case the application window would appear very small--is this your 
desired behavior? Is this what happens when you run outside of NetBeans?

I would recommend finding each of the EXE files involved here--probably 
netbeans64.exe, java.exe, and javaw.exe (in your JDK folder), right clicking 
them from Windows explorer, going to Properties->Compatibility->Change HiDPI 
settings and _uncheck_ both checkboxes, so that no special compatibility 
settings are used. I'd also double-check that your app is really running on 
Java 15. With recent Java versions, windows should be scaled and text should be 
sharp at the same time.

> NetBeans screen scaling with Windows 10 
> 
>
> Key: NETBEANS-6172
> URL: https://issues.apache.org/jira/browse/NETBEANS-6172
> Project: NetBeans
>  Issue Type: Improvement
>  Components: javaee - Hibernate
>Affects Versions: 12.4
> Environment: Windows 10, NetBeans 12.0
>Reporter: Sergio García
>Assignee: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: LoginScaled.png, LoginScaled_Real.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
>  
>  In the latest versions of Netbeans I have been able to verify that the 
> Netbeans IDE is rescaled according to the latent configuration in Windows 10 
> (dpi); this new behavior is fine and improves the development environment. 
> However it is also a problem as it also visually rescales the GUIs in the 
> debugging process; i'm using Maven to compile and execute the program.
>  In my case, having a GUI adapted to the real size of my monitor screen is 
> important. I have tried to solve this problem by parameterizing the java with 
> commands like "-Dsun.java2d.uiScale = 1.0" or by disabling the windows 
> rescaling option that exists in the "java.exe" and "javaw.exe" properties but 
> this does not work for NetBeans. It also doesn't work to change the Netbeans 
> setting with the parameter "-J-Dsun.java2d.dpiaware = true".
>   
>  *It would be interesting to have a clear and functional way to avoid 
> rescaling windows to facilitate the visual design of the GUIs.*



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Comment Edited] (NETBEANS-6172) NetBeans screen scaling with Windows 10

2021-11-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439316#comment-17439316
 ] 

Eirik Bakke edited comment on NETBEANS-6172 at 11/5/21, 2:54 PM:
-

> The desired behavior is that , when debugging , the swing components (Frames 
> Panels) are not rescaled according to the windows configuration (DPI).
In this case the application window would appear very small--is this your 
desired behavior? Is this what happens when you run outside of NetBeans?

I would recommend finding each of the EXE files involved here, probably 
netbeans64.exe, java.exe, and javaw.exe (in your JDK folder), right clicking 
them from Windows explorer, going to Properties->Compatibility->Change HiDPI 
settings and _uncheck_ both checkboxes, so that no special compatibility 
settings are used. I'd also double-check that your app is really running on 
Java 15. With recent Java versions, windows should be scaled and text should be 
sharp at the same time.


was (Author: ebakke):
> The desired behavior is that , when debugging , the swing components (Frames 
> Panels) are not rescaled according to the windows configuration (DPI).
In this case the application window would appear very small--is this your 
desired behavior? Is this what happens when you run outside of NetBeans?

I would recommend finding each of the EXE files involved here--probably 
netbeans64.exe, java.exe, and javaw.exe (in your JDK folder), right clicking 
them from Windows explorer, going to Properties->Compatibility->Change HiDPI 
settings and _uncheck_ both checkboxes, so that no special compatibility 
settings are used. I'd also double-check that your app is really running on 
Java 15. With recent Java versions, windows should be scaled and text should be 
sharp at the same time.

> NetBeans screen scaling with Windows 10 
> 
>
> Key: NETBEANS-6172
> URL: https://issues.apache.org/jira/browse/NETBEANS-6172
> Project: NetBeans
>  Issue Type: Improvement
>  Components: javaee - Hibernate
>Affects Versions: 12.4
> Environment: Windows 10, NetBeans 12.0
>Reporter: Sergio García
>Assignee: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: LoginScaled.png, LoginScaled_Real.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
>  
>  In the latest versions of Netbeans I have been able to verify that the 
> Netbeans IDE is rescaled according to the latent configuration in Windows 10 
> (dpi); this new behavior is fine and improves the development environment. 
> However it is also a problem as it also visually rescales the GUIs in the 
> debugging process; i'm using Maven to compile and execute the program.
>  In my case, having a GUI adapted to the real size of my monitor screen is 
> important. I have tried to solve this problem by parameterizing the java with 
> commands like "-Dsun.java2d.uiScale = 1.0" or by disabling the windows 
> rescaling option that exists in the "java.exe" and "javaw.exe" properties but 
> this does not work for NetBeans. It also doesn't work to change the Netbeans 
> setting with the parameter "-J-Dsun.java2d.dpiaware = true".
>   
>  *It would be interesting to have a clear and functional way to avoid 
> rescaling windows to facilitate the visual design of the GUIs.*



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Commented] (NETBEANS-3746) [FlatLaF] Change theme for FlatLaF

2021-11-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439310#comment-17439310
 ] 

Eirik Bakke commented on NETBEANS-3746:
---

I think the switch between FlatLAF themes is much less likely to cause problems 
than the switch between e.g. Aqua and FlatLAF, since FlatLAF was designed to 
allow this, and also since component dimensions won't change much.

Perhaps allow restartless switching between FlatLAF themes, but require a 
restart in all other cases?

>From the recent discussion it sounds like the future of NetBeans will be to go 
>with FlatLAF everywhere, and just switch its themes rather than encouraging 
>people to use entirely different Swing LAF implementations.

> [FlatLaF] Change theme for FlatLaF
> --
>
> Key: NETBEANS-3746
> URL: https://issues.apache.org/jira/browse/NETBEANS-3746
> Project: NetBeans
>  Issue Type: New Feature
>  Components: FlatLaf, ide - UI, platform - OptionsSettings
> Environment: Product Version: Apache NetBeans IDE 11.1
> Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
> Java: 11.0.2; Java HotSpot(TM) 64-Bit Server VM 11.0.2+9-LTS
> Runtime: Java(TM) SE Runtime Environment 11.0.2+9-LTS
> System: Windows 10 version 10.0 running on amd64; Cp1252; de_DE (nb)
> User directory: C:\Users\Chrl\AppData\Roaming\NetBeans\11.1
> Cache directory: C:\Users\Chrl\AppData\Local\NetBeans\Cache\11.1
>Reporter: Christian Lenz
>Assignee: Karl Tauber
>Priority: Major
>  Labels: Look, theme
> Attachments: flat-laf-changing-theme.gif
>
>
> As far as I know, there ia theming option for FlatLaF inside the FlatLaF 
> demo. See my screencapture for more info. So it is possible via JSON to theme 
> the LaF easy and restartless. IntelliJ is doing that and it works like a 
> charm.
> The problem of NetBeans changing LaF is you often need to restart, because 
> not all components are repainted correctly. But it seems that theming of 
> FlatLaF is independent from NetBeans.
> So it would be nice, if we can switch the FlatLaF theme easy via NetBeans as 
> it is possible in the FlatLaF demo which is located here: 
> https://github.com/JFormDesigner/FlatLaf
> I already asked here: https://github.com/JFormDesigner/FlatLaf/issues/29



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Commented] (NETBEANS-3746) [FlatLaF] Change theme for FlatLaF

2021-11-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439245#comment-17439245
 ] 

Eirik Bakke commented on NETBEANS-3746:
---

Switching without restarting introduces a lot of potential bugs that would only 
occur in that particular case. We might risk getting LAF-related bug reports, 
and then always having to say "did you restart first?" before assessing them.

Since LAF changes are done very infrequently, and are fraught with bugs, I'd 
prefer not giving users the option of switching without restarting.

> [FlatLaF] Change theme for FlatLaF
> --
>
> Key: NETBEANS-3746
> URL: https://issues.apache.org/jira/browse/NETBEANS-3746
> Project: NetBeans
>  Issue Type: New Feature
>  Components: FlatLaf, ide - UI, platform - OptionsSettings
> Environment: Product Version: Apache NetBeans IDE 11.1
> Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
> Java: 11.0.2; Java HotSpot(TM) 64-Bit Server VM 11.0.2+9-LTS
> Runtime: Java(TM) SE Runtime Environment 11.0.2+9-LTS
> System: Windows 10 version 10.0 running on amd64; Cp1252; de_DE (nb)
> User directory: C:\Users\Chrl\AppData\Roaming\NetBeans\11.1
> Cache directory: C:\Users\Chrl\AppData\Local\NetBeans\Cache\11.1
>Reporter: Christian Lenz
>Assignee: Karl Tauber
>Priority: Major
>  Labels: Look, theme
> Attachments: flat-laf-changing-theme.gif
>
>
> As far as I know, there ia theming option for FlatLaF inside the FlatLaF 
> demo. See my screencapture for more info. So it is possible via JSON to theme 
> the LaF easy and restartless. IntelliJ is doing that and it works like a 
> charm.
> The problem of NetBeans changing LaF is you often need to restart, because 
> not all components are repainted correctly. But it seems that theming of 
> FlatLaF is independent from NetBeans.
> So it would be nice, if we can switch the FlatLaF theme easy via NetBeans as 
> it is possible in the FlatLaF demo which is located here: 
> https://github.com/JFormDesigner/FlatLaf
> I already asked here: https://github.com/JFormDesigner/FlatLaf/issues/29



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Commented] (NETBEANS-6172) NetBeans screen scaling with Windows 10

2021-11-05 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439241#comment-17439241
 ] 

Eirik Bakke commented on NETBEANS-6172:
---

Which version of Java is the process being debugged run in?

> However it is also a problem as it also visually rescales the GUIs in the 
> debugging process
> In my case, having a GUI adapted to the real size of my monitor screen is 
> important.
What is the desired behavior for the application being run here? Do you want it 
to be unscaled (smaller than other Windows apps, but sharp), or scaled (same 
size as other Windows apps)? Is the problem the size of the app, or that it's 
the correct size but blurry?



> NetBeans screen scaling with Windows 10 
> 
>
> Key: NETBEANS-6172
> URL: https://issues.apache.org/jira/browse/NETBEANS-6172
> Project: NetBeans
>  Issue Type: Improvement
>  Components: javaee - Hibernate
>Affects Versions: 12.4
> Environment: Windows 10, NetBeans 12.0
>Reporter: Sergio García
>Assignee: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: LoginScaled.png, LoginScaled_Real.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
>  
>  In the latest versions of Netbeans I have been able to verify that the 
> Netbeans IDE is rescaled according to the latent configuration in Windows 10 
> (dpi); this new behavior is fine and improves the development environment. 
> However it is also a problem as it also visually rescales the GUIs in the 
> debugging process; i'm using Maven to compile and execute the program.
>  In my case, having a GUI adapted to the real size of my monitor screen is 
> important. I have tried to solve this problem by parameterizing the java with 
> commands like "-Dsun.java2d.uiScale = 1.0" or by disabling the windows 
> rescaling option that exists in the "java.exe" and "javaw.exe" properties but 
> this does not work for NetBeans. It also doesn't work to change the Netbeans 
> setting with the parameter "-J-Dsun.java2d.dpiaware = true".
>   
>  *It would be interesting to have a clear and functional way to avoid 
> rescaling windows to facilitate the visual design of the GUIs.*



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-6172) NetBeans screen scaling with Windows 10

2021-11-05 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-6172:
--
Labels: HiDPI  (was: performance)

> NetBeans screen scaling with Windows 10 
> 
>
> Key: NETBEANS-6172
> URL: https://issues.apache.org/jira/browse/NETBEANS-6172
> Project: NetBeans
>  Issue Type: Improvement
>  Components: javaee - Hibernate
>Affects Versions: 12.4
> Environment: Windows 10, NetBeans 12.0
>Reporter: Sergio García
>Assignee: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: LoginScaled.png, LoginScaled_Real.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
>  
>  In the latest versions of Netbeans I have been able to verify that the 
> Netbeans IDE is rescaled according to the latent configuration in Windows 10 
> (dpi); this new behavior is fine and improves the development environment. 
> However it is also a problem as it also visually rescales the GUIs in the 
> debugging process; i'm using Maven to compile and execute the program.
>  In my case, having a GUI adapted to the real size of my monitor screen is 
> important. I have tried to solve this problem by parameterizing the java with 
> commands like "-Dsun.java2d.uiScale = 1.0" or by disabling the windows 
> rescaling option that exists in the "java.exe" and "javaw.exe" properties but 
> this does not work for NetBeans. It also doesn't work to change the Netbeans 
> setting with the parameter "-J-Dsun.java2d.dpiaware = true".
>   
>  *It would be interesting to have a clear and functional way to avoid 
> rescaling windows to facilitate the visual design of the GUIs.*



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Resolved] (NETBEANS-4198) Bad text rendering for Test results on macOS, and with HiDPI scaling on Windows

2021-10-01 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANS-4198.
---
Fix Version/s: Next
   Resolution: Fixed

PR was merged; marking as resolved.

> Bad text rendering for Test results on macOS, and with HiDPI scaling on 
> Windows
> ---
>
> Key: NETBEANS-4198
> URL: https://issues.apache.org/jira/browse/NETBEANS-4198
> Project: NetBeans
>  Issue Type: Bug
>  Components: utilities - Test Runner
>Affects Versions: 11.3
>Reporter: Scott Palmer
>Priority: Minor
>  Labels: HiDPI, pull-request-available
> Fix For: Next
>
> Attachments: bad test text.jpg
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The message “Tests passed: XX%” is poorly rendered.  It’s like the alpha 
> channel is blending in a binary way.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Resolved] (NETBEANS-5931) Consolidate duplicated logic to set rendering hints

2021-09-29 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANS-5931.
---
Fix Version/s: Next
   Resolution: Fixed

PR was merged, marking fixed.

> Consolidate duplicated logic to set rendering hints
> ---
>
> Key: NETBEANS-5931
> URL: https://issues.apache.org/jira/browse/NETBEANS-5931
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Property Sheet
>Affects Versions: 12.4
> Environment: Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: pull-request-available
> Fix For: Next
>
> Attachments: NoAntialiasing.png
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> There is a lot of duplicated logic around the NetBeans codebase relating to 
> the setting of rendering hints on Graphics2D objects. I'll submit a PR to try 
> to consolidate this logic into a single utility method.
> (The PR for this issue will also fix a minor issue where non-editable text 
> values in the property sheet ended up not being anti-aliased. See attached 
> screenshot. With the new utility method, this becomes a one-line fix.)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Commented] (NETBEANS-2360) HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux

2021-09-13 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17414303#comment-17414303
 ] 

Eirik Bakke commented on NETBEANS-2360:
---

I tested the sun.java2d.uiScale property, but it doesn't support fractional 
scalings either. So I'll keep using GDK_SCALE, which is more official.

Would still be good to figure out how to detect the 2x scaling on openSUSE 
Tumbleweed/KDE.

[~hlavki] Do you have multiple monitors, by the way, or just the one shown in 
your control panel screenshot?

> HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux
> ---
>
> Key: NETBEANS-2360
> URL: https://issues.apache.org/jira/browse/NETBEANS-2360
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 11.0, 12.2
> Environment: Kubuntu 18.03
> Oracle JDK 11.0.2
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, Linux, pull-request-available
> Attachments: image-2021-09-12-21-01-33-807.png, 
> image-2021-09-12-21-05-06-852.png, kubunt.jpg
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Running NetBeans 11 on Kubuntu 18.03, GUI text size does not seem to take 
> into account the system's default HiDPI scaling. This was reported in a 
> Twitter thread on https://twitter.com/nicktail/status/1114789604337405952 . 
> Note that Window decorations seem to be the correct size.
> Setting the GDK_SCALE environment variable seems to fix the problem, if I 
> understand the originally reporter correctly. This could probably be done 
> easily from the NetBeans launcher script (netbeans/bin). But it wouldn't fix 
> the problem in multi-monitor setups. We should investigate what could be done 
> to make scaling work properly in multi-monitor setups involving one HiDPI 
> screen and one non-HiDPI screen.
> Before merging a patch to the launcher script, it should be tested on a 
> couple of different Linux environments, using both HiDPI and non-HiDPI 
> screens. Note that the UNIX launcher script is also used on MacOS.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Commented] (NETBEANS-2360) HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux

2021-09-12 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413790#comment-17413790
 ] 

Eirik Bakke commented on NETBEANS-2360:
---

Thanks, that is useful! Are all your other KDE apps scaled 2x? I.e. have you 
configured a HiDPI scaling somewhere in the KDE settings? Is there a "control 
panel" setting or such that this is configured from?

It would be useful to find out if there's another bash command that can be used 
to detect the desired scale factor, on your particular setup.

(And now I'm wondering if the NetBeans launch script should be setting 
sun.java2d.uiScale rather than GDK_SCALE... the former seems to support 
fractional scaling factors, and not just 2x scaling.)

> HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux
> ---
>
> Key: NETBEANS-2360
> URL: https://issues.apache.org/jira/browse/NETBEANS-2360
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 11.0, 12.2
> Environment: Kubuntu 18.03
> Oracle JDK 11.0.2
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, Linux, pull-request-available
> Attachments: image-2021-09-12-21-01-33-807.png, 
> image-2021-09-12-21-05-06-852.png, kubunt.jpg
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Running NetBeans 11 on Kubuntu 18.03, GUI text size does not seem to take 
> into account the system's default HiDPI scaling. This was reported in a 
> Twitter thread on https://twitter.com/nicktail/status/1114789604337405952 . 
> Note that Window decorations seem to be the correct size.
> Setting the GDK_SCALE environment variable seems to fix the problem, if I 
> understand the originally reporter correctly. This could probably be done 
> easily from the NetBeans launcher script (netbeans/bin). But it wouldn't fix 
> the problem in multi-monitor setups. We should investigate what could be done 
> to make scaling work properly in multi-monitor setups involving one HiDPI 
> screen and one non-HiDPI screen.
> Before merging a patch to the launcher script, it should be tested on a 
> couple of different Linux environments, using both HiDPI and non-HiDPI 
> screens. Note that the UNIX launcher script is also used on MacOS.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Commented] (NETBEANS-2360) HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux

2021-09-12 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413765#comment-17413765
 ] 

Eirik Bakke commented on NETBEANS-2360:
---

Hi Michal, thanks for testing! What kind of problem do you see? Are you 
expecting HiDPI scaling to be active (if so, which scale percentage?) And/or 
are you seeing problems with text anti-aliasing?

Could you also check the output of "echo $KDE_FULL_SESSION"? Thank you!


> HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux
> ---
>
> Key: NETBEANS-2360
> URL: https://issues.apache.org/jira/browse/NETBEANS-2360
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 11.0, 12.2
> Environment: Kubuntu 18.03
> Oracle JDK 11.0.2
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, Linux, pull-request-available
> Attachments: kubunt.jpg
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Running NetBeans 11 on Kubuntu 18.03, GUI text size does not seem to take 
> into account the system's default HiDPI scaling. This was reported in a 
> Twitter thread on https://twitter.com/nicktail/status/1114789604337405952 . 
> Note that Window decorations seem to be the correct size.
> Setting the GDK_SCALE environment variable seems to fix the problem, if I 
> understand the originally reporter correctly. This could probably be done 
> easily from the NetBeans launcher script (netbeans/bin). But it wouldn't fix 
> the problem in multi-monitor setups. We should investigate what could be done 
> to make scaling work properly in multi-monitor setups involving one HiDPI 
> screen and one non-HiDPI screen.
> Before merging a patch to the launcher script, it should be tested on a 
> couple of different Linux environments, using both HiDPI and non-HiDPI 
> screens. Note that the UNIX launcher script is also used on MacOS.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Created] (NETBEANS-5958) NPE at com.sun.tools.javac.comp.Modules.addVisiblePackages(Modules.java:1565)

2021-08-27 Thread Eirik Bakke (Jira)

Eirik Bakke created NETBEANS-5958:
-

 Summary: NPE at 
com.sun.tools.javac.comp.Modules.addVisiblePackages(Modules.java:1565)
 Key: NETBEANS-5958
 URL: https://issues.apache.org/jira/browse/NETBEANS-5958
 Project: NetBeans
  Issue Type: Bug
  Components: java - Compiler
Affects Versions: 12.4
 Environment: NetBeans 12.4 on Windows 10 on Java 11.0.11. nbjavac 
plugin _not_ installed.
Reporter: Eirik Bakke


In a Maven-based Java project on NetBeans 12.4 with Java 11 and Compile-on-Save 
enabled with vanilla javac (nbjavac _not_ installed), I'm getting frequent 
NullPointerException notifications. Here is one of these NPE stack traces:

{noformat}
SEVERE [org.openide.util.Exceptions]
java.lang.NullPointerException
at 
jdk.compiler/com.sun.tools.javac.comp.Modules.addVisiblePackages(Modules.java:1565)
at 
jdk.compiler/com.sun.tools.javac.comp.Modules.initVisiblePackages(Modules.java:1551)
at 
jdk.compiler/com.sun.tools.javac.comp.Modules$3.complete(Modules.java:1430)
at 
jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:642)
at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:272)
at 
jdk.compiler/com.sun.tools.javac.comp.Modules.initModules(Modules.java:233)
at 
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.initModules(JavaCompiler.java:1045)
at 
jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:328)
at 
jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.ensureEntered(JavacTaskImpl.java:481)
at 
jdk.compiler/com.sun.tools.javac.model.JavacElements.ensureEntered(JavacElements.java:779)
at 
jdk.compiler/com.sun.tools.javac.model.JavacElements.doGetTypeElement(JavacElements.java:171)
at 
jdk.compiler/com.sun.tools.javac.model.JavacElements.getTypeElement(JavacElements.java:160)
at 
jdk.compiler/com.sun.tools.javac.model.JavacElements.getTypeElement(JavacElements.java:87)
at 
org.netbeans.modules.java.source.parsing.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:395)
at 
org.netbeans.api.java.source.CompilationController.toPhase(CompilationController.java:88)
at 
org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$1.run(DeclarativeHintsParser.java:480)
at 
org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$1.run(DeclarativeHintsParser.java:477)
at 
org.netbeans.modules.java.source.parsing.MimeTask.run(MimeTask.java:60)
at 
org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
at 
org.netbeans.modules.parsing.api.ParserManager$MimeTaskAction.run(ParserManager.java:357)
at 
org.netbeans.modules.parsing.api.ParserManager$MimeTaskAction.run(ParserManager.java:340)
at 
org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
at 
org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
at 
org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
at 
org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
at 
org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
at 
org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
at 
org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
at 
org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:311)
at 
org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:431)
at 
org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:423)
at 
org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser.resolve(DeclarativeHintsParser.java:477)
at 
org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser.access$000(DeclarativeHintsParser.java:83)
at 
org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseCondition(DeclarativeHintsParser.java:311)
at 
org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseConditions(DeclarativeHintsParser.java:258)
at 
org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseRule(DeclarativeHintsParser.java:215)
at 
org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.parseInput(DeclarativeHintsParser.java:184)
at 
org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser$Impl.access$200(DeclarativeHintsParser.java:90)
at 
org.netbeans.modules.java.hints.declarative.DeclarativeHintsParser.parse(DeclarativeHintsParser.java:395)
at

[jira] [Resolved] (NETBEANS-5322) Anonymous innerclasses may be lost from the model with nb-javac.

2021-08-27 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANS-5322.
---
Resolution: Fixed

PR was merged; marking fixed.

> Anonymous innerclasses may be lost from the model with nb-javac.
> 
>
> Key: NETBEANS-5322
> URL: https://issues.apache.org/jira/browse/NETBEANS-5322
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 12.3
>Reporter: Jan Lahoda
>Assignee: Jan Lahoda
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Consider code like:
> {code:java}
> package javaapplication2;
> public class JavaApplication2 {
> public static void main(String[] args) {
> new Runnable() {
> };
> }
> }
> {code}
> There is an obvious compile-time error for the anonymous innerclass. When 
> running on e.g. JDK 15 without nb-javac, the provided fix works fine, and 
> generates the run method. When I install nb-javac, the fix stops to work, 
> unfortunately.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Resolved] (NETBEANS-5655) Invalid UTF-8 character when building on Windows

2021-08-27 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANS-5655.
---
Resolution: Fixed

PR was merged, marking fixed.

> Invalid UTF-8 character when building on Windows
> 
>
> Key: NETBEANS-5655
> URL: https://issues.apache.org/jira/browse/NETBEANS-5655
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 12.4
> Environment: Building NetBeans on Windows 10 from the Windows command 
> line (not WSL).
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Doing a build on Windows, the following error occurs:
> {{BUILD FAILED}}
> {{C:\Users\ebakke\ZRoot\nbsrc\incubator-netbeans\nbbuild\build.xml:395: The 
> following error occurred while executing this line:}}
> {{C:\Users\ebakke\ZRoot\nbsrc\incubator-netbeans\nbbuild\javadoctools\build.xml:48:
>  The following error occurred while executing this line:}}
> {{C:\Users\ebakke\ZRoot\nbsrc\incubator-netbeans\nbbuild\javadoctools\build.xml:149:
>  javax.xml.transform.TransformerException: 
> javax.xml.transform.TransformerException: 
> com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Invalid byte 3 
> of 3-byte UTF-8 sequence.}}
> Examining build.xml:149, it points to the file 
> nbbuild/build/javadoc/alldatas.xml, which indeed appears to have a malformed 
> UTF-8 character somewhere.
> Doing some further investigation...
> {{ebakke@EBLEN:/z/nbsrc/incubator-netbeans/nbbuild/build/javadoc$ diff 
> alldatas1.xml alldatas2.xml}}
> {{5139c5139}}
> {{< when running in “compile-on-save? mode}}
> {{---}}
> {{> when running in “compile-on-save�? mode}}
> Will submit a PR.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Resolved] (NETBEANS-5726) Checkmark next to "Show Editor Toolbar" menu item can get out of sync with actual setting

2021-08-27 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke resolved NETBEANS-5726.
---
Resolution: Fixed

PR was merged, marking fixed.

> Checkmark next to "Show Editor Toolbar" menu item can get out of sync with 
> actual setting
> -
>
> Key: NETBEANS-5726
> URL: https://issues.apache.org/jira/browse/NETBEANS-5726
> Project: NetBeans
>  Issue Type: Improvement
>  Components: editor - Options
>Affects Versions: 12.2
> Environment: All OSes.
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The checkmark next to the "Show Editor Toolbar" menu item can get out of sync 
> with actual setting.
> To reproduce:
> 1) Open a file for editing in the NetBeans editor.
> 2) Click View->"Show Only Editor"
> 3) Click View->"Show Editor Toolbar"
> 4) Click View->"Show Only Editor"
> 5) Click View->"Show Editor Toolbar"
> 6) There's now a checkmark next to View->"Show Editor Toolbar", even though 
> there is no editor toolbar showing.
> It seems the checkbox in the menu is inverted on every click rather than 
> properly being bound to the underlying "toolbarVisible" preference from the 
> java.util.prefs.Preferences system, which is (rightly) modified by the "Show 
> Only Editor" action.
> (This bug report is a copy of the old BugZilla bug 
> https://bz.apache.org/netbeans/show_bug.cgi?id=240513 .)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Comment Edited] (NETBEANS-5914) NetBeans 12.4 freezes on startup

2021-08-26 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405356#comment-17405356
 ] 

Eirik Bakke edited comment on NETBEANS-5914 at 8/26/21, 4:43 PM:
-

It's not an issue I can reproduce on demand, unfortunately, and I haven't seen 
it occur for several months. There were about 20 Maven-based NetBeans module 
projects open, and the deadlock would occur on IDE startup (rather than while 
building the projects).

Was there a patch in 12.5 already with regards to this bug? If my IDE enters a 
state again where it becomes possible to trigger the deadlock by restarting, I 
can try with and without a patch. Otherwise I think the only way to "confirm" 
solutions to these kinds of bugs is to stare hard at the original thread dump 
and the resulting patch...


was (Author: ebakke):
It's not an issue I can reproduce on demand, unfortunately, and I haven't seen 
it occur for several months. There were about 20 Maven-based NetBeans module 
projects open, and the deadlock would occur on IDE startup.

Was there a patch in 12.5 already with regards to this bug? If my IDE enters a 
state again where it becomes possible to trigger the deadlock by restarting, I 
can try with and without a patch. Otherwise I think the only way to "confirm" 
solutions to these kinds of bugs is to stare hard at the original thread dump 
and the resulting patch...

> NetBeans 12.4 freezes on startup
> 
>
> Key: NETBEANS-5914
> URL: https://issues.apache.org/jira/browse/NETBEANS-5914
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 12.5
> Environment: NetBeans 12.4 on Zulu/OpenJDK 11 on Windows 10.
>Reporter: Eirik Bakke
>Assignee: Jaroslav Tulach
>Priority: Blocker
> Attachments: 12.5-beta2-threaddump-1629986898821.tdump, 210506 
> NetBeans Deadlock on Startup 2.txt, 210506 NetBeans Deadlock on Startup.txt, 
> 210516 Another NetBeans Deadlock.txt, 210526 NetBeans Deadlock again.txt
>
>
> On NetBeans 12.4, I was previously experiencing some intermittent freezes on 
> startup, at the time when projects were being loaded and such. I did some 
> thread dumps of the frozen IDE using VisualVM. I'm uploading these now in 
> case they are related to NETBEANS-5913.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Commented] (NETBEANS-5914) NetBeans 12.4 freezes on startup

2021-08-26 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405356#comment-17405356
 ] 

Eirik Bakke commented on NETBEANS-5914:
---

It's not an issue I can reproduce on demand, unfortunately, and I haven't seen 
it occur for several months. There were about 20 Maven-based NetBeans module 
projects open, and the deadlock would occur on IDE startup.

Was there a patch in 12.5 already with regards to this bug? If my IDE enters a 
state again where it becomes possible to trigger the deadlock by restarting, I 
can try with and without a patch. Otherwise I think the only way to "confirm" 
solutions to these kinds of bugs is to stare hard at the original thread dump 
and the resulting patch...

> NetBeans 12.4 freezes on startup
> 
>
> Key: NETBEANS-5914
> URL: https://issues.apache.org/jira/browse/NETBEANS-5914
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 12.5
> Environment: NetBeans 12.4 on Zulu/OpenJDK 11 on Windows 10.
>Reporter: Eirik Bakke
>Assignee: Jaroslav Tulach
>Priority: Blocker
> Attachments: 12.5-beta2-threaddump-1629986898821.tdump, 210506 
> NetBeans Deadlock on Startup 2.txt, 210506 NetBeans Deadlock on Startup.txt, 
> 210516 Another NetBeans Deadlock.txt, 210526 NetBeans Deadlock again.txt
>
>
> On NetBeans 12.4, I was previously experiencing some intermittent freezes on 
> startup, at the time when projects were being loaded and such. I did some 
> thread dumps of the frozen IDE using VisualVM. I'm uploading these now in 
> case they are related to NETBEANS-5913.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5931) Consolidate duplicated logic to set rendering hints

2021-08-18 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5931:
--
Description: 
There is a lot of duplicated logic around the NetBeans codebase relating to the 
setting of rendering hints on Graphics2D objects. I'll submit a PR to try to 
consolidate this logic into a single utility method.

(The PR for this issue will also fix a minor issue where non-editable text 
values in the property sheet ended up not being anti-aliased. See attached 
screenshot. With the new utility method, this becomes a one-line fix.)

  was:
There is also a lot of duplicated logic around the NetBeans codebase relating 
to the setting of rendering hints on Graphics2D objects. I'll submit a PR to 
try to consolidate this logic into a single utility method.

(The PR for this issue will also fix a minor issue where non-editable text 
values in the property sheet ended up not being anti-aliased. See attached 
screenshot. With the new utility method, this becomes a one-line fix.)


> Consolidate duplicated logic to set rendering hints
> ---
>
> Key: NETBEANS-5931
> URL: https://issues.apache.org/jira/browse/NETBEANS-5931
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Property Sheet
>Affects Versions: 12.4
> Environment: Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: NoAntialiasing.png
>
>
> There is a lot of duplicated logic around the NetBeans codebase relating to 
> the setting of rendering hints on Graphics2D objects. I'll submit a PR to try 
> to consolidate this logic into a single utility method.
> (The PR for this issue will also fix a minor issue where non-editable text 
> values in the property sheet ended up not being anti-aliased. See attached 
> screenshot. With the new utility method, this becomes a one-line fix.)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5931) Consolidate duplicated logic to set rendering hints

2021-08-18 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5931:
--
Description: 
There is also a lot of duplicated logic around the NetBeans codebase relating 
to the setting of rendering hints on Graphics2D objects. I'll submit a PR to 
try to consolidate this logic into a single utility method.

(The PR for this issue will also fix a minor issue where non-editable text 
values in the property sheet ended up not being anti-aliased. See attached 
screenshot. With the new utility method, this becomes a one-line fix.)

  was:
There is also a lot of duplicated logic around the NetBeans codebase relating 
to the setting of rendering hints on Graphics2D objects. I'll submit a PR to 
try to consolidate this logic into a single utility method.

(The PR for this issue will also fix a minor issue where non-editable text 
values in the property sheet ended up not being anti-aliased. See attached 
screenshot.)


> Consolidate duplicated logic to set rendering hints
> ---
>
> Key: NETBEANS-5931
> URL: https://issues.apache.org/jira/browse/NETBEANS-5931
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Property Sheet
>Affects Versions: 12.4
> Environment: Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: NoAntialiasing.png
>
>
> There is also a lot of duplicated logic around the NetBeans codebase relating 
> to the setting of rendering hints on Graphics2D objects. I'll submit a PR to 
> try to consolidate this logic into a single utility method.
> (The PR for this issue will also fix a minor issue where non-editable text 
> values in the property sheet ended up not being anti-aliased. See attached 
> screenshot. With the new utility method, this becomes a one-line fix.)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5931) Consolidate duplicated logic to set rendering hints

2021-08-18 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5931:
--
Description: 
There is also a lot of duplicated logic around the NetBeans codebase relating 
to the setting of rendering hints on Graphics2D objects. I'll submit a PR to 
try to consolidate this logic into a single utility method.

(The PR for this issue will also fix a minotr issue where non-editable text 
values in the property sheet ended up not being anti-aliased. See attached 
screenshot.)

  was:On the Windows LAF, non-editable text values in the property sheet end up 
not being anti-aliased. This is due to manual painting being done in the 
disabled case, without setting rendering hints. See the attached screenshot.


> Consolidate duplicated logic to set rendering hints
> ---
>
> Key: NETBEANS-5931
> URL: https://issues.apache.org/jira/browse/NETBEANS-5931
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Property Sheet
>Affects Versions: 12.4
> Environment: Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: NoAntialiasing.png
>
>
> There is also a lot of duplicated logic around the NetBeans codebase relating 
> to the setting of rendering hints on Graphics2D objects. I'll submit a PR to 
> try to consolidate this logic into a single utility method.
> (The PR for this issue will also fix a minotr issue where non-editable text 
> values in the property sheet ended up not being anti-aliased. See attached 
> screenshot.)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5931) Consolidate duplicated logic to set rendering hints

2021-08-18 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5931:
--
Description: 
There is also a lot of duplicated logic around the NetBeans codebase relating 
to the setting of rendering hints on Graphics2D objects. I'll submit a PR to 
try to consolidate this logic into a single utility method.

(The PR for this issue will also fix a minor issue where non-editable text 
values in the property sheet ended up not being anti-aliased. See attached 
screenshot.)

  was:
There is also a lot of duplicated logic around the NetBeans codebase relating 
to the setting of rendering hints on Graphics2D objects. I'll submit a PR to 
try to consolidate this logic into a single utility method.

(The PR for this issue will also fix a minotr issue where non-editable text 
values in the property sheet ended up not being anti-aliased. See attached 
screenshot.)


> Consolidate duplicated logic to set rendering hints
> ---
>
> Key: NETBEANS-5931
> URL: https://issues.apache.org/jira/browse/NETBEANS-5931
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Property Sheet
>Affects Versions: 12.4
> Environment: Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: NoAntialiasing.png
>
>
> There is also a lot of duplicated logic around the NetBeans codebase relating 
> to the setting of rendering hints on Graphics2D objects. I'll submit a PR to 
> try to consolidate this logic into a single utility method.
> (The PR for this issue will also fix a minor issue where non-editable text 
> values in the property sheet ended up not being anti-aliased. See attached 
> screenshot.)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5931) Consolidate duplicated logic to set rendering hints

2021-08-18 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5931:
--
Summary: Consolidate duplicated logic to set rendering hints  (was: Missing 
anti-aliasing in property sheet (Windows LAF))

> Consolidate duplicated logic to set rendering hints
> ---
>
> Key: NETBEANS-5931
> URL: https://issues.apache.org/jira/browse/NETBEANS-5931
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Property Sheet
>Affects Versions: 12.4
> Environment: Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: NoAntialiasing.png
>
>
> On the Windows LAF, non-editable text values in the property sheet end up not 
> being anti-aliased. This is due to manual painting being done in the disabled 
> case, without setting rendering hints. See the attached screenshot.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5931) Missing anti-aliasing in property sheet (Windows LAF)

2021-08-18 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5931:
--
Summary: Missing anti-aliasing in property sheet (Windows LAF)  (was: 
Missing anti-aliasing in property sheet (Windows LAF)+consolidate rendering 
hints)

> Missing anti-aliasing in property sheet (Windows LAF)
> -
>
> Key: NETBEANS-5931
> URL: https://issues.apache.org/jira/browse/NETBEANS-5931
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Property Sheet
>Affects Versions: 12.4
> Environment: Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: NoAntialiasing.png
>
>
> On the Windows LAF, non-editable text values in the property sheet end up not 
> being anti-aliased. This is due to manual painting being done in the disabled 
> case, without setting rendering hints. See the attached screenshot.
> There is also a lot of duplicated logic around the NetBeans codebase relating 
> to the setting of rendering hints on Graphics2D objects. Rather than 
> duplicate this logic one more time, the PR for this issue will add a new 
> utility method for this and consolidate the existing occurrences.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5931) Missing anti-aliasing in property sheet (Windows LAF)

2021-08-18 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5931:
--
Description: On the Windows LAF, non-editable text values in the property 
sheet end up not being anti-aliased. This is due to manual painting being done 
in the disabled case, without setting rendering hints. See the attached 
screenshot.  (was: On the Windows LAF, non-editable text values in the property 
sheet end up not being anti-aliased. This is due to manual painting being done 
in the disabled case, without setting rendering hints. See the attached 
screenshot.

There is also a lot of duplicated logic around the NetBeans codebase relating 
to the setting of rendering hints on Graphics2D objects. Rather than duplicate 
this logic one more time, the PR for this issue will add a new utility method 
for this and consolidate the existing occurrences.)

> Missing anti-aliasing in property sheet (Windows LAF)
> -
>
> Key: NETBEANS-5931
> URL: https://issues.apache.org/jira/browse/NETBEANS-5931
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Property Sheet
>Affects Versions: 12.4
> Environment: Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: NoAntialiasing.png
>
>
> On the Windows LAF, non-editable text values in the property sheet end up not 
> being anti-aliased. This is due to manual painting being done in the disabled 
> case, without setting rendering hints. See the attached screenshot.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5931) Missing anti-aliasing in property sheet (Windows LAF)+consolidate rendering hints

2021-08-18 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5931:
--
Summary: Missing anti-aliasing in property sheet (Windows LAF)+consolidate 
rendering hints  (was: Missing anti-aliasing in property sheet (Windows 
LAF)+consolidate rendering hint)

> Missing anti-aliasing in property sheet (Windows LAF)+consolidate rendering 
> hints
> -
>
> Key: NETBEANS-5931
> URL: https://issues.apache.org/jira/browse/NETBEANS-5931
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Property Sheet
>Affects Versions: 12.4
> Environment: Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: NoAntialiasing.png
>
>
> On the Windows LAF, non-editable text values in the property sheet end up not 
> being anti-aliased. This is due to manual painting being done in the disabled 
> case, without setting rendering hints. See the attached screenshot.
> There is also a lot of duplicated logic around the NetBeans codebase relating 
> to the setting of rendering hints on Graphics2D objects. Rather than 
> duplicate this logic one more time, the PR for this issue will add a new 
> utility method for this and consolidate the existing occurrences.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5931) Missing anti-aliasing in property sheet (Windows LAF)+consolidate rendering hint

2021-08-18 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5931:
--
Description: 
On the Windows LAF, non-editable text values in the property sheet end up not 
being anti-aliased. This is due to manual painting being done in the disabled 
case, without setting rendering hints. See the attached screenshot.

There is also a lot of duplicated logic around the NetBeans codebase relating 
to the setting of rendering hints on Graphics2D objects. Rather than duplicate 
this logic one more time, the PR for this issue will add a new utility method 
for this and consolidate the existing occurrences.

  was:
On the Windows LAF, disabled text values in the property sheet end up not being 
anti-aliased. This is due to manual painting being done in the disabled case, 
without setting rendering hints. See the attached screenshot.

There is also a lot of duplicated logic around the NetBeans codebase relating 
to the setting of rendering hints on Graphics2D objects. Rather than duplicate 
this logic one more time, the PR for this issue will add a new utility method 
for this and consolidate the existing occurrences.


> Missing anti-aliasing in property sheet (Windows LAF)+consolidate rendering 
> hint
> 
>
> Key: NETBEANS-5931
> URL: https://issues.apache.org/jira/browse/NETBEANS-5931
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Property Sheet
>Affects Versions: 12.4
> Environment: Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: NoAntialiasing.png
>
>
> On the Windows LAF, non-editable text values in the property sheet end up not 
> being anti-aliased. This is due to manual painting being done in the disabled 
> case, without setting rendering hints. See the attached screenshot.
> There is also a lot of duplicated logic around the NetBeans codebase relating 
> to the setting of rendering hints on Graphics2D objects. Rather than 
> duplicate this logic one more time, the PR for this issue will add a new 
> utility method for this and consolidate the existing occurrences.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5931) Missing anti-aliasing in property sheet (Windows LAF)+consolidate rendering hint

2021-08-18 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5931:
--
Attachment: NoAntialiasing.png

> Missing anti-aliasing in property sheet (Windows LAF)+consolidate rendering 
> hint
> 
>
> Key: NETBEANS-5931
> URL: https://issues.apache.org/jira/browse/NETBEANS-5931
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Property Sheet
>Affects Versions: 12.4
> Environment: Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: NoAntialiasing.png
>
>
> On the Windows LAF, disabled text values in the property sheet end up not 
> being anti-aliased. This is due to manual painting being done in the disabled 
> case, without setting rendering hints.
> There is also a lot of duplicated logic around the NetBeans codebase relating 
> to the setting of rendering hints on Graphics2D objects. Rather than 
> duplicate this logic one more time, the PR for this issue will add a new 
> utility method for this and consolidate the existing occurrences.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5931) Missing anti-aliasing in property sheet (Windows LAF)+consolidate rendering hint

2021-08-18 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5931:
--
Description: 
On the Windows LAF, disabled text values in the property sheet end up not being 
anti-aliased. This is due to manual painting being done in the disabled case, 
without setting rendering hints. See the attached screenshot.

There is also a lot of duplicated logic around the NetBeans codebase relating 
to the setting of rendering hints on Graphics2D objects. Rather than duplicate 
this logic one more time, the PR for this issue will add a new utility method 
for this and consolidate the existing occurrences.

  was:
On the Windows LAF, disabled text values in the property sheet end up not being 
anti-aliased. This is due to manual painting being done in the disabled case, 
without setting rendering hints.

There is also a lot of duplicated logic around the NetBeans codebase relating 
to the setting of rendering hints on Graphics2D objects. Rather than duplicate 
this logic one more time, the PR for this issue will add a new utility method 
for this and consolidate the existing occurrences.


> Missing anti-aliasing in property sheet (Windows LAF)+consolidate rendering 
> hint
> 
>
> Key: NETBEANS-5931
> URL: https://issues.apache.org/jira/browse/NETBEANS-5931
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Property Sheet
>Affects Versions: 12.4
> Environment: Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: NoAntialiasing.png
>
>
> On the Windows LAF, disabled text values in the property sheet end up not 
> being anti-aliased. This is due to manual painting being done in the disabled 
> case, without setting rendering hints. See the attached screenshot.
> There is also a lot of duplicated logic around the NetBeans codebase relating 
> to the setting of rendering hints on Graphics2D objects. Rather than 
> duplicate this logic one more time, the PR for this issue will add a new 
> utility method for this and consolidate the existing occurrences.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Created] (NETBEANS-5931) Missing anti-aliasing in property sheet (Windows LAF)+consolidate rendering hint

2021-08-18 Thread Eirik Bakke (Jira)

Eirik Bakke created NETBEANS-5931:
-

 Summary: Missing anti-aliasing in property sheet (Windows 
LAF)+consolidate rendering hint
 Key: NETBEANS-5931
 URL: https://issues.apache.org/jira/browse/NETBEANS-5931
 Project: NetBeans
  Issue Type: Bug
  Components: platform - Property Sheet
Affects Versions: 12.4
 Environment: Windows LAF on Windows 10.
Reporter: Eirik Bakke


On the Windows LAF, disabled text values in the property sheet end up not being 
anti-aliased. This is due to manual painting being done in the disabled case, 
without setting rendering hints.

There is also a lot of duplicated logic around the NetBeans codebase relating 
to the setting of rendering hints on Graphics2D objects. Rather than duplicate 
this logic one more time, the PR for this issue will add a new utility method 
for this and consolidate the existing occurrences.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5928) Proposed improvements to FlatLAF tab components+borders/margins

2021-08-18 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5928:
--
Labels: HiDPI pull-request-available  (was: pull-request-available)

> Proposed improvements to FlatLAF tab components+borders/margins
> ---
>
> Key: NETBEANS-5928
> URL: https://issues.apache.org/jira/browse/NETBEANS-5928
> Project: NetBeans
>  Issue Type: Improvement
>  Components: FlatLaf
>Affects Versions: 12.4
> Environment: Windows, MacOS, and Linux with FlatLAF Light and FlatLAF 
> Dark
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, pull-request-available
> Attachments: flatlaf-dark-1-before.png, flatlaf-dark-2-after.png, 
> flatlaf-light-1-before.png, flatlaf-light-2-after.png
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> In a previous PR ( https://github.com/apache/netbeans/pull/2967 ), the tab 
> components in the NetBeans window system were redesigned and modernized for 
> the Windows LAF. This PR ports related tabcontrol improvements back into 
> FlatLAF, and proposes a similar tab style for FlatLAF. See the attached 
> screenshots.
> The proposed style, compared to the current FlatLAF style, makes the selected 
> tab look like an actual "tab" with an actual rectangular border around it, 
> while keeping the much simpler "separators only" look for unselected tabs. 
> The proposed style also tightens up vertical space significantly, like in 
> other LAFs. See the attached screenshots. The new tab controls work well on 
> all HiDPI scaling levels, and on all platforms (Windows, Linux, MacOS).
> Advantages of the proposed tabcontrol style:
> * Other applications that have tabs as part of their window system still tend 
> to render at least the active window system tab as an actual "tabs", e.g. 
> Chrome, Excel, Photoshop, Unity.
> * Personally, I find it hard to orient my eyes around the old FlatLAF tab 
> style; the drawn selected tab seems to fix this. (Hard to explain in a fully 
> objective way!)
> * The tab content areas (contents of editor, projects pane, navigator pane 
> etc.) has borders around them, so it is logical that the border continues 
> around the tab that is associated with them.
> * Conserve vertical space. Modern monitors have tended to become wider but 
> not taller. With e.g. 2x HiDPI scaling (as on all MacBooks), there may 
> actually be _fewer_ logical pixels available in the vertical direction than 
> on older laptop screens.
> This PR also removes an extraneous border around the editor area, and 
> introduces a little bit of extra space in the toolbar area.
> I've been using FlatLAF as the default LAF on Linux for my NetBeans Platform 
> application. It handles HiDPI scaling very well, and it's getting really 
> solid--thanks to @DevCharly for all his work on it!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5928) Proposed improvements to FlatLAF tab components+borders/margins

2021-08-17 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5928:
--
Description: 
In a previous PR ( https://github.com/apache/netbeans/pull/2967 ), the tab 
components in the NetBeans window system were redesigned and modernized for the 
Windows LAF. This PR ports related tabcontrol improvements back into FlatLAF, 
and proposes a similar tab style for FlatLAF. See the attached screenshots.

The proposed style, compared to the current FlatLAF style, makes the selected 
tab look like an actual "tab" with an actual rectangular border around it, 
while keeping the much simpler "separators only" look for unselected tabs. The 
proposed style also tightens up vertical space significantly, like in other 
LAFs. See the attached screenshots. The new tab controls work well on all HiDPI 
scaling levels, and on all platforms (Windows, Linux, MacOS).

Advantages of the proposed tabcontrol style:
* Other applications that have tabs as part of their window system still tend 
to render at least the active window system tab as an actual "tabs", e.g. 
Chrome, Excel, Photoshop, Unity.
* Personally, I find it hard to orient my eyes around the old FlatLAF tab 
style; the drawn selected tab seems to fix this. (Hard to explain in a fully 
objective way!)
* The tab content areas (contents of editor, projects pane, navigator pane 
etc.) has borders around them, so it is logical that the border continues 
around the tab that is associated with them.
* Conserve vertical space. Modern monitors have tended to become wider but not 
taller. With e.g. 2x HiDPI scaling (as on all MacBooks), there may actually be 
_fewer_ logical pixels available in the vertical direction than on older laptop 
screens.

This PR also removes an extraneous border around the editor area, and 
introduces a little bit of extra space in the toolbar area.

I've been using FlatLAF as the default LAF on Linux for my NetBeans Platform 
application. It handles HiDPI scaling very well, and it's getting really 
solid--thanks to @DevCharly for all his work on it!

  was:
In a previous PR ( https://github.com/apache/netbeans/pull/2967 ), the tab 
components in the NetBeans window system were redesigned and modernized for the 
Windows LAF. This PR ports related tabcontrol improvements back into FlatLAF, 
and proposes a similar tab style for FlatLAF. See the attached screenshots.

The proposed style, compared to the current FlatLAF style, makes the selected 
tab look like an actual "tab" with an actual rectangular border around it, 
while keeping the much simpler "separators only" look for unselected tabs. The 
proposed style also tightens up vertical space significantly, like in other 
LAFs. See the attached screenshots. The new tab controls work well on all HiDPI 
scaling levels, and on all platforms (Windows, Linux, MacOS).

Advantages of the proposed tabcontrol style:
* Other applications that have tabs as part of their window system still tend 
to render at least the active window system tab as an actual "tabs", e.g. 
Chrome, Excel, Photoshop, Unity.
* Personally, I find it hard to orient my eyes around the old FlatLAF tab 
style; the drawn selected tab seems to fix this. (Hard to explain in a fully 
objective way!)
* The tab content areas (contents of editor, projects pane, navigator pane 
etc.) has borders around them, so it is logical that the border continues 
around the tab that is associated with them.
* Conserve vertical space. Modern monitors have tended to become wider but not 
taller. With e.g. 2x HiDPI scaling (as on all MacBooks), there may actually be 
_fewer_ logical pixels available in the vertical direction than on older laptop 
screens.

This PR also removes an extraneous border around the editor area, and 
introduces a little bit of extra space in the toolbar area.


> Proposed improvements to FlatLAF tab components+borders/margins
> ---
>
> Key: NETBEANS-5928
> URL: https://issues.apache.org/jira/browse/NETBEANS-5928
> Project: NetBeans
>  Issue Type: Improvement
>  Components: FlatLaf
>Affects Versions: 12.4
> Environment: Windows, MacOS, and Linux with FlatLAF Light and FlatLAF 
> Dark
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: flatlaf-dark-1-before.png, flatlaf-dark-2-after.png, 
> flatlaf-light-1-before.png, flatlaf-light-2-after.png
>
>
> In a previous PR ( https://github.com/apache/netbeans/pull/2967 ), the tab 
> components in the NetBeans window system were redesigned and modernized for 
> the Windows LAF. This PR ports related tabcontrol improvements back into 
> FlatLAF, and proposes a similar tab style for FlatLAF. See the attached 
> screenshots.
> The proposed style, compared to the current FlatLAF style, makes the selected 
>

[jira] [Updated] (NETBEANS-5928) Proposed improvements to FlatLAF tab components+borders/margins

2021-08-17 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5928:
--
Description: 
In a previous PR ( https://github.com/apache/netbeans/pull/2967 ), the tab 
components in the NetBeans window system were redesigned and modernized for the 
Windows LAF. This PR ports related tabcontrol improvements back into FlatLAF, 
and proposes a similar tab style for FlatLAF. See the attached screenshots.

The proposed style, compared to the current FlatLAF style, makes the selected 
tab look like an actual "tab" with an actual rectangular border around it, 
while keeping the much simpler "separators only" look for unselected tabs. The 
proposed style also tightens up vertical space significantly, like in other 
LAFs. See the attached screenshots. The new tab controls work well on all HiDPI 
scaling levels, and on all platforms (Windows, Linux, MacOS).

Advantages of the proposed tabcontrol style:
* Other applications that have tabs as part of their window system still tend 
to render at least the active window system tab as an actual "tabs", e.g. 
Chrome, Excel, Photoshop, Unity.
* Personally, I find it hard to orient my eyes around the old FlatLAF tab 
style; the drawn selected tab seems to fix this. (Hard to explain in a fully 
objective way!)
* The tab content areas (contents of editor, projects pane, navigator pane 
etc.) has borders around them, so it is logical that the border continues 
around the tab that is associated with them.
* Conserve vertical space. Modern monitors have tended to become wider but not 
taller. With e.g. 2x HiDPI scaling (as on all MacBooks), there may actually be 
_fewer_ logical pixels available in the vertical direction than on older laptop 
screens.

This PR also removes an extraneous border around the editor area, and 
introduces a little bit of extra space in the toolbar area.

  was:
In a previous PR ( https://github.com/apache/netbeans/pull/2967 ), the tab 
components in the NetBeans window system were redesigned and modernized for the 
Windows LAF. This PR ports related tabcontrol improvements back into FlatLAF, 
and proposes a similar visual style. See the attached screenshots.

The proposed style, compared to the current FlatLAF style, makes the selected 
tab look like an actual "tab" with an actual rectangular border around it, 
while keeping the much simpler "separators only" look for unselected tabs. The 
proposed style also tightens up vertical space significantly, like in other 
LAFs. See the attached screenshots. The new tab controls work well on all HiDPI 
scaling levels, and on all platforms (Windows, Linux, MacOS).

This PR also removes an extraneous border around the editor area, and 
introduces a little bit of extra space in the toolbar area.


> Proposed improvements to FlatLAF tab components+borders/margins
> ---
>
> Key: NETBEANS-5928
> URL: https://issues.apache.org/jira/browse/NETBEANS-5928
> Project: NetBeans
>  Issue Type: Improvement
>  Components: FlatLaf
>Affects Versions: 12.4
> Environment: Windows, MacOS, and Linux with FlatLAF Light and FlatLAF 
> Dark
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: flatlaf-dark-1-before.png, flatlaf-dark-2-after.png, 
> flatlaf-light-1-before.png, flatlaf-light-2-after.png
>
>
> In a previous PR ( https://github.com/apache/netbeans/pull/2967 ), the tab 
> components in the NetBeans window system were redesigned and modernized for 
> the Windows LAF. This PR ports related tabcontrol improvements back into 
> FlatLAF, and proposes a similar tab style for FlatLAF. See the attached 
> screenshots.
> The proposed style, compared to the current FlatLAF style, makes the selected 
> tab look like an actual "tab" with an actual rectangular border around it, 
> while keeping the much simpler "separators only" look for unselected tabs. 
> The proposed style also tightens up vertical space significantly, like in 
> other LAFs. See the attached screenshots. The new tab controls work well on 
> all HiDPI scaling levels, and on all platforms (Windows, Linux, MacOS).
> Advantages of the proposed tabcontrol style:
> * Other applications that have tabs as part of their window system still tend 
> to render at least the active window system tab as an actual "tabs", e.g. 
> Chrome, Excel, Photoshop, Unity.
> * Personally, I find it hard to orient my eyes around the old FlatLAF tab 
> style; the drawn selected tab seems to fix this. (Hard to explain in a fully 
> objective way!)
> * The tab content areas (contents of editor, projects pane, navigator pane 
> etc.) has borders around them, so it is logical that the border continues 
> around the tab that is associated with them.
> * Conserve vertical space. Modern monitors have tended to

[jira] [Updated] (NETBEANS-5928) Proposed improvements to FlatLAF tab components+borders/margins

2021-08-17 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5928:
--
Attachment: flatlaf-light-1-before.png
flatlaf-light-2-after.png
flatlaf-dark-1-before.png
flatlaf-dark-2-after.png

> Proposed improvements to FlatLAF tab components+borders/margins
> ---
>
> Key: NETBEANS-5928
> URL: https://issues.apache.org/jira/browse/NETBEANS-5928
> Project: NetBeans
>  Issue Type: Improvement
>  Components: FlatLaf
>Affects Versions: 12.4
> Environment: Windows, MacOS, and Linux with FlatLAF Light and FlatLAF 
> Dark
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: flatlaf-dark-1-before.png, flatlaf-dark-2-after.png, 
> flatlaf-light-1-before.png, flatlaf-light-2-after.png
>
>
> In a previous PR ( https://github.com/apache/netbeans/pull/2967 ), the tab 
> components in the NetBeans window system were redesigned and modernized for 
> the Windows LAF. This PR ports related tabcontrol improvements back into 
> FlatLAF, and proposes a similar visual style. See the attached screenshots.
> The proposed style, compared to the current FlatLAF style, makes the selected 
> tab look like an actual "tab" with an actual rectangular border around it, 
> while keeping the much simpler "separators only" look for unselected tabs. 
> The proposed style also tightens up vertical space significantly, like in 
> other LAFs. See the attached screenshots. The new tab controls work well on 
> all HiDPI scaling levels, and on all platforms (Windows, Linux, MacOS).
> This PR also removes an extraneous border around the editor area, and 
> introduces a little bit of extra space in the toolbar area.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Created] (NETBEANS-5928) Proposed improvements to FlatLAF tab components+borders/margins

2021-08-17 Thread Eirik Bakke (Jira)

Eirik Bakke created NETBEANS-5928:
-

 Summary: Proposed improvements to FlatLAF tab 
components+borders/margins
 Key: NETBEANS-5928
 URL: https://issues.apache.org/jira/browse/NETBEANS-5928
 Project: NetBeans
  Issue Type: Improvement
  Components: FlatLaf
Affects Versions: 12.4
 Environment: Windows, MacOS, and Linux with FlatLAF Light and FlatLAF 
Dark
Reporter: Eirik Bakke
 Attachments: flatlaf-dark-1-before.png, flatlaf-dark-2-after.png, 
flatlaf-light-1-before.png, flatlaf-light-2-after.png

In a previous PR ( https://github.com/apache/netbeans/pull/2967 ), the tab 
components in the NetBeans window system were redesigned and modernized for the 
Windows LAF. This PR ports related tabcontrol improvements back into FlatLAF, 
and proposes a similar visual style. See the attached screenshots.

The proposed style, compared to the current FlatLAF style, makes the selected 
tab look like an actual "tab" with an actual rectangular border around it, 
while keeping the much simpler "separators only" look for unselected tabs. The 
proposed style also tightens up vertical space significantly, like in other 
LAFs. See the attached screenshots. The new tab controls work well on all HiDPI 
scaling levels, and on all platforms (Windows, Linux, MacOS).

This PR also removes an extraneous border around the editor area, and 
introduces a little bit of extra space in the toolbar area.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5927) Switch Windows LAF to the now-standard "Segoe UI" font

2021-08-17 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5927:
--
Attachment: fontchange-1-before.png

> Switch Windows LAF to the now-standard "Segoe UI" font
> --
>
> Key: NETBEANS-5927
> URL: https://issues.apache.org/jira/browse/NETBEANS-5927
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Other
>Affects Versions: 12.4
> Environment: NetBeans 12.4 with Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: fontchange-1-before.png, fontchange-2-after.png
>
>
> For the last 14 years (since Windows Vista), the default UI font on Windows 
> has been Segoe UI 12. But Swing's Windows LAF stayed with Tahoma 11, for 
> reasons of backwards compatibility only (see JDK-6669448). This makes 
> NetBeans look a little dated, and the font size smaller than in other Windows 
> application. In the words of one blogger: "On a related note, this is one of 
> the bigger visual deficiencies of NetBeans running on Vista – the smaller 
> Tahoma font makes it less visually appealing that it could have been." 
> https://www.pushing-pixels.org/page/213?m
> This PR switches the NetBeans Windows LAF to the newer Segoe font, by 
> borrowing logic from FlatLAF to get the actual Windows default font from the 
> "win.messagebox.font" desktop property, which is initialized from the Win32 
> API. This also avoids one of the problems that were fixed in the earlier 
> https://github.com/apache/netbeans/pull/1777 , with the Swing Windows LAF 
> using incorrect font sizes on certain HiDPI configurations.
> Segoe UI 12 looks similar to Tahoma 11, but with ascenders and descenders 
> that extend one pixel farther up/down. Letters like "j" and "y" have some 
> differences in their shapes.
> Note that certain UI elements, notably the menu bar, were already using Segoe 
> UI 12. And FlatLAF is already using Segoe UI 12 on Windows. Note also that 
> this PR should not affect the main code editor font.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5927) Switch Windows LAF to the now-standard "Segoe UI" font

2021-08-17 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5927:
--
Attachment: fontchange-2-after.png

> Switch Windows LAF to the now-standard "Segoe UI" font
> --
>
> Key: NETBEANS-5927
> URL: https://issues.apache.org/jira/browse/NETBEANS-5927
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Other
>Affects Versions: 12.4
> Environment: NetBeans 12.4 with Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: fontchange-1-before.png, fontchange-2-after.png
>
>
> For the last 14 years (since Windows Vista), the default UI font on Windows 
> has been Segoe UI 12. But Swing's Windows LAF stayed with Tahoma 11, for 
> reasons of backwards compatibility only (see JDK-6669448). This makes 
> NetBeans look a little dated, and the font size smaller than in other Windows 
> application. In the words of one blogger: "On a related note, this is one of 
> the bigger visual deficiencies of NetBeans running on Vista – the smaller 
> Tahoma font makes it less visually appealing that it could have been." 
> https://www.pushing-pixels.org/page/213?m
> This PR switches the NetBeans Windows LAF to the newer Segoe font, by 
> borrowing logic from FlatLAF to get the actual Windows default font from the 
> "win.messagebox.font" desktop property, which is initialized from the Win32 
> API. This also avoids one of the problems that were fixed in the earlier 
> https://github.com/apache/netbeans/pull/1777 , with the Swing Windows LAF 
> using incorrect font sizes on certain HiDPI configurations.
> Segoe UI 12 looks similar to Tahoma 11, but with ascenders and descenders 
> that extend one pixel farther up/down. Letters like "j" and "y" have some 
> differences in their shapes.
> Note that certain UI elements, notably the menu bar, were already using Segoe 
> UI 12. And FlatLAF is already using Segoe UI 12 on Windows. Note also that 
> this PR should not affect the main code editor font.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-5927) Switch Windows LAF to the now-standard "Segoe UI" font

2021-08-17 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-5927:
--
Description: 
For the last 14 years (since Windows Vista), the default UI font on Windows has 
been Segoe UI 12. But Swing's Windows LAF stayed with Tahoma 11, for reasons of 
backwards compatibility only (see JDK-6669448). This makes NetBeans look a 
little dated, and the font size smaller than in other Windows application. In 
the words of one blogger: "On a related note, this is one of the bigger visual 
deficiencies of NetBeans running on Vista – the smaller Tahoma font makes it 
less visually appealing that it could have been." 
https://www.pushing-pixels.org/page/213?m

This PR switches the NetBeans Windows LAF to the newer Segoe font, by borrowing 
logic from FlatLAF to get the actual Windows default font from the 
"win.messagebox.font" desktop property, which is initialized from the Win32 
API. This also avoids one of the problems that were fixed in the earlier 
https://github.com/apache/netbeans/pull/1777 , with the Swing Windows LAF using 
incorrect font sizes on certain HiDPI configurations.

Segoe UI 12 looks similar to Tahoma 11, but with ascenders and descenders that 
extend one pixel farther up/down. Letters like "j" and "y" have some 
differences in their shapes.

Note that certain UI elements, notably the menu bar, were already using Segoe 
UI 12. And FlatLAF is already using Segoe UI 12 on Windows. Note also that this 
PR should not affect the main code editor font.

  was:
For the last 14 years (since Windows Vista), the default UI font on Windows has 
been Segoe UI 12. But Swing's Windows LAF stayed with Tahoma 11, for reasons of 
backwards compatibility only (see JDK-6669448). This makes NetBeans look a 
little dated, and the font size smaller than in other Windows application. In 
the words of one blogger: "On a related note, this is one of the bigger visual 
deficiencies of NetBeans running on Vista – the smaller Tahoma font makes it 
less visually appealing that it could have been." 
https://www.pushing-pixels.org/page/213?m

This PR switches the NetBeans Windows LAF to the newer Segoe font, by borrowing 
logic from FlatLAF to get the actual Windows default font from the 
"win.messagebox.font" desktop property, which is initialized from the Win32 
API. This also avoids one of the problems that were fixed in the earlier 
https://github.com/apache/netbeans/pull/1777 , with the Swing Windows LAF using 
incorrect font sizes on certain HiDPI configurations.

Segoe UI 12 looks similar to Tahoma 11, but with ascenders and descenders that 
extend one pixel farther up/down. Letters like "j" and "y" have some 
differences in their shapes.

Note that certain UI elements, notably the menu bar, were already using Segoe 
UI 12. And FlatLAF is already using Segoe UI 12 on Windows.


> Switch Windows LAF to the now-standard "Segoe UI" font
> --
>
> Key: NETBEANS-5927
> URL: https://issues.apache.org/jira/browse/NETBEANS-5927
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Other
>Affects Versions: 12.4
> Environment: NetBeans 12.4 with Windows LAF on Windows 10.
>Reporter: Eirik Bakke
>Priority: Major
>
> For the last 14 years (since Windows Vista), the default UI font on Windows 
> has been Segoe UI 12. But Swing's Windows LAF stayed with Tahoma 11, for 
> reasons of backwards compatibility only (see JDK-6669448). This makes 
> NetBeans look a little dated, and the font size smaller than in other Windows 
> application. In the words of one blogger: "On a related note, this is one of 
> the bigger visual deficiencies of NetBeans running on Vista – the smaller 
> Tahoma font makes it less visually appealing that it could have been." 
> https://www.pushing-pixels.org/page/213?m
> This PR switches the NetBeans Windows LAF to the newer Segoe font, by 
> borrowing logic from FlatLAF to get the actual Windows default font from the 
> "win.messagebox.font" desktop property, which is initialized from the Win32 
> API. This also avoids one of the problems that were fixed in the earlier 
> https://github.com/apache/netbeans/pull/1777 , with the Swing Windows LAF 
> using incorrect font sizes on certain HiDPI configurations.
> Segoe UI 12 looks similar to Tahoma 11, but with ascenders and descenders 
> that extend one pixel farther up/down. Letters like "j" and "y" have some 
> differences in their shapes.
> Note that certain UI elements, notably the menu bar, were already using Segoe 
> UI 12. And FlatLAF is already using Segoe UI 12 on Windows. Note also that 
> this PR should not affect the main code editor font.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (NETBEANS-5927) Switch Windows LAF to the now-standard "Segoe UI" font

2021-08-17 Thread Eirik Bakke (Jira)

Eirik Bakke created NETBEANS-5927:
-

 Summary: Switch Windows LAF to the now-standard "Segoe UI" font
 Key: NETBEANS-5927
 URL: https://issues.apache.org/jira/browse/NETBEANS-5927
 Project: NetBeans
  Issue Type: Bug
  Components: platform - Other
Affects Versions: 12.4
 Environment: NetBeans 12.4 with Windows LAF on Windows 10.
Reporter: Eirik Bakke


For the last 14 years (since Windows Vista), the default UI font on Windows has 
been Segoe UI 12. But Swing's Windows LAF stayed with Tahoma 11, for reasons of 
backwards compatibility only (see JDK-6669448). This makes NetBeans look a 
little dated, and the font size smaller than in other Windows application. In 
the words of one blogger: "On a related note, this is one of the bigger visual 
deficiencies of NetBeans running on Vista – the smaller Tahoma font makes it 
less visually appealing that it could have been." 
https://www.pushing-pixels.org/page/213?m

This PR switches the NetBeans Windows LAF to the newer Segoe font, by borrowing 
logic from FlatLAF to get the actual Windows default font from the 
"win.messagebox.font" desktop property, which is initialized from the Win32 
API. This also avoids one of the problems that were fixed in the earlier 
https://github.com/apache/netbeans/pull/1777 , with the Swing Windows LAF using 
incorrect font sizes on certain HiDPI configurations.

Segoe UI 12 looks similar to Tahoma 11, but with ascenders and descenders that 
extend one pixel farther up/down. Letters like "j" and "y" have some 
differences in their shapes.

Note that certain UI elements, notably the menu bar, were already using Segoe 
UI 12. And FlatLAF is already using Segoe UI 12 on Windows.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Commented] (NETBEANS-2360) HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux

2021-08-17 Thread Eirik Bakke (Jira)



[ 
https://issues.apache.org/jira/browse/NETBEANS-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400693#comment-17400693
 ] 

Eirik Bakke commented on NETBEANS-2360:
---

I'm about to create a PR for this issue, which also covers anti-aliasing issues 
on KDE. So I adjusted the title of this issue to include the anti-aliasing 
issue, since they should be tested together.

> HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux
> ---
>
> Key: NETBEANS-2360
> URL: https://issues.apache.org/jira/browse/NETBEANS-2360
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 11.0, 12.2
> Environment: Kubuntu 18.03
> Oracle JDK 11.0.2
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, Linux
> Attachments: kubunt.jpg
>
>
> Running NetBeans 11 on Kubuntu 18.03, GUI text size does not seem to take 
> into account the system's default HiDPI scaling. This was reported in a 
> Twitter thread on https://twitter.com/nicktail/status/1114789604337405952 . 
> Note that Window decorations seem to be the correct size.
> Setting the GDK_SCALE environment variable seems to fix the problem, if I 
> understand the originally reporter correctly. This could probably be done 
> easily from the NetBeans launcher script (netbeans/bin). But it wouldn't fix 
> the problem in multi-monitor setups. We should investigate what could be done 
> to make scaling work properly in multi-monitor setups involving one HiDPI 
> screen and one non-HiDPI screen.
> Before merging a patch to the launcher script, it should be tested on a 
> couple of different Linux environments, using both HiDPI and non-HiDPI 
> screens. Note that the UNIX launcher script is also used on MacOS.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[jira] [Updated] (NETBEANS-2360) HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux

2021-08-17 Thread Eirik Bakke (Jira)



 [ 
https://issues.apache.org/jira/browse/NETBEANS-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-2360:
--
Summary: HiDPI scaling (and anti-aliasing on KDE) not applied automatically 
on Linux  (was: HiDPI scaling not applied automatically on Linux)

> HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux
> ---
>
> Key: NETBEANS-2360
> URL: https://issues.apache.org/jira/browse/NETBEANS-2360
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 11.0, 12.2
> Environment: Kubuntu 18.03
> Oracle JDK 11.0.2
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, Linux
> Attachments: kubunt.jpg
>
>
> Running NetBeans 11 on Kubuntu 18.03, GUI text size does not seem to take 
> into account the system's default HiDPI scaling. This was reported in a 
> Twitter thread on https://twitter.com/nicktail/status/1114789604337405952 . 
> Note that Window decorations seem to be the correct size.
> Setting the GDK_SCALE environment variable seems to fix the problem, if I 
> understand the originally reporter correctly. This could probably be done 
> easily from the NetBeans launcher script (netbeans/bin). But it wouldn't fix 
> the problem in multi-monitor setups. We should investigate what could be done 
> to make scaling work properly in multi-monitor setups involving one HiDPI 
> screen and one non-HiDPI screen.
> Before merging a patch to the launcher script, it should be tested on a 
> couple of different Linux environments, using both HiDPI and non-HiDPI 
> screens. Note that the UNIX launcher script is also used on MacOS.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

1 2 3 4 5 6 7 >

1 - 100 of 698 matches

Mail list logo