from:"Eirik Bakke \\\\\\$JIRA\\\\\\$"

[jira] [Closed] (NETBEANS-1238) HiDPI icons in tabcontrol and openide.awt modules for Windows LAF

2018-10-30 Thread Eirik Bakke (JIRA)



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

Eirik Bakke closed NETBEANS-1238.
-
Resolution: Fixed

Closing as the corresponding pull request was reviewed and merged.

> HiDPI icons in tabcontrol and openide.awt modules for Windows LAF
> -
>
> Key: NETBEANS-1238
> URL: https://issues.apache.org/jira/browse/NETBEANS-1238
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: Windows 8.1 and Windows 10 with high-density displays or 
> accessibility scaling
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, pull-request-available
> Fix For: Next
>
> Attachments: NETBEANS-1238 After patch.png, NETBEANS-1238 Before 
> patch.png, VectorIconTester output.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> On Windows 10, each monitor may be configured with an arbitrary scaling 
> factor, such as 125%, 150%, 200%, or even 300%. For instance, high-density 
> laptop displays are typically set to a scaling of 200% by default. On Java 9 
> and 10, Swing handles this "HiDPI" scaling automatically, making the UI take 
> up more pixels without looking smaller, and without any changes in the client 
> application. This makes bitmap icons blurry or ragged, however.
> To look good on HiDPI displays on Windows 10, 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, the 
> "_" button that collapses a sidebar, or the ">>" button that shows hidden 
> toolbar icons. These icons reside in the tabcontrol and openide.awt modules.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1582) HiDPI icons for window system icons on Linux

2018-10-30 Thread Eirik Bakke (JIRA)

Eirik Bakke created NETBEANS-1582:
-

 Summary: HiDPI icons for window system icons on Linux
 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


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, the "_" 
button that collapses a sidebar, or the ">>" button that shows hidden toolbar 
icons. 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).

(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
(v7.6.3#76005)

-
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-1583) Support MultiResolutionImage loading from ImageUtilities

2018-10-30 Thread Eirik Bakke (JIRA)

Eirik Bakke created NETBEANS-1583:
-

 Summary: Support MultiResolutionImage loading from ImageUtilities 
 Key: NETBEANS-1583
 URL: https://issues.apache.org/jira/browse/NETBEANS-1583
 Project: NetBeans
  Issue Type: Improvement
  Components: platform - Other
Affects Versions: 10.0
 Environment: Windows, Linux, and MacOS
Reporter: Eirik Bakke


To look good on HiDPI/Retina displays, the NetBeans IDE and NetBeans Platform 
applications will eventually need to provide high-resolution versions of 
various image asset (typically icons). In Swing, multi-resolution image assets 
are supported via the MultiResolutionImage class; such images are automatically 
loaded by methods such as Toolkit.getImage based on a standard naming 
convention. For instance, on MacOS, Toolkit.getImage("myicon.png") will also 
load the file "myi...@2x.png" if present, returning a MultiResolutionImage (see 
[https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as 
in the JDK. See Philip Race's comment on 
[https://bugs.openjdk.java.net/browse/JDK-8151787] :

{quote}The proposed name convention for splash screens *and* other multi-res 
images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
and also because we already supported @2x on retina Mac.
{quote}
 
(On the naming convention, see also 
https://bugs.openjdk.java.net/browse/JDK-8090575 )

As far as I know, only MacOS currently supports the automatic loading of such 
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
the underlying MultiResolutionImage. So it's already possible to implement this 
on the latest JDK. Note, however, that we should probably wait for 
https://bugs.openjdk.java.net/browse/JDK-8212226 to be fixed before enabling 
this on Windows.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1583) Support MultiResolutionImage loading from ImageUtilities

2018-10-30 Thread Eirik Bakke (JIRA)

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

Eirik Bakke updated NETBEANS-1583:
--
Description:
To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans Platform
(RCP) applications, will eventually need to provide high-resolution versions of
various image asset (typically icons). In Swing, multi-resolution image assets
are supported via the
[MultiResolutionImage|https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html]
class; such images are automatically loaded by methods such as
Toolkit.getImage based on a standard naming convention. For instance, on MacOS,
Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" if
present, returning a MultiResolutionImage (implemented in
[JDK-8011059|https://bugs.openjdk.java.net/browse/JDK-8011059]). NetBeans'
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as
in the JDK. See Philip Race's comment on
[JDK-8151787|https://bugs.openjdk.java.net/browse/JDK-8151787] :

{quote}The proposed name convention for splash screens *and* other multi-res
images is @125pct @150pct @200pct @2x @250pct @300pct @3x
ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively
and also because we already supported @2x on retina Mac.
{quote}
On the naming convention, see also
[JDK-8090575|https://bugs.openjdk.java.net/browse/JDK-8090575]. Also make sure
to retain the ability to add a "_dark" suffix for dark LAFs.

As far as I know, only MacOS currently supports the automatic loading of such
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support
the underlying MultiResolutionImage class. So it's already possible to
implement this on the latest JDK. Note, however, that we should probably wait
for [JDK-8212226|https://bugs.openjdk.java.net/browse/JDK-8212226] to be fixed
before enabling this on Windows.

As part of this patch, other ImageUtilities methods such as createDisabledIcon,
createDisabledImage, and mergeImages should also be updated to support both
MultiResolutionImage and the new org.openide.util.VectorIcon class (introduced
at https://github.com/apache/incubator-netbeans/pull/859/files ). Emilian Bold
has done some work on this in the past; see
https://github.com/emilianbold/nextbeans/commit/0f99dba0c1b3e8e0bc4e7cec407b53d30e85ead1
. Eirik Bakke also has some working code for createDisabledIcon in particular,
which works with the VectorIcon class and any other Icon instance.

was:
To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans Platform
(RCP) applications, will eventually need to provide high-resolution versions of
various image asset (typically icons). In Swing, multi-resolution image assets
are supported via the
[MultiResolutionImage|https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html]
class; such images are automatically loaded by methods such as
Toolkit.getImage based on a standard naming convention. For instance, on MacOS,
Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" if
present, returning a MultiResolutionImage (implemented in
[JDK-8011059|https://bugs.openjdk.java.net/browse/JDK-8011059]). NetBeans'
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as
in the JDK. See Philip Race's comment on
[JDK-8151787|https://bugs.openjdk.java.net/browse/JDK-8151787] :

As part of

[jira] [Updated] (NETBEANS-1583) Support MultiResolutionImage loading from ImageUtilities

2018-10-30 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1583:
--
Description: 
To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans Platform 
(RCP), applications will eventually need to provide high-resolution versions of 
various image asset (typically icons). In Swing, multi-resolution image assets 
are supported via the 
[MultiResolutionImage|https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html]
 class; such images are automatically loaded by methods such as 
Toolkit.getImage based on a standard naming convention. For instance, on MacOS, 
Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" if 
present, returning a MultiResolutionImage (see 
[https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as 
in the JDK. See Philip Race's comment on 
[https://bugs.openjdk.java.net/browse/JDK-8151787] :

{quote}The proposed name convention for splash screens *and* other multi-res 
images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
and also because we already supported @2x on retina Mac.
{quote}
 
(On the naming convention, see also 
https://bugs.openjdk.java.net/browse/JDK-8090575 )

As far as I know, only MacOS currently supports the automatic loading of such 
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
the underlying MultiResolutionImage. So it's already possible to implement this 
on the latest JDK. Note, however, that we should probably wait for 
https://bugs.openjdk.java.net/browse/JDK-8212226 to be fixed before enabling 
this on Windows.

  was:
To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans Platform 
(RCP), applications will eventually need to provide high-resolution versions of 
various image asset (typically icons). In Swing, multi-resolution image assets 
are supported via the 
[MultiResolutionImage|https://docs.oracle.com/javase/9/docs/api/java/awt/image/MultiResolutionImage.html]
 class; such images are automatically loaded by methods such as 
Toolkit.getImage based on a standard naming convention. For instance, on MacOS, 
Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" if 
present, returning a MultiResolutionImage (see 
[https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as 
in the JDK. See Philip Race's comment on 
[https://bugs.openjdk.java.net/browse/JDK-8151787] :

{quote}The proposed name convention for splash screens *and* other multi-res 
images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
and also because we already supported @2x on retina Mac.
{quote}
 
(On the naming convention, see also 
https://bugs.openjdk.java.net/browse/JDK-8090575 )

As far as I know, only MacOS currently supports the automatic loading of such 
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
the underlying MultiResolutionImage. So it's already possible to implement this 
on the latest JDK. Note, however, that we should probably wait for 
https://bugs.openjdk.java.net/browse/JDK-8212226 to be fixed before enabling 
this on Windows.


> Support MultiResolutionImage loading from ImageUtilities 
> -
>
> Key: NETBEANS-1583
> URL: https://issues.apache.org/jira/browse/NETBEANS-1583
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 10.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
>
> To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans 
> Platform (RCP), applications will eventually need to provide high-resolution 
> versions of various image asset (typically icons). In Swing, multi-resolution 
> image assets are supported via the 
> [MultiResolutionImage|https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html]
>  class; such images are automatically loaded by methods such as 
> Toolkit.getImage based on a standard naming convention. For instance, on 
> MacOS, Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" 
> if present, returning a MultiResolutionImage (see 
> [https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
> ImageUtilities.loadImage and friends should do the same.
> The same naming convention for

[jira] [Updated] (NETBEANS-1583) Support MultiResolutionImage loading from ImageUtilities

2018-10-30 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1583:
--
Description: 
To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans Platform 
(RCP), applications will eventually need to provide high-resolution versions of 
various image asset (typically icons). In Swing, multi-resolution image assets 
are supported via the 
[MultiResolutionImage|https://docs.oracle.com/javase/9/docs/api/java/awt/image/MultiResolutionImage.html]
 class; such images are automatically loaded by methods such as 
Toolkit.getImage based on a standard naming convention. For instance, on MacOS, 
Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" if 
present, returning a MultiResolutionImage (see 
[https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as 
in the JDK. See Philip Race's comment on 
[https://bugs.openjdk.java.net/browse/JDK-8151787] :

{quote}The proposed name convention for splash screens *and* other multi-res 
images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
and also because we already supported @2x on retina Mac.
{quote}
 
(On the naming convention, see also 
https://bugs.openjdk.java.net/browse/JDK-8090575 )

As far as I know, only MacOS currently supports the automatic loading of such 
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
the underlying MultiResolutionImage. So it's already possible to implement this 
on the latest JDK. Note, however, that we should probably wait for 
https://bugs.openjdk.java.net/browse/JDK-8212226 to be fixed before enabling 
this on Windows.

  was:
To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans Platform 
(RCP), applications will eventually need to provide high-resolution versions of 
various image asset (typically icons). In Swing, multi-resolution image assets 
are supported via the MultiResolutionImage class; such images are automatically 
loaded by methods such as Toolkit.getImage based on a standard naming 
convention. For instance, on MacOS, Toolkit.getImage("myicon.png") will also 
load the file "myi...@2x.png" if present, returning a MultiResolutionImage (see 
[https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as 
in the JDK. See Philip Race's comment on 
[https://bugs.openjdk.java.net/browse/JDK-8151787] :

{quote}The proposed name convention for splash screens *and* other multi-res 
images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
and also because we already supported @2x on retina Mac.
{quote}
 
(On the naming convention, see also 
https://bugs.openjdk.java.net/browse/JDK-8090575 )

As far as I know, only MacOS currently supports the automatic loading of such 
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
the underlying MultiResolutionImage. So it's already possible to implement this 
on the latest JDK. Note, however, that we should probably wait for 
https://bugs.openjdk.java.net/browse/JDK-8212226 to be fixed before enabling 
this on Windows.


> Support MultiResolutionImage loading from ImageUtilities 
> -
>
> Key: NETBEANS-1583
> URL: https://issues.apache.org/jira/browse/NETBEANS-1583
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 10.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
>
> To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans 
> Platform (RCP), applications will eventually need to provide high-resolution 
> versions of various image asset (typically icons). In Swing, multi-resolution 
> image assets are supported via the 
> [MultiResolutionImage|https://docs.oracle.com/javase/9/docs/api/java/awt/image/MultiResolutionImage.html]
>  class; such images are automatically loaded by methods such as 
> Toolkit.getImage based on a standard naming convention. For instance, on 
> MacOS, Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" 
> if present, returning a MultiResolutionImage (see 
> [https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
> ImageUtilities.loadImage and friends should do the same.
> The same naming convention for multi-resolution image assets should be used 
> as in the JDK. See Philip Race's comment on 
>

[jira] [Updated] (NETBEANS-1583) Support MultiResolutionImage loading from ImageUtilities

2018-10-30 Thread Eirik Bakke (JIRA)

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

The same naming convention for multi-resolution image assets should be used as
in the JDK. See Philip Race's comment on
[JDK-8151787|https://bugs.openjdk.java.net/browse/JDK-8151787] :

As part of this patch, other

[jira] [Updated] (NETBEANS-1583) Support MultiResolutionImage loading from ImageUtilities

2018-10-30 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1583:
--
Description: 
To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans Platform 
(RCP), applications will eventually need to provide high-resolution versions of 
various image asset (typically icons). In Swing, multi-resolution image assets 
are supported via the MultiResolutionImage class; such images are automatically 
loaded by methods such as Toolkit.getImage based on a standard naming 
convention. For instance, on MacOS, Toolkit.getImage("myicon.png") will also 
load the file "myi...@2x.png" if present, returning a MultiResolutionImage (see 
[https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as 
in the JDK. See Philip Race's comment on 
[https://bugs.openjdk.java.net/browse/JDK-8151787] :

{quote}The proposed name convention for splash screens *and* other multi-res 
images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
and also because we already supported @2x on retina Mac.
{quote}
 
(On the naming convention, see also 
https://bugs.openjdk.java.net/browse/JDK-8090575 )

As far as I know, only MacOS currently supports the automatic loading of such 
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
the underlying MultiResolutionImage. So it's already possible to implement this 
on the latest JDK. Note, however, that we should probably wait for 
https://bugs.openjdk.java.net/browse/JDK-8212226 to be fixed before enabling 
this on Windows.

  was:
To look good on HiDPI/Retina displays, the NetBeans IDE and NetBeans Platform 
applications will eventually need to provide high-resolution versions of 
various image asset (typically icons). In Swing, multi-resolution image assets 
are supported via the MultiResolutionImage class; such images are automatically 
loaded by methods such as Toolkit.getImage based on a standard naming 
convention. For instance, on MacOS, Toolkit.getImage("myicon.png") will also 
load the file "myi...@2x.png" if present, returning a MultiResolutionImage (see 
[https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as 
in the JDK. See Philip Race's comment on 
[https://bugs.openjdk.java.net/browse/JDK-8151787] :

{quote}The proposed name convention for splash screens *and* other multi-res 
images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
and also because we already supported @2x on retina Mac.
{quote}
 
(On the naming convention, see also 
https://bugs.openjdk.java.net/browse/JDK-8090575 )

As far as I know, only MacOS currently supports the automatic loading of such 
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
the underlying MultiResolutionImage. So it's already possible to implement this 
on the latest JDK. Note, however, that we should probably wait for 
https://bugs.openjdk.java.net/browse/JDK-8212226 to be fixed before enabling 
this on Windows.


> Support MultiResolutionImage loading from ImageUtilities 
> -
>
> Key: NETBEANS-1583
> URL: https://issues.apache.org/jira/browse/NETBEANS-1583
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 10.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
>
> To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans 
> Platform (RCP), applications will eventually need to provide high-resolution 
> versions of various image asset (typically icons). In Swing, multi-resolution 
> image assets are supported via the MultiResolutionImage class; such images 
> are automatically loaded by methods such as Toolkit.getImage based on a 
> standard naming convention. For instance, on MacOS, 
> Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" if 
> present, returning a MultiResolutionImage (see 
> [https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
> ImageUtilities.loadImage and friends should do the same.
> The same naming convention for multi-resolution image assets should be used 
> as in the JDK. See Philip Race's comment on 
> [https://bugs.openjdk.java.net/browse/JDK-8151787] :
> {quote}The proposed name convention for splash screens *and* other multi-res 
> images is @125pct @150pct @200pct @2x @250pct @300pct @3x

[jira] [Updated] (NETBEANS-1583) Support MultiResolutionImage loading from ImageUtilities

2018-10-30 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1583:
--
Description: 
To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans Platform 
(RCP) applications, will eventually need to provide high-resolution versions of 
various image asset (typically icons). In Swing, multi-resolution image assets 
are supported via the 
[MultiResolutionImage|https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html]
 class; such images are automatically loaded by methods such as 
Toolkit.getImage based on a standard naming convention. For instance, on MacOS, 
Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" if 
present, returning a MultiResolutionImage (see 
[https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as 
in the JDK. See Philip Race's comment on 
[https://bugs.openjdk.java.net/browse/JDK-8151787] :

{quote}The proposed name convention for splash screens *and* other multi-res 
images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
and also because we already supported @2x on retina Mac.
{quote}
 
(On the naming convention, see also 
https://bugs.openjdk.java.net/browse/JDK-8090575 )

As far as I know, only MacOS currently supports the automatic loading of such 
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
the underlying MultiResolutionImage. So it's already possible to implement this 
on the latest JDK. Note, however, that we should probably wait for 
https://bugs.openjdk.java.net/browse/JDK-8212226 to be fixed before enabling 
this on Windows.

  was:
To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans Platform 
(RCP), applications will eventually need to provide high-resolution versions of 
various image asset (typically icons). In Swing, multi-resolution image assets 
are supported via the 
[MultiResolutionImage|https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html]
 class; such images are automatically loaded by methods such as 
Toolkit.getImage based on a standard naming convention. For instance, on MacOS, 
Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" if 
present, returning a MultiResolutionImage (see 
[https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as 
in the JDK. See Philip Race's comment on 
[https://bugs.openjdk.java.net/browse/JDK-8151787] :

{quote}The proposed name convention for splash screens *and* other multi-res 
images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
and also because we already supported @2x on retina Mac.
{quote}
 
(On the naming convention, see also 
https://bugs.openjdk.java.net/browse/JDK-8090575 )

As far as I know, only MacOS currently supports the automatic loading of such 
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
the underlying MultiResolutionImage. So it's already possible to implement this 
on the latest JDK. Note, however, that we should probably wait for 
https://bugs.openjdk.java.net/browse/JDK-8212226 to be fixed before enabling 
this on Windows.


> Support MultiResolutionImage loading from ImageUtilities 
> -
>
> Key: NETBEANS-1583
> URL: https://issues.apache.org/jira/browse/NETBEANS-1583
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 10.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
>
> To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans 
> Platform (RCP) applications, will eventually need to provide high-resolution 
> versions of various image asset (typically icons). In Swing, multi-resolution 
> image assets are supported via the 
> [MultiResolutionImage|https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html]
>  class; such images are automatically loaded by methods such as 
> Toolkit.getImage based on a standard naming convention. For instance, on 
> MacOS, Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" 
> if present, returning a MultiResolutionImage (see 
> [https://bugs.openjdk.java.net/browse/JDK-8011059] ). NetBeans' 
> ImageUtilities.loadImage and friends should do the same.
> The same naming convention for

[jira] [Updated] (NETBEANS-1583) Support MultiResolutionImage loading from ImageUtilities

2018-10-30 Thread Eirik Bakke (JIRA)

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

The same naming convention for multi-resolution image assets should be used as
in the JDK. See Philip Race's comment on
[JDK-8151787|https://bugs.openjdk.java.net/browse/JDK-8151787] :

[jira] [Updated] (NETBEANS-1583) Support MultiResolutionImage loading from ImageUtilities

2018-10-30 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1583:
--
Description: 
To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans Platform 
(RCP) applications, will eventually need to provide high-resolution versions of 
various image asset (typically icons). In Swing, multi-resolution image assets 
are supported via the 
[MultiResolutionImage|https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html]
 class; such images are automatically loaded by methods such as 
Toolkit.getImage based on a standard naming convention. For instance, on MacOS, 
Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" if 
present, returning a MultiResolutionImage (implemented in 
[JDK-8011059|https://bugs.openjdk.java.net/browse/JDK-8011059]). NetBeans' 
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as 
in the JDK. See Philip Race's comment on 
[JDK-8151787|https://bugs.openjdk.java.net/browse/JDK-8151787] :

{quote}The proposed name convention for splash screens *and* other multi-res 
images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
and also because we already supported @2x on retina Mac.
{quote}
 
On the naming convention, see also 
[JDK-8090575|https://bugs.openjdk.java.net/browse/JDK-8090575]. Also make sure 
to retain the ability to add a "_dark" suffix for dark LAFs.

As far as I know, only MacOS currently supports the automatic loading of such 
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
the underlying MultiResolutionImage class. So it's already possible to 
implement this on the latest JDK. Note, however, that we should probably wait 
for [JDK-8212226|https://bugs.openjdk.java.net/browse/JDK-8212226] to be fixed 
before enabling this on Windows.

As part of this patch, other ImageUtilities methods such as createDisabledIcon, 
createDisabledImage, and mergeImages should also be updated to support both 
MultiResolutionImage and the new org.openide.util.VectorIcon class (introduced 
at https://github.com/apache/incubator-netbeans/pull/859/files ). Emilian Bold 
has done some work on this in the past; see 
https://github.com/emilianbold/nextbeans/commit/0f99dba0c1b3e8e0bc4e7cec407b53d30e85ead1
 .



  was:
To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans Platform 
(RCP) applications, will eventually need to provide high-resolution versions of 
various image asset (typically icons). In Swing, multi-resolution image assets 
are supported via the 
[MultiResolutionImage|https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html]
 class; such images are automatically loaded by methods such as 
Toolkit.getImage based on a standard naming convention. For instance, on MacOS, 
Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" if 
present, returning a MultiResolutionImage (implemented in 
[JDK-8011059|https://bugs.openjdk.java.net/browse/JDK-8011059]). NetBeans' 
ImageUtilities.loadImage and friends should do the same.

The same naming convention for multi-resolution image assets should be used as 
in the JDK. See Philip Race's comment on 
[JDK-8151787|https://bugs.openjdk.java.net/browse/JDK-8151787] :

{quote}The proposed name convention for splash screens *and* other multi-res 
images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
and also because we already supported @2x on retina Mac.
{quote}
 
(On the naming convention, see also 
[JDK-8090575|https://bugs.openjdk.java.net/browse/JDK-8090575])

As far as I know, only MacOS currently supports the automatic loading of such 
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
the underlying MultiResolutionImage class. So it's already possible to 
implement this on the latest JDK. Note, however, that we should probably wait 
for [JDK-8212226|https://bugs.openjdk.java.net/browse/JDK-8212226] to be fixed 
before enabling this on Windows.


> Support MultiResolutionImage loading from ImageUtilities 
> -
>
> Key: NETBEANS-1583
> URL: https://issues.apache.org/jira/browse/NETBEANS-1583
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 10.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
>
> To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans 
> Platform (RCP) applications, will eventually need to provide high-resolution 
> versions

[jira] [Commented] (NETBEANS-1227) Mark Windows launcher binary as per-monitor DPI aware

2018-10-27 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-1227:
---

This fix might affect the way Windows decides on DPI settings for applications 
run from the IDE as well, yes. I'm not sure exactly how the IDE launches 
applications under development when you hit "run", but I suspect it depends on 
whether you are running an ant or maven project, and on whether you are running 
a NetBeans IDE under development or a regular Java application.

When you run the Dev IDE, you're probably running it on Java 8 (since it's 
usually built on Java 8 as well). Java 8 has no HiDPI support, so everything 
becomes tiny or blurry (tiny in this case probably because Windows assumes 
NetBeans and all its child processes, or perhaps launcher binaries, support 
HiDPI).

You could (1) run the Dev IDE on Java 9 or above (2) use the old trick to 
override DPI settings for all of NetBeans (see if you can find a setting that 
works) or (3) try to find whatever launcher EXE file is being used to actually 
launch the dev IDE (nbexec64.exe? or perhaps netbeans64.exe in the 
nbbuild\netbeans\bin directory?), and override DPI settings for that EXE file 
specifically (right-click, Properties etc.).

> Mark Windows launcher binary as per-monitor DPI aware
> -
>
> Key: NETBEANS-1227
> URL: https://issues.apache.org/jira/browse/NETBEANS-1227
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 9.0
> Environment: Windows 8.1 and Windows 10
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, pull-request-available
> Fix For: 10.0
>
> Attachments: SmallIconsRun.png
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> As of Java 10.0.2, support for HiDPI monitors on Windows is quite good. All 
> the standard Swing components appear in high resolution, and Graphics2D 
> surfaces are automatically scaled appropriately for whichever monitor their 
> containing window is located on, including when windows are dragged between 
> monitors in a mixed-DPI multi-monitor setting.
> For this to work, however, the EXE file that launches NetBeans must contain a 
> manifest that declares the application to be DPI-aware. Such a manifest 
> currently exists in java.exe and javaw.exe, but not in the custom 
> netbeans64.exe launcher. A workaround for the missing manifest is to right 
> click the "bin\netbeans64.exe" file, or whichever shortcut is being used to 
> open NetBeans, go to the "Compatibility" tab, click "Change high DPI 
> settings", "Override high DPI scaling behavior", and select scaling performed 
> by "Application".
> An appropriate manifest should be added to netbeans64.exe to declare NetBeans 
> as per-monitor DPI aware.
> To see how the manifest should be declared, we can dump the manifest of 
> javaw.exe:
>  {code:xml}
> 
>  xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
>   processorArchitecture="X86" type="win32"/>
>  Java(TM) SE process
>  
>  
>   xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings;>
>  true/PM
>  
>  
>  
> 
> {code}
> This reveals that Java 10.0.2 considers itself DPI-aware at the "Per Monitor 
> V1" level (see the Microsoft documentation linked below). The NetBeans 
> launcher binary should declare the same.
> References:
> [https://docs.microsoft.com/en-us/windows/desktop/hidpi/high-dpi-desktop-application-development-on-windows]
> [https://msdn.microsoft.com/en-us/library/windows/desktop/mt846517(v=vs.85).aspx]
> [https://docs.microsoft.com/en-us/windows/desktop/sbscs/application-manifests]
> [https://blogs.msdn.microsoft.com/mithuns/2009/12/16/random-how-to-quickly-view-a-binarys-embedded-manifest]
> [https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1428) Fatal error when profiling

2018-11-09 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-1428:
---

I've observed this profiler crash on Windows 10 as well. In my case I was using 
"Attach to External Process" in a Maven-based project. The crash occurs 
consistently on Java 9.0.7.1, Java 10.0.2, and Java 12-ea, but did _not_ occur 
on Java 8.0.181.

> Fatal error when profiling
> --
>
> Key: NETBEANS-1428
> URL: https://issues.apache.org/jira/browse/NETBEANS-1428
> Project: NetBeans
>  Issue Type: Bug
>  Components: profiler - Base
>Affects Versions: 9.0, 10.0
> Environment: Windows 10, JDK11 (OpenJDK 11.0+28)
>Reporter: Peter Hull
>Priority: Major
>  Labels: netcat
> Attachments: hs_err_pid38528.log
>
>
> Attempting to profile a Java freeform project (Netcat 10, Profiling FreeForm, 
> Step 2)
> I get the following error
> {{#}}
> {{# A fatal error has been detected by the Java Runtime Environment:}}
> {{#}}
> {{#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7ff8e831c775, 
> pid=38528, tid=38596}}
> {{#}}
> {{# JRE version: OpenJDK Runtime Environment (11.0+28) (build 11+28)}}
> {{# Java VM: OpenJDK 64-Bit Server VM (11+28, mixed mode, tiered, compressed 
> oops, g1 gc, windows-amd64)}}
> {{# Problematic frame:}}
> {{# V  [jvm.dll+0x5ec775]}}
> {{#}}
> {{# No core dump will be written. Minidumps are not enabled by default on 
> client versions of Windows}}
> {{#}}
> {{# An error report file with more information is saved as:}}
> {{# D:\Libraries\Downloads\TS_Profiler_freeform\freeform\hs_err_pid38528.log}}
> {{#}}
> {{# If you would like to submit a bug report, please visit:}}
> {{#   http://bugreport.java.com/bugreport/crash.jsp}}
> {{#}}
> Seems reproducible, I have attached the crash log.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1582) HiDPI icons for window system icons on default Linux LAF

2018-11-13 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-1582:
---

Beware of discussions to change the default LAF on Linux: 
https://issues.apache.org/jira/browse/NETBEANS-1344 . (This issue relates to 
whichever LAF is the default on Linux.)

> 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
(v7.6.3#76005)

-
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-49) Please add smooth scrolling

2018-11-15 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-49:
-

If I ever go by a Microsoft Store I could try to see if I find a Surface Book 
to try on...

> Please add smooth scrolling 
> 
>
> Key: NETBEANS-49
> URL: https://issues.apache.org/jira/browse/NETBEANS-49
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Window System
>Reporter: Christian Lenz
>Priority: Major
>  Labels: pull-request-available
> Fix For: 10.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Inside the editor, when I scroll with my touchpad to the bottom, it jumps 9 
> lines to the next, this is a lot. I don't like such gappings I would like to 
> have a smooth stepless scrolling, like in chrome or other windows native 
> apps. Please add this for horizontal and vertical scrolling, it will be much 
> better. Not only in editors, it should be available everywhere, where we have 
> scrollbars.
> Regards
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-49) Please add smooth scrolling

2018-11-15 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-49:
-

For the default LaF, Is scrolling behavior still strictly better after the 
patch, or did it get worse? In other words, is there a chance we might need to 
revert the original patch, or should we keep it there for now?

> Please add smooth scrolling 
> 
>
> Key: NETBEANS-49
> URL: https://issues.apache.org/jira/browse/NETBEANS-49
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Window System
>Reporter: Christian Lenz
>Priority: Major
>  Labels: pull-request-available
> Fix For: 10.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Inside the editor, when I scroll with my touchpad to the bottom, it jumps 9 
> lines to the next, this is a lot. I don't like such gappings I would like to 
> have a smooth stepless scrolling, like in chrome or other windows native 
> apps. Please add this for horizontal and vertical scrolling, it will be much 
> better. Not only in editors, it should be available everywhere, where we have 
> scrollbars.
> Regards
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-49) Please add smooth scrolling

2018-11-14 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-49:
-

Yes, the smooth scrolling patch was intentionally specific to the Windows LAF 
only, since it's not needed on MacOS, and since it was the only LAF I had a 
chance to test it on. We can enable it on other LAFs too if desired, though it 
might involve either copying some code over to Darcula or doing some ugly 
reflection hacks that I was trying to avoid.

Now if I remember correctly, even with the new patch, you mentioned (on the 
mailing list) that you saw some scroll problems in the editor on your 
particular computer. Is that still the case? Did the patch make scrolling 
better or worse overall on that computer? It might be good to fix these 
problems first.

> Please add smooth scrolling 
> 
>
> Key: NETBEANS-49
> URL: https://issues.apache.org/jira/browse/NETBEANS-49
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Window System
>Reporter: Christian Lenz
>Priority: Major
>  Labels: pull-request-available
> Fix For: 10.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Inside the editor, when I scroll with my touchpad to the bottom, it jumps 9 
> lines to the next, this is a lot. I don't like such gappings I would like to 
> have a smooth stepless scrolling, like in chrome or other windows native 
> apps. Please add this for horizontal and vertical scrolling, it will be much 
> better. Not only in editors, it should be available everywhere, where we have 
> scrollbars.
> Regards
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1145) Automate build of Windows Launchers

2018-10-04 Thread Eirik Bakke (JIRA)



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

Eirik Bakke edited comment on NETBEANS-1145 at 10/4/18 10:14 PM:
-

My notes from building the Windows launchers, in case it is of any help:
 * The windows EXE files can be built on Linux. No Windows machine is necessary 
except for testing purposes.
 * The windows EXE files can also be built on WSL, i.e. Windows Subsystem for 
Linux. (Cue theme music from the movie "Inception".)
 * On Windows WSL Ubuntu, I used "sudo apt-get install gcc g++ cmake gdb 
qt4-qmake g++-mingw-w64-x86-64 g++-mingw mingw-w64 openjdk-8-jdk" to get all 
the relevant packages installed. I assume it would be something similar on 
regular Ubuntu.
 * The launchers are in the following directories:
 harness/apisupport.harness/windows-launcher-src
 platform/o.n.bootstrap/launcher/windows
 nb/ide.launcher/windows
 * For each of the above directories, do "make -f Makefile.mingw". That should 
build the EXE file in each case.


was (Author: ebakke):
My notes from building the Windows launchers, in case it is of any help:
 * The windows EXE files can be built on Linux. No Windows machine is necessary 
except for testing purposes.
 * The windows EXE files can also be built on WSL, i.e. Windows Subsystem for 
Linux. (Cue theme music from the movie "Inception".)
 * On Windows WSL Ubuntu, I used "sudo apt-get install gcc g++ cmake gdb 
qt4-qmake g++-mingw-w64-x86-64 g++-mingw mingw-w64 openjdk-8-jdk" to get all 
the relevant packages installed. I assume it would be something similar on 
regular Ubuntu.
 * The launchers are in the following directories:
 harness/apisupport.harness/windows-launcher-src
 platform/o.n.bootstrap/launcher/windows
 nb/ide.launcher/windows
 * For each of the above directories, do "make -f Makefile.mingw". That should 
build the EXE file.

> Automate build of Windows Launchers
> ---
>
> Key: NETBEANS-1145
> URL: https://issues.apache.org/jira/browse/NETBEANS-1145
> Project: NetBeans
>  Issue Type: Improvement
>  Components: apisupport - Harness, platform - LaunchersCLI
>Reporter: Svatopluk Dedic
>Priority: Minor
>
> See comments in 
> [https://github.com/apache/incubator-netbeans/pull/573#pullrequestreview-147108327]
>  :
> The envisioned build process should monitor:
>  * apisupport.harness/lwindows-launcher-src
>  * ide/launcher/windows
>  * o.n.bootstrap/launcher/windows
> and rebuild netbeans or application launchers. I am not so sure about 
> automatic upload to the extbin, the number of artifact from automated builds 
> could reach quite high.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1145) Automate build of Windows Launchers

2018-10-04 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-1145:
---

My notes from building the Windows launchers, in case it is of any help:
 * The windows EXE files can be built on Linux. No Windows machine is necessary 
except for testing purposes.
 * The windows EXE files can also be built on WSL, i.e. Windows Subsystem for 
Linux. (Cue theme music from the movie "Inception".)
 * On Windows WSL Ubuntu, I used "sudo apt-get install gcc g++ cmake gdb 
qt4-qmake g++-mingw-w64-x86-64 g++-mingw mingw-w64 openjdk-8-jdk" to get all 
the relevant packages installed. I assume it would be something similar on 
regular Ubuntu.
 * The launchers are in the following directories:
 harness/apisupport.harness/windows-launcher-src
 platform/o.n.bootstrap/launcher/windows
 nb/ide.launcher/windows
 * For each of the above directories, do "make -f Makefile.mingw". That should 
build the EXE file.

> Automate build of Windows Launchers
> ---
>
> Key: NETBEANS-1145
> URL: https://issues.apache.org/jira/browse/NETBEANS-1145
> Project: NetBeans
>  Issue Type: Improvement
>  Components: apisupport - Harness, platform - LaunchersCLI
>Reporter: Svatopluk Dedic
>Priority: Minor
>
> See comments in 
> [https://github.com/apache/incubator-netbeans/pull/573#pullrequestreview-147108327]
>  :
> The envisioned build process should monitor:
>  * apisupport.harness/lwindows-launcher-src
>  * ide/launcher/windows
>  * o.n.bootstrap/launcher/windows
> and rebuild netbeans or application launchers. I am not so sure about 
> automatic upload to the extbin, the number of artifact from automated builds 
> could reach quite high.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-980) Home/end/up/down do not work properly when word wrapping is enabled

2018-09-30 Thread Eirik Bakke (JIRA)



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

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

Closing as pull request was merged.

> Home/end/up/down do not work properly when word wrapping is enabled
> ---
>
> Key: NETBEANS-980
> URL: https://issues.apache.org/jira/browse/NETBEANS-980
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Other, editor - Painting  Printing
>Affects Versions: 9.0
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Caret movements via Home/End and arrow Up/Down keys do not work properly when 
> text wrap (especially in "after words" mode) is enabled in the NetBeans 
> editor.
> Specific bugs:
> 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
> beginning of the paragraph rather than to the beginning of the current wrap 
> line (physical line).
> 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
> beginning of the next wrap line instead of to the end of the current wrap 
> line.
> 3) Pressing Up has no effect if the preceding wrap line ended before the 
> caret's current X position.
> 4) Pressing Down will move the caret down _two_ lines if the following wrap 
> line ended before the caret's current X position (and assuming the wrap line 
> two lines down is long enough).
> 5) Left-clicking the mouse to the right of the end of a wrap line puts the 
> caret on the beginning of the next wrap line rather than at the end of the 
> current (clicked) wrap line.
> The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
> (UpAction/DownAction/BeginLineAction/EndLineAction).
> Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and 
> is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to 
> move the caret before lineStartPos.)
> Bugs 2-5 above all relate to what caret position is mapped to the "infinite" 
> horizontal space that follows each wrap line. With NetBeans' current 
> behavior, this space corresponds to a caret position directly following the 
> last character of a wrap line. This caret position, however, is physically 
> mapped (and painted) on the beginning of the following wrap line, which 
> confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 
> is fixed, then bugs 2-4 might "fix themselves" as well.
> For bug 5, I think the best solution when clicking the space beyond the end 
> of a wrap line would be to move the caret to right _before_ the last 
> character on the wrap line. This character is usually a space (in word wrap 
> mode), though it could also be a hyphen or such if a more advanced word 
> wrapping algorithm is used (proposed in the pull request for NETBEANS-977). 
> The resulting behavior would be similar to that of a default JTextArea, or 
> jEdit (though these never break words on anything else than a space). Another 
> solution would be to do like the TextEdit app on MacOS, where the cursor is 
> placed _after_ the last character on the wrap line, like NetBeans currently 
> does, but with a backwards bias such that the cursor is painted on the end of 
> the current wrap line instead of on the beginning of the next wrap line. The 
> latter is probably harder to implement, and is not really necessary.
> To test the above bugs:
> 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
> set "Line Wrap" to "After words". Click OK.
> 2) Create a new plain text file and paste in the paragraph "SHORTWORD 
> LONGWORD SHORTWORD LUUUNGWORD".
> 3) Resize the editor window so that the paragraph gets split into four wrap 
> lines (one word on each wrap line--i.e. make the editor a little wider than 
> the long word).
> 4) For each bugs 1-4 listed above, position the caret right after 
> "...ONG", then press the relevant key to test.
> 5) To test bug 5 above, click the mouse to the right of the first, second, or 
> third wrap line.
> Tested in NetBeans 9.0 rc1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1308) Windows launcher fails to suppress console

2018-09-30 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1308:
--
Labels:   (was: Platform)

> Windows launcher fails to suppress console
> --
>
> Key: NETBEANS-1308
> URL: https://issues.apache.org/jira/browse/NETBEANS-1308
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: Next
> Environment: Windows 10
>Reporter: Eirik Bakke
>Priority: Critical
>
> The latest version of the Windows launcher (netbeans64.exe), on the master 
> branch per September 16, opens a new console window every time NetBeans is 
> launched from a shortcut or by double-clicking on the executable in Explorer. 
> The console was suppressed in earlier versions.
> I think this applied to the platform application launcher as well (app64.exe) 
> when I tested two weeks ago.
> This bug was present before the unrelated changes in NETBEANS-1227 ( 
> https://github.com/apache/incubator-netbeans/pull/573 ).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1308) Windows launcher fails to suppress console

2018-09-30 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1308:
--
Component/s: platform - Launchers

> Windows launcher fails to suppress console
> --
>
> Key: NETBEANS-1308
> URL: https://issues.apache.org/jira/browse/NETBEANS-1308
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: Next
> Environment: Windows 10
>Reporter: Eirik Bakke
>Priority: Critical
>
> The latest version of the Windows launcher (netbeans64.exe), on the master 
> branch per September 16, opens a new console window every time NetBeans is 
> launched from a shortcut or by double-clicking on the executable in Explorer. 
> The console was suppressed in earlier versions.
> I think this applied to the platform application launcher as well (app64.exe) 
> when I tested two weeks ago.
> This bug was present before the unrelated changes in NETBEANS-1227 ( 
> https://github.com/apache/incubator-netbeans/pull/573 ).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1308) Windows launcher fails to suppress console

2018-09-30 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1308:
--
Labels: Platform  (was: )

> Windows launcher fails to suppress console
> --
>
> Key: NETBEANS-1308
> URL: https://issues.apache.org/jira/browse/NETBEANS-1308
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: Next
> Environment: Windows 10
>Reporter: Eirik Bakke
>Priority: Critical
>  Labels: Platform
>
> The latest version of the Windows launcher (netbeans64.exe), on the master 
> branch per September 16, opens a new console window every time NetBeans is 
> launched from a shortcut or by double-clicking on the executable in Explorer. 
> The console was suppressed in earlier versions.
> I think this applied to the platform application launcher as well (app64.exe) 
> when I tested two weeks ago.
> This bug was present before the unrelated changes in NETBEANS-1227 ( 
> https://github.com/apache/incubator-netbeans/pull/573 ).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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] [Closed] (NETBEANS-1261) Thin grey line under active tab on MacOS retina screens

2018-09-30 Thread Eirik Bakke (JIRA)



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

Eirik Bakke closed NETBEANS-1261.
-
Resolution: Fixed

Closed as pull request was merged.

> Thin grey line under active tab on MacOS retina screens
> ---
>
> Key: NETBEANS-1261
> URL: https://issues.apache.org/jira/browse/NETBEANS-1261
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS with Retina display
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: pull-request-available
> Attachments: Thin grey line fixed.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> There is a small rendering artifact, visible on retina screens (e.g. MacBook 
> Pro) on the Aqua LAF, under the active TopComponent tab--a thin grey line 
> that should not be there. See the attached screenshot. I'll submit a patch 
> fixing this after making sure it doesn't cause other problems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1261) Thin grey line under active tab on MacOS retina screens

2018-09-30 Thread Eirik Bakke (JIRA)



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

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

> Thin grey line under active tab on MacOS retina screens
> ---
>
> Key: NETBEANS-1261
> URL: https://issues.apache.org/jira/browse/NETBEANS-1261
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS with Retina display
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: pull-request-available
> Attachments: Thin grey line fixed.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> There is a small rendering artifact, visible on retina screens (e.g. MacBook 
> Pro) on the Aqua LAF, under the active TopComponent tab--a thin grey line 
> that should not be there. See the attached screenshot. I'll submit a patch 
> fixing this after making sure it doesn't cause other problems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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] [Reopened] (NETBEANS-1261) Thin grey line under active tab on MacOS retina screens

2018-09-30 Thread Eirik Bakke (JIRA)



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

Eirik Bakke reopened NETBEANS-1261:
---

> Thin grey line under active tab on MacOS retina screens
> ---
>
> Key: NETBEANS-1261
> URL: https://issues.apache.org/jira/browse/NETBEANS-1261
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS with Retina display
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: pull-request-available
> Attachments: Thin grey line fixed.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> There is a small rendering artifact, visible on retina screens (e.g. MacBook 
> Pro) on the Aqua LAF, under the active TopComponent tab--a thin grey line 
> that should not be there. See the attached screenshot. I'll submit a patch 
> fixing this after making sure it doesn't cause other problems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1308) Windows launcher fails to suppress console

2018-10-02 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-1308:
---

Bug is confirmed to be present in 10vc1.

> Windows launcher fails to suppress console
> --
>
> Key: NETBEANS-1308
> URL: https://issues.apache.org/jira/browse/NETBEANS-1308
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: Next
> Environment: Windows 10
>Reporter: Eirik Bakke
>Priority: Critical
>
> The latest version of the Windows launcher (netbeans64.exe), on the master 
> branch per September 16, opens a new console window every time NetBeans is 
> launched from a shortcut or by double-clicking on the executable in Explorer. 
> The console was suppressed in earlier versions.
> I think this applied to the platform application launcher as well (app64.exe) 
> when I tested two weeks ago.
> This bug was present before the unrelated changes in NETBEANS-1227 ( 
> https://github.com/apache/incubator-netbeans/pull/573 ).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1308) Windows launcher fails to suppress console

2018-10-02 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1308:
--
Affects Version/s: (was: Next)
   10.0

> Windows launcher fails to suppress console
> --
>
> Key: NETBEANS-1308
> URL: https://issues.apache.org/jira/browse/NETBEANS-1308
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 10.0
> Environment: Windows 10
>Reporter: Eirik Bakke
>Priority: Critical
>
> The latest version of the Windows launcher (netbeans64.exe), on the master 
> branch per September 16, opens a new console window every time NetBeans is 
> launched from a shortcut or by double-clicking on the executable in Explorer. 
> The console was suppressed in earlier versions.
> I think this applied to the platform application launcher as well (app64.exe) 
> when I tested two weeks ago.
> This bug was present before the unrelated changes in NETBEANS-1227 ( 
> https://github.com/apache/incubator-netbeans/pull/573 ).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-713) HighlightingManager does not track changes to HighlightsLayerExcludes correctly

2018-10-01 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-713:
-
Fix Version/s: 10.0

> HighlightingManager does not track changes to HighlightsLayerExcludes 
> correctly
> ---
>
> Key: NETBEANS-713
> URL: https://issues.apache.org/jira/browse/NETBEANS-713
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2, 9.0
>Reporter: Eirik Bakke
>Assignee: Emilian Bold
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 10.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The editor API defines the JEditorPane client properties 
> [HighlightsLayerExcludes and 
> HighlightsLayerIncludes|http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor-lib2/index.html?org/netbeans/spi/editor/highlighting/package-summary.html]
>  to allow clients to show/hide specific highlight layers on demand. The bug 
> is that modifications to these properties are not reflected properly in the 
> editor.
> The use case here is for a NetBeans Platform application that needs to modify 
> the client properties depending on user action (e.g. keyboard focus state).
> The bug seems to be in 
> o.n.modules.editor.lib2.highlighting.HighlightingManager.Highlighting. In the 
> constructor, the paneFilter variable is initialized once from the 
> HighlightsLayerExcludes/HighlightsLayerIncludes client properties, right 
> above where the propertyChangeListener that is supposed to track changes to 
> it is added. The PropertyChangeListener reacts to changes to the client 
> properties by calling rebuildAllLayers(), which calls rebuildAllLayersImpl(), 
> which always just uses the value of paneFilter set in the constructor.
> Originally reported as Bugzilla bug 
> [248664|https://netbeans.org/bugzilla/show_bug.cgi?id=248664]. Adding this as 
> a JIRA issue to associate with a pull request that I'm about to open.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-673) Add support for MariaDB JDBC driver in Add Connection dialog

2018-10-01 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-673:
-
Fix Version/s: 10.0

> Add support for MariaDB JDBC driver in Add Connection dialog
> 
>
> Key: NETBEANS-673
> URL: https://issues.apache.org/jira/browse/NETBEANS-673
> Project: NetBeans
>  Issue Type: Bug
>  Components: db - Code
>Affects Versions: 9.0
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 10.0
>
> Attachments: NETBEANS-673 Patch Screenshot Updated.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The "Add Connection" wizard does not currently recognize the MariaDB JDBC 
> driver; this means that the "host", "port", and "database" fields do not end 
> up being shown in the connection panel. Instead, the user has to manually 
> construct the JDBC URL to insert this information.
> The fix is simple; a new entry needs to be added in 
> org.netbeans.modules.db.util.DriverListUtil , recognizing the driver class 
> "org.mariadb.jdbc.Driver" (instead of "com.mysql.jdbc.Driver" for MySQL). The 
> MariaDB driver uses the exact same format for its JDBC URLs as MySQL, except 
> allows the protocol name "mariadb" to be used instead of "mysql".
> (MariaDB and its driver aims to be completely compatible with MySQL--either 
> driver can be used to connect to either database. The MariaDB JDBC driver is 
> LGPL while MySQL's driver is GPL, however, making only the MariaDB one 
> suitable for bundling with commercial software.)
> See also https://issues.apache.org/jira/browse/NETBEANS-170, which deals with 
> simplifying the JDBC driver download process.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-673) Add support for MariaDB JDBC driver in Add Connection dialog

2018-10-01 Thread Eirik Bakke (JIRA)



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

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

> Add support for MariaDB JDBC driver in Add Connection dialog
> 
>
> Key: NETBEANS-673
> URL: https://issues.apache.org/jira/browse/NETBEANS-673
> Project: NetBeans
>  Issue Type: Bug
>  Components: db - Code
>Affects Versions: 9.0
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 10.0
>
> Attachments: NETBEANS-673 Patch Screenshot Updated.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The "Add Connection" wizard does not currently recognize the MariaDB JDBC 
> driver; this means that the "host", "port", and "database" fields do not end 
> up being shown in the connection panel. Instead, the user has to manually 
> construct the JDBC URL to insert this information.
> The fix is simple; a new entry needs to be added in 
> org.netbeans.modules.db.util.DriverListUtil , recognizing the driver class 
> "org.mariadb.jdbc.Driver" (instead of "com.mysql.jdbc.Driver" for MySQL). The 
> MariaDB driver uses the exact same format for its JDBC URLs as MySQL, except 
> allows the protocol name "mariadb" to be used instead of "mysql".
> (MariaDB and its driver aims to be completely compatible with MySQL--either 
> driver can be used to connect to either database. The MariaDB JDBC driver is 
> LGPL while MySQL's driver is GPL, however, making only the MariaDB one 
> suitable for bundling with commercial software.)
> See also https://issues.apache.org/jira/browse/NETBEANS-170, which deals with 
> simplifying the JDBC driver download process.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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] [Reopened] (NETBEANS-673) Add support for MariaDB JDBC driver in Add Connection dialog

2018-10-01 Thread Eirik Bakke (JIRA)



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

Eirik Bakke reopened NETBEANS-673:
--

> Add support for MariaDB JDBC driver in Add Connection dialog
> 
>
> Key: NETBEANS-673
> URL: https://issues.apache.org/jira/browse/NETBEANS-673
> Project: NetBeans
>  Issue Type: Bug
>  Components: db - Code
>Affects Versions: 9.0
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 10.0
>
> Attachments: NETBEANS-673 Patch Screenshot Updated.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The "Add Connection" wizard does not currently recognize the MariaDB JDBC 
> driver; this means that the "host", "port", and "database" fields do not end 
> up being shown in the connection panel. Instead, the user has to manually 
> construct the JDBC URL to insert this information.
> The fix is simple; a new entry needs to be added in 
> org.netbeans.modules.db.util.DriverListUtil , recognizing the driver class 
> "org.mariadb.jdbc.Driver" (instead of "com.mysql.jdbc.Driver" for MySQL). The 
> MariaDB driver uses the exact same format for its JDBC URLs as MySQL, except 
> allows the protocol name "mariadb" to be used instead of "mysql".
> (MariaDB and its driver aims to be completely compatible with MySQL--either 
> driver can be used to connect to either database. The MariaDB JDBC driver is 
> LGPL while MySQL's driver is GPL, however, making only the MariaDB one 
> suitable for bundling with commercial software.)
> See also https://issues.apache.org/jira/browse/NETBEANS-170, which deals with 
> simplifying the JDBC driver download process.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-980) Home/end/up/down do not work properly when word wrapping is enabled

2018-10-01 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-980:
-
Fix Version/s: 10.0

> Home/end/up/down do not work properly when word wrapping is enabled
> ---
>
> Key: NETBEANS-980
> URL: https://issues.apache.org/jira/browse/NETBEANS-980
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Other, editor - Painting  Printing
>Affects Versions: 9.0
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: pull-request-available
> Fix For: 10.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Caret movements via Home/End and arrow Up/Down keys do not work properly when 
> text wrap (especially in "after words" mode) is enabled in the NetBeans 
> editor.
> Specific bugs:
> 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
> beginning of the paragraph rather than to the beginning of the current wrap 
> line (physical line).
> 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
> beginning of the next wrap line instead of to the end of the current wrap 
> line.
> 3) Pressing Up has no effect if the preceding wrap line ended before the 
> caret's current X position.
> 4) Pressing Down will move the caret down _two_ lines if the following wrap 
> line ended before the caret's current X position (and assuming the wrap line 
> two lines down is long enough).
> 5) Left-clicking the mouse to the right of the end of a wrap line puts the 
> caret on the beginning of the next wrap line rather than at the end of the 
> current (clicked) wrap line.
> The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
> (UpAction/DownAction/BeginLineAction/EndLineAction).
> Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and 
> is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to 
> move the caret before lineStartPos.)
> Bugs 2-5 above all relate to what caret position is mapped to the "infinite" 
> horizontal space that follows each wrap line. With NetBeans' current 
> behavior, this space corresponds to a caret position directly following the 
> last character of a wrap line. This caret position, however, is physically 
> mapped (and painted) on the beginning of the following wrap line, which 
> confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 
> is fixed, then bugs 2-4 might "fix themselves" as well.
> For bug 5, I think the best solution when clicking the space beyond the end 
> of a wrap line would be to move the caret to right _before_ the last 
> character on the wrap line. This character is usually a space (in word wrap 
> mode), though it could also be a hyphen or such if a more advanced word 
> wrapping algorithm is used (proposed in the pull request for NETBEANS-977). 
> The resulting behavior would be similar to that of a default JTextArea, or 
> jEdit (though these never break words on anything else than a space). Another 
> solution would be to do like the TextEdit app on MacOS, where the cursor is 
> placed _after_ the last character on the wrap line, like NetBeans currently 
> does, but with a backwards bias such that the cursor is painted on the end of 
> the current wrap line instead of on the beginning of the next wrap line. The 
> latter is probably harder to implement, and is not really necessary.
> To test the above bugs:
> 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
> set "Line Wrap" to "After words". Click OK.
> 2) Create a new plain text file and paste in the paragraph "SHORTWORD 
> LONGWORD SHORTWORD LUUUNGWORD".
> 3) Resize the editor window so that the paragraph gets split into four wrap 
> lines (one word on each wrap line--i.e. make the editor a little wider than 
> the long word).
> 4) For each bugs 1-4 listed above, position the caret right after 
> "...ONG", then press the relevant key to test.
> 5) To test bug 5 above, click the mouse to the right of the first, second, or 
> third wrap line.
> Tested in NetBeans 9.0 rc1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1261) Thin grey line under active tab on MacOS retina screens

2018-10-01 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1261:
--
Fix Version/s: 10.0

> Thin grey line under active tab on MacOS retina screens
> ---
>
> Key: NETBEANS-1261
> URL: https://issues.apache.org/jira/browse/NETBEANS-1261
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS with Retina display
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 10.0
>
> Attachments: Thin grey line fixed.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> There is a small rendering artifact, visible on retina screens (e.g. MacBook 
> Pro) on the Aqua LAF, under the active TopComponent tab--a thin grey line 
> that should not be there. See the attached screenshot. I'll submit a patch 
> fixing this after making sure it doesn't cause other problems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-406) addPropertyChangeListener w/o matching removePropertyChangeListener

2018-10-01 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-406:
-
Fix Version/s: 10.0

> addPropertyChangeListener w/o matching removePropertyChangeListener
> ---
>
> Key: NETBEANS-406
> URL: https://issues.apache.org/jira/browse/NETBEANS-406
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - CSL (API  infrastructure), editor - 
> Painting  Printing
>Affects Versions: 8.2, 9.0
> Environment: NetBeans 9.0 beta 
> (incubator-netbeans-release-205-on-20180202) on OpenJDK 64-Bit Server VM 
> 9.0.4.1+11, Mac OS 10.9.5
>Reporter: Eirik Bakke
>Assignee: Matthias Bläsing
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 10.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> The following warning appears in the IDE log every now and then in 8.2 and 
> 9.0 beta:
>  
> {code:java}
> WARNING [org.openide.util.WeakListenerImpl]: Can't remove 
> java.beans.PropertyChangeListener using method 
> org.netbeans.modules.editor.NbEditorDocument.removePropertyChangeListener 
> from org.netbeans.modules.editor.NbEditorDocument@299b063c, 
> mimeType='text/x-editor-search', kitClass=null, length=9, version=15, 
> file=null{code}
>  
> The warning above can be reproduced by opening a Java editor, closing all 
> editors, and then invoking a GC with by double-clicking the memory meter in 
> the "Performance" toolbar item. 
> This bug was previously discussed in Bugzilla at 
> [https://netbeans.org/bugzilla/show_bug.cgi?id=196323] . Not sure what 
> priority to put for this bug; it's a memory leak, but I'm not sure how big of 
> an impact it has.
> *Analysis*
> Storing a stacktrace in WeakListenerImpl.ListenerReference on creation and 
> then printing it on the failed removal shows the place where the problematic 
> listener is added:
> {code:java}
> java.lang.Exception
>  at 
> org.openide.util.WeakListenerImpl$ListenerReference.(WeakListenerImpl.java:554)
>  at org.openide.util.WeakListenerImpl.(WeakListenerImpl.java:109)
>  at org.openide.util.WeakListenerImpl.(WeakListenerImpl.java:99)
>  at 
> org.openide.util.WeakListenerImpl$PropertyChange.(WeakListenerImpl.java:187)
>  at org.openide.util.WeakListeners.propertyChange(WeakListeners.java:282)
>  at 
> org.netbeans.modules.editor.lib2.view.DocumentViewOp.checkSettingsInfo(DocumentViewOp.java:937)
>  at 
> org.netbeans.modules.editor.lib2.view.DocumentViewOp.checkViewsInited(DocumentViewOp.java:622)
>  at 
> org.netbeans.modules.editor.lib2.view.DocumentView.getPreferredSpan(DocumentView.java:251)
>  at 
> javax.swing.plaf.basic.BasicTextUI$RootView.getPreferredSpan(BasicTextUI.java:1353)
>  at javax.swing.plaf.basic.BasicTextUI.getPreferredSize(BasicTextUI.java:919)
>  at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
>  at javax.swing.JEditorPane.getPreferredSize(JEditorPane.java:1333)
>  at 
> org.netbeans.modules.editor.NbEditorUI$LayeredEditorPane.getPreferredSize(NbEditorUI.java:475){code}
> The problem is on this line of DocumentViewOp:
> {code:java}
> o.n.modules.editor.lib2.view.DocumentUtilities.addPropertyChangeListener(doc, 
> WeakListeners.propertyChange(this, doc));{code}
> The DocumentUtilities.addPropertyChangeListener is a special API for allowing 
> property change listeners to be attached to BaseDocument instances (see 
> Bugzilla [https://netbeans.org/bugzilla/show_bug.cgi?id=181073] ). Since it 
> doesn't actually add addPropertyChangeListener/removePropertyChangeListener 
> methods to BaseDocument, it doesn't work with WeakListeners.
> As far as I can see, the only place that actually uses 
> DocumentUtilities.addPropertyChangeListener is the single line i 
> DocumentViewOp above.
> I would propose adding a removedPropertyChangeListener method to BaseDocument 
> that delegates to DocumentUtilities.removePropertyChangeListener (or performs 
> the equivalent logic itself). This way the WeakListener will find the method 
> it expects when the listener is due to be removed, and the property change 
> events will still have the Document instance as the event source instead of 
> the delegate PropertyChangeSupport, as is probably desired.
> An alternative is to make WeakListeners aware of the special setup wrt. 
> property change listeners on BaseDocument instances. But that seems like an 
> abstraction violation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (NETBEANS-49) Please add smooth scrolling

2018-10-03 Thread Eirik Bakke (JIRA)



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

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

Closing as corresponding pull request was merged.

> Please add smooth scrolling 
> 
>
> Key: NETBEANS-49
> URL: https://issues.apache.org/jira/browse/NETBEANS-49
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Window System
>Reporter: Christian Lenz
>Priority: Major
>  Labels: pull-request-available
> Fix For: Next
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Inside the editor, when I scroll with my touchpad to the bottom, it jumps 9 
> lines to the next, this is a lot. I don't like such gappings I would like to 
> have a smooth stepless scrolling, like in chrome or other windows native 
> apps. Please add this for horizontal and vertical scrolling, it will be much 
> better. Not only in editors, it should be available everywhere, where we have 
> scrollbars.
> Regards
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1284) Missing toggle button indication in Find Usages pane

2018-09-22 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1284:
--
Description: 
The "Find Usages" pane has a number of toggle buttons on its left. On MacOS, 
there is no indication of whether each toggle button is depressed or not. On 
Windows, the indication is present in Java 8 but disappeared in Java 9. See the 
attached screenshot.

The regression on Windows going from Java 8 to Java 9 probably happened due to 
https://bugs.openjdk.java.net/browse/JDK-4796987 (see 
https://bugs.openjdk.java.net/browse/JDK-8186366 ).

The relevant code is in
src/org/netbeans/modules/refactoring/spi/impl/FiltersManagerImpl.java . 
Removing the "result.setBorderPainted(false);" line fixes the problem on 
Windows but not on MacOS.

  was:
The "Find Usages" pane has a number of toggle buttons on its left. On MacOS, 
there is no indication of whether each toggle button is depressed or not. On 
Windows, the indication is present in Java 8 but disappeared in Java 9. See the 
attached screenshot.

The relevant code is in
src/org/netbeans/modules/refactoring/spi/impl/FiltersManagerImpl.java

The regression on Windows going from Java 8 to Java 9 probably happened due to 
https://bugs.openjdk.java.net/browse/JDK-4796987 (see 
https://bugs.openjdk.java.net/browse/JDK-8186366 ).

Removing the "result.setBorderPainted(false);" line fixes the problem on 
Windows but not on MacOS.


> Missing toggle button indication in Find Usages pane
> 
>
> Key: NETBEANS-1284
> URL: https://issues.apache.org/jira/browse/NETBEANS-1284
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Refactoring
>Affects Versions: 9.0
> Environment: MacOS (Java 8 verified) or Windows (Java 9 or 10, but 
> not Java 8)
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: missingtoggle.png
>
>
> The "Find Usages" pane has a number of toggle buttons on its left. On MacOS, 
> there is no indication of whether each toggle button is depressed or not. On 
> Windows, the indication is present in Java 8 but disappeared in Java 9. See 
> the attached screenshot.
> The regression on Windows going from Java 8 to Java 9 probably happened due 
> to https://bugs.openjdk.java.net/browse/JDK-4796987 (see 
> https://bugs.openjdk.java.net/browse/JDK-8186366 ).
> The relevant code is in
> src/org/netbeans/modules/refactoring/spi/impl/FiltersManagerImpl.java . 
> Removing the "result.setBorderPainted(false);" line fixes the problem on 
> Windows but not on MacOS.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1260) HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF

2018-09-20 Thread Eirik Bakke (JIRA)



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

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

> HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF
> --
>
> Key: NETBEANS-1260
> URL: https://issues.apache.org/jira/browse/NETBEANS-1260
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, pull-request-available
> Attachments: NETBEANS-1260 MacOS Retina After Patch.png, 
> NETBEANS-1260 MacOS Retina Before Patch.png, VectorIconTest Output with Aqua 
> and Windows vector icons.png
>
>
> To look good on MacBook Pro and other Apple computers with Retina screens, 
> the various icons that are part of NetBeans' window system must be made 
> available in both 100% and 200% sizes. This includes, for instance, the "X" 
> button that is used to close tabs, the "_" button that collapses a sidebar, 
> or the ">>" button that shows hidden toolbar icons. These icons reside in the 
> tabcontrol and openide.awt modules.
> I'll soon submit a pull request that fixes this by providing vectorized 
> versions of the relevant window system icons. The approach is the same as is 
> taken for the Windows LAF, in NETBEANS-1238.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1260) HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF

2018-09-20 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1260:
--
Environment: MacOS with retina screens (e.g. MacBook Pro)  (was: MacOS)

> HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF
> --
>
> Key: NETBEANS-1260
> URL: https://issues.apache.org/jira/browse/NETBEANS-1260
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS with retina screens (e.g. MacBook Pro)
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, pull-request-available
> Attachments: NETBEANS-1260 MacOS Retina After Patch.png, 
> NETBEANS-1260 MacOS Retina Before Patch.png, VectorIconTest Output with Aqua 
> and Windows vector icons.png
>
>
> To look good on MacBook Pro and other Apple computers with Retina screens, 
> the various icons that are part of NetBeans' window system must be made 
> available in both 100% and 200% sizes. This includes, for instance, the "X" 
> button that is used to close tabs, the "_" button that collapses a sidebar, 
> or the ">>" button that shows hidden toolbar icons. These icons reside in the 
> tabcontrol and openide.awt modules.
> I'll soon submit a pull request that fixes this by providing vectorized 
> versions of the relevant window system icons. The approach is the same as is 
> taken for the Windows LAF, in NETBEANS-1238.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1284) Missing toggle button indication in Find Usages pane

2018-09-22 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1284:
--
Priority: Minor  (was: Major)

> Missing toggle button indication in Find Usages pane
> 
>
> Key: NETBEANS-1284
> URL: https://issues.apache.org/jira/browse/NETBEANS-1284
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Refactoring
>Affects Versions: 9.0
> Environment: MacOS (Java 8 verified) or Windows (Java 9 or 10, but 
> not Java 8)
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: missingtoggle.png
>
>
> The "Find Usages" pane has a number of toggle buttons on its left. On MacOS, 
> there is no indication of whether each toggle button is depressed or not. On 
> Windows, the indication is present in Java 8 but disappeared in Java 9. See 
> the attached screenshot.
> The relevant code is in
> src/org/netbeans/modules/refactoring/spi/impl/FiltersManagerImpl.java
> The regression on Windows going from Java 8 to Java 9 probably happened due 
> to https://bugs.openjdk.java.net/browse/JDK-4796987 (see 
> https://bugs.openjdk.java.net/browse/JDK-8186366 ).
> Removing the "result.setBorderPainted(false);" line fixes the problem on 
> Windows but not on MacOS.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1284) Missing toggle button indication in Find Usages pane

2018-09-22 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1284:
--
Description: 
The "Find Usages" pane has a number of toggle buttons on its left. On MacOS, 
there is no indication of whether each toggle button is depressed or not. On 
Windows, the indication is present in Java 8 but disappeared in Java 9. See the 
attached screenshot.

The relevant code is in
src/org/netbeans/modules/refactoring/spi/impl/FiltersManagerImpl.java

The regression on Windows going from Java 8 to Java 9 probably happened due to 
https://bugs.openjdk.java.net/browse/JDK-4796987 (see 
https://bugs.openjdk.java.net/browse/JDK-8186366 ).

Removing the "result.setBorderPainted(false);" line fixes the problem on 
Windows but not on MacOS.

  was:
The "Find Usages" pane has a number of toggle buttons on its left. On MacOS, 
there is no indication of whether each toggle button is depressed or not. On 
Windows, the indication is present in Java 8 but disappeared in Java 9.

The relevant code is in
src/org/netbeans/modules/refactoring/spi/impl/FiltersManagerImpl.java

The regression on Windows going from Java 8 to Java 9 probably happened due to 
https://bugs.openjdk.java.net/browse/JDK-4796987 (see 
https://bugs.openjdk.java.net/browse/JDK-8186366 ).

Removing the "result.setBorderPainted(false);" line fixes the problem on 
Windows but not on MacOS.


> Missing toggle button indication in Find Usages pane
> 
>
> Key: NETBEANS-1284
> URL: https://issues.apache.org/jira/browse/NETBEANS-1284
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Refactoring
>Affects Versions: 9.0
> Environment: MacOS (Java 8 verified) or Windows (Java 9 or 10, but 
> not Java 8)
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: missingtoggle.png
>
>
> The "Find Usages" pane has a number of toggle buttons on its left. On MacOS, 
> there is no indication of whether each toggle button is depressed or not. On 
> Windows, the indication is present in Java 8 but disappeared in Java 9. See 
> the attached screenshot.
> The relevant code is in
> src/org/netbeans/modules/refactoring/spi/impl/FiltersManagerImpl.java
> The regression on Windows going from Java 8 to Java 9 probably happened due 
> to https://bugs.openjdk.java.net/browse/JDK-4796987 (see 
> https://bugs.openjdk.java.net/browse/JDK-8186366 ).
> Removing the "result.setBorderPainted(false);" line fixes the problem on 
> Windows but not on MacOS.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1284) Missing toggle button indication in Find Usages pane

2018-09-22 Thread Eirik Bakke (JIRA)

Eirik Bakke created NETBEANS-1284:
-

 Summary: Missing toggle button indication in Find Usages pane
 Key: NETBEANS-1284
 URL: https://issues.apache.org/jira/browse/NETBEANS-1284
 Project: NetBeans
  Issue Type: Bug
  Components: editor - Refactoring
Affects Versions: 9.0
 Environment: MacOS (Java 8 verified) or Windows (Java 9 or 10, but not 
Java 8)
Reporter: Eirik Bakke
 Attachments: missingtoggle.png

The "Find Usages" pane has a number of toggle buttons on its left. On MacOS, 
there is no indication of whether each toggle button is depressed or not. On 
Windows, the indication is present in Java 8 but disappeared in Java 9.

The relevant code is in
src/org/netbeans/modules/refactoring/spi/impl/FiltersManagerImpl.java

The regression on Windows going from Java 8 to Java 9 probably happened due to 
https://bugs.openjdk.java.net/browse/JDK-4796987 (see 
https://bugs.openjdk.java.net/browse/JDK-8186366 ).

Removing the "result.setBorderPainted(false);" line fixes the problem on 
Windows but not on MacOS.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1227) Mark Windows launcher binary as per-monitor DPI aware

2018-12-29 Thread Eirik Bakke (JIRA)



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

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

Confirmed fixed in 10.0 release.

> Mark Windows launcher binary as per-monitor DPI aware
> -
>
> Key: NETBEANS-1227
> URL: https://issues.apache.org/jira/browse/NETBEANS-1227
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 9.0
> Environment: Windows 8.1 and Windows 10
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, pull-request-available
> Fix For: 10.0
>
> Attachments: SmallIconsRun.png
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> As of Java 10.0.2, support for HiDPI monitors on Windows is quite good. All 
> the standard Swing components appear in high resolution, and Graphics2D 
> surfaces are automatically scaled appropriately for whichever monitor their 
> containing window is located on, including when windows are dragged between 
> monitors in a mixed-DPI multi-monitor setting.
> For this to work, however, the EXE file that launches NetBeans must contain a 
> manifest that declares the application to be DPI-aware. Such a manifest 
> currently exists in java.exe and javaw.exe, but not in the custom 
> netbeans64.exe launcher. A workaround for the missing manifest is to right 
> click the "bin\netbeans64.exe" file, or whichever shortcut is being used to 
> open NetBeans, go to the "Compatibility" tab, click "Change high DPI 
> settings", "Override high DPI scaling behavior", and select scaling performed 
> by "Application".
> An appropriate manifest should be added to netbeans64.exe to declare NetBeans 
> as per-monitor DPI aware.
> To see how the manifest should be declared, we can dump the manifest of 
> javaw.exe:
>  {code:xml}
> 
>  xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
>   processorArchitecture="X86" type="win32"/>
>  Java(TM) SE process
>  
>  
>   xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings;>
>  true/PM
>  
>  
>  
> 
> {code}
> This reveals that Java 10.0.2 considers itself DPI-aware at the "Per Monitor 
> V1" level (see the Microsoft documentation linked below). The NetBeans 
> launcher binary should declare the same.
> References:
> [https://docs.microsoft.com/en-us/windows/desktop/hidpi/high-dpi-desktop-application-development-on-windows]
> [https://msdn.microsoft.com/en-us/library/windows/desktop/mt846517(v=vs.85).aspx]
> [https://docs.microsoft.com/en-us/windows/desktop/sbscs/application-manifests]
> [https://blogs.msdn.microsoft.com/mithuns/2009/12/16/random-how-to-quickly-view-a-binarys-embedded-manifest]
> [https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-374) font is too small on high res notebook monitor

2018-12-29 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-374:
--

Is this issue still present on NetBeans 10? Are you on Windows, MacOS, or Linux?

On Windows, the issue should be fixed by 
https://issues.apache.org/jira/browse/NETBEANS-1227 .

> font is too small on high res notebook monitor
> --
>
> Key: NETBEANS-374
> URL: https://issues.apache.org/jira/browse/NETBEANS-374
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - UI
>Reporter: Peter
>Priority: Major
>
> font is too small on high res notebook monitor (e.g. macbook pro 15, 
> 2880x1800). Even i tuned to enlarge the font, all other things : menu, button 
> are just too small



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-346) Tabs, characters, and the right Margin don't line up

2019-01-17 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-346:
-
Priority: Critical  (was: Major)

> Tabs, characters, and the right Margin don't line up
> 
>
> Key: NETBEANS-346
> URL: https://issues.apache.org/jira/browse/NETBEANS-346
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Other
>Affects Versions: 9.0
> Environment: Mac OS 10.10 (at least)
>Reporter: Austin Stephens
>Priority: Critical
>  Labels: HiDPI, font
> Attachments: Screen Shot 2018-01-29 at 4.58.35 PM.png, Screen Shot 
> 2018-02-28 at 11.27.32 AM.png, linewidth.png
>
>
> When the Right Margin is set at 80 chars, it is drawn at 8*2* chars. This is 
> annoying because I have a 1440x900 screen that I split vertically in to two. 
> This results in two editing areas that are about 80 chars wide. I could see 
> the margin line in both editors when scrolled all the way to the left. Since 
> Netbeans (9.0 beta) is now drawing them at char 8*2*, it is not possible to 
> size those editors so I can see the line in both windows and it is driving me 
> crazy.
> This is a first world issue at the moment, but you might find code coming 
> from mac programmers coming in two or more chars too wide in the Netbeans 
> source code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-346) Tabs, characters, and the right Margin don't line up

2019-01-17 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-346:
--

Drawing the end-of-line marker in the wrong place has turned out to be a quite 
bad bug. For myself, it took about 4 months to discover the problem, and 
another month to discover a workaround (which is to select a zoom level for 
which the marker happens to be in the right place). My source code repository 
now has a mix of line widths from the 4 months of work during which I was 
unaware of the problem, and my git log is littered with "fix line widths"-type 
entries. To properly repair the damage I had to spend an hour setting up 
checkstyle and going into each file to correct all the line widths. Increased 
the bug priority to "Critical" for this reason.

> Tabs, characters, and the right Margin don't line up
> 
>
> Key: NETBEANS-346
> URL: https://issues.apache.org/jira/browse/NETBEANS-346
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Other
>Affects Versions: 9.0
> Environment: Mac OS 10.10 (at least)
>Reporter: Austin Stephens
>Priority: Critical
>  Labels: HiDPI, font
> Attachments: Screen Shot 2018-01-29 at 4.58.35 PM.png, Screen Shot 
> 2018-02-28 at 11.27.32 AM.png, linewidth.png
>
>
> When the Right Margin is set at 80 chars, it is drawn at 8*2* chars. This is 
> annoying because I have a 1440x900 screen that I split vertically in to two. 
> This results in two editing areas that are about 80 chars wide. I could see 
> the margin line in both editors when scrolled all the way to the left. Since 
> Netbeans (9.0 beta) is now drawing them at char 8*2*, it is not possible to 
> size those editors so I can see the line in both windows and it is driving me 
> crazy.
> This is a first world issue at the moment, but you might find code coming 
> from mac programmers coming in two or more chars too wide in the Netbeans 
> source code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-346) Tabs, characters, and the right Margin don't line up

2019-01-17 Thread Eirik Bakke (JIRA)



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

Eirik Bakke edited comment on NETBEANS-346 at 1/17/19 6:09 PM:
---

Drawing the end-of-line marker in the wrong place has turned out to be a quite 
bad bug. For myself, it took about 4 months to discover the problem, and 
another month to discover a workaround (which is to select a zoom level for 
which the marker happens to be in the right place). My source code repository 
now has a mix of line widths from the 4 months of work during which I was 
unaware of the problem, and my git log is littered with "fix line widths"-type 
entries. To properly repair the damage, I had to spend an hour setting up 
checkstyle and going into each file to correct all the line widths. Increased 
the bug priority to "Critical" for this reason.


was (Author: ebakke):
Drawing the end-of-line marker in the wrong place has turned out to be a quite 
bad bug. For myself, it took about 4 months to discover the problem, and 
another month to discover a workaround (which is to select a zoom level for 
which the marker happens to be in the right place). My source code repository 
now has a mix of line widths from the 4 months of work during which I was 
unaware of the problem, and my git log is littered with "fix line widths"-type 
entries. To properly repair the damage I had to spend an hour setting up 
checkstyle and going into each file to correct all the line widths. Increased 
the bug priority to "Critical" for this reason.

> Tabs, characters, and the right Margin don't line up
> 
>
> Key: NETBEANS-346
> URL: https://issues.apache.org/jira/browse/NETBEANS-346
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Other
>Affects Versions: 9.0
> Environment: Mac OS 10.10 (at least)
>Reporter: Austin Stephens
>Priority: Critical
>  Labels: HiDPI, font
> Attachments: Screen Shot 2018-01-29 at 4.58.35 PM.png, Screen Shot 
> 2018-02-28 at 11.27.32 AM.png, linewidth.png
>
>
> When the Right Margin is set at 80 chars, it is drawn at 8*2* chars. This is 
> annoying because I have a 1440x900 screen that I split vertically in to two. 
> This results in two editing areas that are about 80 chars wide. I could see 
> the margin line in both editors when scrolled all the way to the left. Since 
> Netbeans (9.0 beta) is now drawing them at char 8*2*, it is not possible to 
> size those editors so I can see the line in both windows and it is driving me 
> crazy.
> This is a first world issue at the moment, but you might find code coming 
> from mac programmers coming in two or more chars too wide in the Netbeans 
> source code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-49) Please add smooth scrolling

2018-12-12 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-49:
-

Yes, this patch was Windows-specific. There are two options for making it work 
for other LAFs:
1) Use reflection to make the patch LAF-independent, like in 
http://mail.openjdk.java.net/pipermail/awt-dev/2017-January/012507.html . The 
problem is that this particular reflection trick might be disallowed in future 
Java versions (at least according to a warning message that is printed by the 
JRE when this approach is used).
2) Make a new custom ScrollPaneUI class for each LAF that is to be supported, 
extending from whatever LAF-specific ScrollPaneUI class is used in said LAF. 
For Darcula, this requires copying the code in this patch to the Darcula 
repository.

I'm not sure which approach is better--in particular, I don't know exactly how 
likely the reflection-based approach (approach 1) is to fail in future Java 
versions.

Approach 1 would be a change in NetBeans only, while Approach 2 would require a 
change on the Darcula side, and some code duplication.


> Please add smooth scrolling 
> 
>
> Key: NETBEANS-49
> URL: https://issues.apache.org/jira/browse/NETBEANS-49
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Window System
>Reporter: Christian Lenz
>Priority: Major
>  Labels: pull-request-available
> Fix For: 10.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Inside the editor, when I scroll with my touchpad to the bottom, it jumps 9 
> lines to the next, this is a lot. I don't like such gappings I would like to 
> have a smooth stepless scrolling, like in chrome or other windows native 
> apps. Please add this for horizontal and vertical scrolling, it will be much 
> better. Not only in editors, it should be available everywhere, where we have 
> scrollbars.
> Regards
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-49) Please add smooth scrolling

2018-12-13 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-49:
-

OK, let's discuss Approach 2, then.

The main requirement is to override BasicScrollPaneUI's 
createMouseWheelListener. For LAFs that add their own ScrollPaneUI class that 
extends from BasicScrollPaneUI, this must be done by extending from said 
LAF-specific class instead of directly from BasicScrollPaneUI (so that we 
retain whatever other functionality the LAF has added to BasicScrollPaneUI).

I had a quick look in https://github.com/Revivius/nb-darcula and could not 
actually see the ScrollPaneUI being overridden anywhere. Maybe I'm wrong. But 
in any case the existing patch does not seem to work on Darcula on Windows 10. 
Some investigation would be needed here.

Also be aware that if the code in the patch ends up being copied to Darcula, it 
will have to be updated in two places if we later make other improvements (e.g. 
to fix the Surface Book problems you mentioned earlier).

> Please add smooth scrolling 
> 
>
> Key: NETBEANS-49
> URL: https://issues.apache.org/jira/browse/NETBEANS-49
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Window System
>Reporter: Christian Lenz
>Priority: Major
>  Labels: pull-request-available
> Fix For: 10.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Inside the editor, when I scroll with my touchpad to the bottom, it jumps 9 
> lines to the next, this is a lot. I don't like such gappings I would like to 
> have a smooth stepless scrolling, like in chrome or other windows native 
> apps. Please add this for horizontal and vertical scrolling, it will be much 
> better. Not only in editors, it should be available everywhere, where we have 
> scrollbars.
> Regards
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1428) Fatal error when profiling

2018-11-26 Thread Eirik Bakke (JIRA)



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

Eirik Bakke edited comment on NETBEANS-1428 at 11/26/18 3:44 PM:
-

(Also sent this comment as a reply to the mailing list; including here for 
those looking at the JIRA issue: )
I tested the new DLL--it works!!

Here's what I did:
1) Start a Java profiling session via the "-agentpath" JVM argument and 
invoking "Attach to External Process". Shortly thereafter the JVM crashes with 
the "SUREFIRE-859: #  EXCEPTION_ACCESS_VIOLATION (0xc005) at 
pc=0x5f131f25, pid=10112, tid=23396" error (and a long JVM dump).
2) Download Peter Hull's recompiled profiler binaries from 
https://github.com/pedro-w/incubator-netbeans/releases/tag/v0.1-alpha , and 
paste the two files (profilerinterface.dll and profilerinterface.map) into 
NetBeans\profiler\lib\deployed\jdk16\windows-amd64 (overwriting the two 
existing files).
3) Repeat (1) again. No crash this time, everything works fine!

This is great. Very happy that the profiler functionality will be working 
again, for newer JDKs. Thanks, Peter!



was (Author: ebakke):
(Also sent this comment as a reply to the mailing list; including here for 
those looking at the JIRA issue:)
I tested the new DLL--it works!!

Here's what I did:
1) Start a Java profiling session via the "-agentpath" JVM argument and 
invoking "Attach to External Process". Shortly thereafter the JVM crashes with 
the "SUREFIRE-859: #  EXCEPTION_ACCESS_VIOLATION (0xc005) at 
pc=0x5f131f25, pid=10112, tid=23396" error (and a long JVM dump).
2) Download Peter Hull's recompiled profiler binaries from 
https://github.com/pedro-w/incubator-netbeans/releases/tag/v0.1-alpha , and 
paste the two files (profilerinterface.dll and profilerinterface.map) into 
NetBeans\profiler\lib\deployed\jdk16\windows-amd64 (overwriting the two 
existing files).
3) Repeat (1) again. No crash this time, everything works fine!

This is great. Very happy that the profiler functionality will be working 
again, for newer JDKs. Thanks, Peter!


> Fatal error when profiling
> --
>
> Key: NETBEANS-1428
> URL: https://issues.apache.org/jira/browse/NETBEANS-1428
> Project: NetBeans
>  Issue Type: Bug
>  Components: profiler - Base
>Affects Versions: 9.0, 10.0
> Environment: Windows 10, JDK11 (OpenJDK 11.0+28)
>Reporter: Peter Hull
>Priority: Major
>  Labels: netcat
> Attachments: hs_err_pid38528.log
>
>
> Attempting to profile a Java freeform project (Netcat 10, Profiling FreeForm, 
> Step 2)
> I get the following error
> {{#}}
> {{# A fatal error has been detected by the Java Runtime Environment:}}
> {{#}}
> {{#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7ff8e831c775, 
> pid=38528, tid=38596}}
> {{#}}
> {{# JRE version: OpenJDK Runtime Environment (11.0+28) (build 11+28)}}
> {{# Java VM: OpenJDK 64-Bit Server VM (11+28, mixed mode, tiered, compressed 
> oops, g1 gc, windows-amd64)}}
> {{# Problematic frame:}}
> {{# V  [jvm.dll+0x5ec775]}}
> {{#}}
> {{# No core dump will be written. Minidumps are not enabled by default on 
> client versions of Windows}}
> {{#}}
> {{# An error report file with more information is saved as:}}
> {{# D:\Libraries\Downloads\TS_Profiler_freeform\freeform\hs_err_pid38528.log}}
> {{#}}
> {{# If you would like to submit a bug report, please visit:}}
> {{#   http://bugreport.java.com/bugreport/crash.jsp}}
> {{#}}
> Seems reproducible, I have attached the crash log.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1428) Fatal error when profiling

2018-11-26 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-1428:
---

(Also sent this comment as a reply to the mailing list; including here for 
those looking at the JIRA issue:)
I tested the new DLL--it works!!

Here's what I did:
1) Start a Java profiling session via the "-agentpath" JVM argument and 
invoking "Attach to External Process". Shortly thereafter the JVM crashes with 
the "SUREFIRE-859: #  EXCEPTION_ACCESS_VIOLATION (0xc005) at 
pc=0x5f131f25, pid=10112, tid=23396" error (and a long JVM dump).
2) Download Peter Hull's recompiled profiler binaries from 
https://github.com/pedro-w/incubator-netbeans/releases/tag/v0.1-alpha , and 
paste the two files (profilerinterface.dll and profilerinterface.map) into 
NetBeans\profiler\lib\deployed\jdk16\windows-amd64 (overwriting the two 
existing files).
3) Repeat (1) again. No crash this time, everything works fine!

This is great. Very happy that the profiler functionality will be working 
again, for newer JDKs. Thanks, Peter!


> Fatal error when profiling
> --
>
> Key: NETBEANS-1428
> URL: https://issues.apache.org/jira/browse/NETBEANS-1428
> Project: NetBeans
>  Issue Type: Bug
>  Components: profiler - Base
>Affects Versions: 9.0, 10.0
> Environment: Windows 10, JDK11 (OpenJDK 11.0+28)
>Reporter: Peter Hull
>Priority: Major
>  Labels: netcat
> Attachments: hs_err_pid38528.log
>
>
> Attempting to profile a Java freeform project (Netcat 10, Profiling FreeForm, 
> Step 2)
> I get the following error
> {{#}}
> {{# A fatal error has been detected by the Java Runtime Environment:}}
> {{#}}
> {{#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7ff8e831c775, 
> pid=38528, tid=38596}}
> {{#}}
> {{# JRE version: OpenJDK Runtime Environment (11.0+28) (build 11+28)}}
> {{# Java VM: OpenJDK 64-Bit Server VM (11+28, mixed mode, tiered, compressed 
> oops, g1 gc, windows-amd64)}}
> {{# Problematic frame:}}
> {{# V  [jvm.dll+0x5ec775]}}
> {{#}}
> {{# No core dump will be written. Minidumps are not enabled by default on 
> client versions of Windows}}
> {{#}}
> {{# An error report file with more information is saved as:}}
> {{# D:\Libraries\Downloads\TS_Profiler_freeform\freeform\hs_err_pid38528.log}}
> {{#}}
> {{# If you would like to submit a bug report, please visit:}}
> {{#   http://bugreport.java.com/bugreport/crash.jsp}}
> {{#}}
> Seems reproducible, I have attached the crash log.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-416) Excessive CPU usage

2019-01-07 Thread Eirik Bakke (JIRA)



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

Eirik Bakke edited comment on NETBEANS-416 at 1/7/19 12:31 PM:
---

Are people on Windows 10 observing this behavior _always_, or just sometimes? A 
quick check shows NetBeans 10 using 0% on my own Windows 10 setup.

For troubleshooting purposes, it might be worth trying to turn of Windows 
Defender's background scan, and seeing if the problem persists. I've got it 
permanently disabled myself, for unrelated reasons (it makes Windows Subsystem 
for Linux unbearably slow), but it's probably not something we can recommend.

To turn of Windows Defender's background scan, go into the "Edit Group Policy" 
app and then set Computer Configuration->Administrative Templates->Windows 
Components->Windows Defender Antivirus->Turn off Windows Defender Antivirus.


was (Author: ebakke):
Are people on Windows 10 observing this behavior _always_, or just sometimes? A 
quick check shows NetBeans using 0% on my own Windows 10 setup.

For troubleshooting purposes, it might be worth trying to turn of Windows 
Defender's background scan, and seeing if the problem persists. I've got it 
permanently disabled myself, for unrelated reasons (it makes Windows Subsystem 
for Linux unbearably slow), but it's probably not something we can recommend.

To turn of Windows Defender's background scan, go into the "Edit Group Policy" 
app and then set Computer Configuration->Administrative Templates->Windows 
Components->Windows Defender Antivirus->Turn off Windows Defender Antivirus.

> Excessive CPU usage
> ---
>
> Key: NETBEANS-416
> URL: https://issues.apache.org/jira/browse/NETBEANS-416
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance
>Affects Versions: 8.2, 9.0
> Environment: Windows 10 Pro 64bit
>Reporter: Acs
>Priority: Major
> Attachments: 2018-02-22 14_34_52-Task Manager.png, 
> netbeans_30_cpu_usage.png, netbeans_9.0_plugins.png, profile_9.0.npss, 
> profiler_window.png, selfsampler.npss
>
>
> Hey,
> Something I have noticed in Netbeans is that from time to time Netbeans CPU 
> usage will go up to around 20% and most of the times I have Netbeans in the 
> background so I am not doing anything in Netbeans.
> Please fix this as this is a huge annoyance.
> Edit: To further explain why this is a huge annoyance: Netbeans will trigger 
> my laptop fans with the usage of CPU when it's not doing anything.
> Please someone analyze the profiler and tell me if I have a plugin that is 
> doing this or this is netbeans.
> I am really considering changing IDEs because of t his.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-416) Excessive CPU usage

2019-01-07 Thread Eirik Bakke (JIRA)



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

Eirik Bakke edited comment on NETBEANS-416 at 1/7/19 12:31 PM:
---

Are people on Windows 10 observing this behavior _always_, or just sometimes? A 
quick check shows NetBeans 10 using 0% CPU right now on my own Windows 10 setup.

For troubleshooting purposes, it might be worth trying to turn of Windows 
Defender's background scan, and seeing if the problem persists. I've got it 
permanently disabled myself, for unrelated reasons (it makes Windows Subsystem 
for Linux unbearably slow), but it's probably not something we can recommend.

To turn of Windows Defender's background scan, go into the "Edit Group Policy" 
app and then set Computer Configuration->Administrative Templates->Windows 
Components->Windows Defender Antivirus->Turn off Windows Defender Antivirus.


was (Author: ebakke):
Are people on Windows 10 observing this behavior _always_, or just sometimes? A 
quick check shows NetBeans 10 using 0% on my own Windows 10 setup.

For troubleshooting purposes, it might be worth trying to turn of Windows 
Defender's background scan, and seeing if the problem persists. I've got it 
permanently disabled myself, for unrelated reasons (it makes Windows Subsystem 
for Linux unbearably slow), but it's probably not something we can recommend.

To turn of Windows Defender's background scan, go into the "Edit Group Policy" 
app and then set Computer Configuration->Administrative Templates->Windows 
Components->Windows Defender Antivirus->Turn off Windows Defender Antivirus.

> Excessive CPU usage
> ---
>
> Key: NETBEANS-416
> URL: https://issues.apache.org/jira/browse/NETBEANS-416
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance
>Affects Versions: 8.2, 9.0
> Environment: Windows 10 Pro 64bit
>Reporter: Acs
>Priority: Major
> Attachments: 2018-02-22 14_34_52-Task Manager.png, 
> netbeans_30_cpu_usage.png, netbeans_9.0_plugins.png, profile_9.0.npss, 
> profiler_window.png, selfsampler.npss
>
>
> Hey,
> Something I have noticed in Netbeans is that from time to time Netbeans CPU 
> usage will go up to around 20% and most of the times I have Netbeans in the 
> background so I am not doing anything in Netbeans.
> Please fix this as this is a huge annoyance.
> Edit: To further explain why this is a huge annoyance: Netbeans will trigger 
> my laptop fans with the usage of CPU when it's not doing anything.
> Please someone analyze the profiler and tell me if I have a plugin that is 
> doing this or this is netbeans.
> I am really considering changing IDEs because of t his.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-416) Excessive CPU usage

2019-01-07 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-416:
--

Are people on Windows 10 observing this behavior _always_, or just sometimes? A 
quick check shows NetBeans using 0% on my own Windows 10 setup.

For troubleshooting purposes, it might be worth trying to turn of Windows 
Defender's background scan, and seeing if the problem persists. I've got it 
permanently disabled myself, for unrelated reasons (it makes Windows Subsystem 
for Linux unbearably slow), but it's probably not something we can recommend.

To turn of Windows Defender's background scan, go into the "Edit Group Policy" 
app and then set Computer Configuration->Administrative Templates->Windows 
Components->Windows Defender Antivirus->Turn off Windows Defender Antivirus.

> Excessive CPU usage
> ---
>
> Key: NETBEANS-416
> URL: https://issues.apache.org/jira/browse/NETBEANS-416
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance
>Affects Versions: 8.2, 9.0
> Environment: Windows 10 Pro 64bit
>Reporter: Acs
>Priority: Major
> Attachments: 2018-02-22 14_34_52-Task Manager.png, 
> netbeans_30_cpu_usage.png, netbeans_9.0_plugins.png, profile_9.0.npss, 
> profiler_window.png, selfsampler.npss
>
>
> Hey,
> Something I have noticed in Netbeans is that from time to time Netbeans CPU 
> usage will go up to around 20% and most of the times I have Netbeans in the 
> background so I am not doing anything in Netbeans.
> Please fix this as this is a huge annoyance.
> Edit: To further explain why this is a huge annoyance: Netbeans will trigger 
> my laptop fans with the usage of CPU when it's not doing anything.
> Please someone analyze the profiler and tell me if I have a plugin that is 
> doing this or this is netbeans.
> I am really considering changing IDEs because of t his.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-467) maven artifacts for Apache NetBeans Platform need to be created and hosted

2018-12-28 Thread Eirik Bakke (JIRA)



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

Eirik Bakke edited comment on NETBEANS-467 at 12/28/18 11:59 PM:
-

In case it's of help to anyone, here's the Windows BAT file I used to build 
Maven artifacts for my own platform application (after first checking out the 
9.0-vc3 tag of the incubator-netbeans repository to the current directory):
{code:java}
echo on
set JAVA_HOME=C:\Program Files\Java\zulu-8.0.181
call ant
call mvn org.codehaus.mojo:nb-repository-plugin:1.4-mybuild:download 
-DnexusIndexDirectory=..\nbrepoidx 
-DrepositoryUrl=https://repo.maven.apache.org/maven2
call ant build-nbms
call ant build-source-zips
call ant build-javadoc
call mvn org.codehaus.mojo:nb-repository-plugin:1.4-mybuild:populate 
-DnexusIndexDirectory=..\nbrepoidx -DforcedVersion=RELEASE90VC3MYBUILD 
-DnetbeansInstallDirectory=nbbuild\netbeans -DnetbeansNbmDirectory=nbbuild\nbms 
-DnetbeansSourcesDirectory=nbbuild\build\source-zips 
-DnetbeansJavadocDirectory=nbbuild\build\javadoc{code}
 
Update on 2018-12-29: In the instructions above, I forgot to mention one thing: 
at some point, before running the above script, I had to clone the sources to 
nb-repository-plugin and build the latter myself. The official 
nb-repository-plugin is now at 
https://github.com/apache/incubator-netbeans-mavenutils . (I've changed the 
plugin version string in the instructions above to "1.4-mybuild" instead of 
"1.4" to show that I'm referring to a home-built version. You can set your own 
version string by editing the top-level "version" element in 
incubator-netbeans-mavenutils/nb-repository-plugins/pom.xml .)



was (Author: ebakke):
In case it's of help to anyone, here's the Windows BAT file I used to build 
Maven artifacts for my own platform application (after first checking out the 
9.0-vc3 tag of the incubator-netbeans repository to the current directory):
{code:java}
echo on
set JAVA_HOME=C:\Program Files\Java\zulu-8.0.181
call ant
call mvn org.codehaus.mojo:nb-repository-plugin:1.4:download 
-DnexusIndexDirectory=..\nbrepoidx 
-DrepositoryUrl=https://repo.maven.apache.org/maven2
call ant build-nbms
call ant build-source-zips
call ant build-javadoc
call mvn org.codehaus.mojo:nb-repository-plugin:1.4:populate 
-DnexusIndexDirectory=..\nbrepoidx -DforcedVersion=RELEASE90VC3MYBUILD 
-DnetbeansInstallDirectory=nbbuild\netbeans -DnetbeansNbmDirectory=nbbuild\nbms 
-DnetbeansSourcesDirectory=nbbuild\build\source-zips 
-DnetbeansJavadocDirectory=nbbuild\build\javadoc{code}
 

> maven artifacts for Apache NetBeans Platform  need to be created and hosted
> ---
>
> Key: NETBEANS-467
> URL: https://issues.apache.org/jira/browse/NETBEANS-467
> Project: NetBeans
>  Issue Type: Task
>  Components: website
>Affects Versions: 9.0
>Reporter: Eric Barboni
>Priority: Critical
>  Labels: NETBEANS-9
>
> Hi (hope I did not miss mails on this topic),
>  During test on maven NetCAT, testers are told to create and generate 
> mavenized NetBeans Platform Module and Suite.
>  Maven archetype for Netbeans platform module [1] are linked to artefacts 
> stored in  [2] (RELEASE 6 to 8.2) and it is also possible to use snapshot 
> versions from [3]
> Artefacts are generated from Oracle NetBeans sources at the moment, RELEASE* 
> artefact were built from a specific build, SNAPSHOT artefact are refreshed 
> every day with no history (I suppose for space reason).
>  
> It would be nice to recreate a workflow to  regenerate maven artefacts for 
> the Apache NetBeans Platform from Apache NetBeans sources.
>  
> [1][https://github.com/mojohaus/nbm-archetype/]
> [2][https://bits.netbeans.org/nexus]
> [3][https://bits.netbeans.org/dev/maven-snapshot/|http://bits.netbeans.org/dev/maven-snapshot/]
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1260) HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF

2018-09-17 Thread Eirik Bakke (JIRA)

Eirik Bakke created NETBEANS-1260:
-

 Summary: HiDPI icons in tabcontrol and openide.awt modules for 
Aqua (MacOS) LAF
 Key: NETBEANS-1260
 URL: https://issues.apache.org/jira/browse/NETBEANS-1260
 Project: NetBeans
  Issue Type: Bug
  Components: platform - Window System
Affects Versions: 9.0
 Environment: MacOS
Reporter: Eirik Bakke


To look good on MacBook Pro and other Apple computers with Retina screens, the 
various icons that are part of NetBeans' window system must be made available 
in both 100% and 200% sizes. This includes, for instance, the "X" button that 
is used to close tabs, the "_" button that collapses a sidebar, or the ">>" 
button that shows hidden toolbar icons. These icons reside in the tabcontrol 
and openide.awt modules.

I'll soon submit a pull request that fixes this by providing vectorized 
versions of the relevant window system icons. The approach is the same as is 
taken for the Windows LAF, in NETBEANS-1238.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1261) Thin grey line under active tab on MacOS retina screens

2018-09-17 Thread Eirik Bakke (JIRA)

Eirik Bakke created NETBEANS-1261:
-

 Summary: Thin grey line under active tab on MacOS retina screens
 Key: NETBEANS-1261
 URL: https://issues.apache.org/jira/browse/NETBEANS-1261
 Project: NetBeans
  Issue Type: Bug
  Components: platform - Window System
Affects Versions: 9.0
 Environment: MacOS with Retina display
Reporter: Eirik Bakke
 Attachments: Thin grey line.png

There is a small rendering artifact, visible on retina screens (e.g. MacBook 
Pro) on the Aqua LAF, under the active TopComponent tab--a thin grey line that 
should not be there. See the attached screenshot. I'll submit a patch fixing 
this after making sure it doesn't cause other problems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1249) Excessive spacing between menu items on Windows LAF

2018-09-13 Thread Eirik Bakke (JIRA)

Eirik Bakke created NETBEANS-1249:
-

 Summary: Excessive spacing between menu items on Windows LAF
 Key: NETBEANS-1249
 URL: https://issues.apache.org/jira/browse/NETBEANS-1249
 Project: NetBeans
  Issue Type: Bug
  Components: platform - Other
Affects Versions: 9.0
 Environment: Windows 10, Java 9 or 10.
Reporter: Eirik Bakke


The default insets for JMenuItem are too large in the vertical direction on the 
Windows Look & Feel, compared to those of native applications (e.g. Notepad). 
This max menus unnecessarily tall, and taller than those of native applications 
with the same number of items.

I'll submit a screenshot and a pull request fixing this shortly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1249) Excessive spacing between menu items on Windows LAF

2018-09-13 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1249:
--
Attachment: NETBEANS-1249 NetBeans Menu Spacing Fix.png

> Excessive spacing between menu items on Windows LAF
> ---
>
> Key: NETBEANS-1249
> URL: https://issues.apache.org/jira/browse/NETBEANS-1249
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Other
>Affects Versions: 9.0
> Environment: Windows 10, Java 9 or 10.
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: NETBEANS-1249 NetBeans Menu Spacing Fix.png
>
>
> The default insets for JMenuItem are too large in the vertical direction on 
> the Windows Look & Feel, compared to those of native applications (e.g. 
> Notepad). This max menus unnecessarily tall, and taller than those of native 
> applications with the same number of items.
> I'll submit a screenshot and a pull request fixing this shortly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1261) Thin grey line under active tab on MacOS retina screens

2018-09-18 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1261:
--
Attachment: (was: Thin grey line.png)

> Thin grey line under active tab on MacOS retina screens
> ---
>
> Key: NETBEANS-1261
> URL: https://issues.apache.org/jira/browse/NETBEANS-1261
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS with Retina display
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: pull-request-available
> Attachments: Thin grey line fixed.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There is a small rendering artifact, visible on retina screens (e.g. MacBook 
> Pro) on the Aqua LAF, under the active TopComponent tab--a thin grey line 
> that should not be there. See the attached screenshot. I'll submit a patch 
> fixing this after making sure it doesn't cause other problems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1261) Thin grey line under active tab on MacOS retina screens

2018-09-18 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1261:
--
Attachment: Thin grey line fixed.png

> Thin grey line under active tab on MacOS retina screens
> ---
>
> Key: NETBEANS-1261
> URL: https://issues.apache.org/jira/browse/NETBEANS-1261
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS with Retina display
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: pull-request-available
> Attachments: Thin grey line fixed.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There is a small rendering artifact, visible on retina screens (e.g. MacBook 
> Pro) on the Aqua LAF, under the active TopComponent tab--a thin grey line 
> that should not be there. See the attached screenshot. I'll submit a patch 
> fixing this after making sure it doesn't cause other problems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-67) Replace Java SplashScreen with a custom window.

2018-09-11 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-67:

Labels: HiDPI MultiMonitor  (was: MultiMonitor)

> Replace Java SplashScreen with a custom window.
> ---
>
> Key: NETBEANS-67
> URL: https://issues.apache.org/jira/browse/NETBEANS-67
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Reporter: Laszlo Kishalmi
>Priority: Minor
>  Labels: HiDPI, MultiMonitor
> Attachments: NetBeans_SplashScreen.png, blanksplash.png
>
>
> Unfortunately the Java SplashScreen feature is not well maintained. It looks 
> really odd on Linux multi-monitor displays trying to arrange the screen on 
> the middle of the two monitors. I think the intention of this Java feature 
> was to create prompt response to the user on opening a Java application. Well 
>  disk and hardware get quicker and Java get leaner on load (with Java 9). 
> This feature could be replaced by using a custom window instead.
> This would improve on two things:
> - Placement of the Splash Screen could be really multi-monitor aware
> - There is a flicker on startup for those who are upgrading from dev/release 
> candidate to final release. The first image says developer version then it 
> updates to release
> I'm trying to work something out. Though there is some chance to have some 
> interference with the platform branding.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1227) Mark Windows launcher binary as per-monitor DPI aware

2018-09-11 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1227:
--
Labels: HiDPI  (was: )

> Mark Windows launcher binary as per-monitor DPI aware
> -
>
> Key: NETBEANS-1227
> URL: https://issues.apache.org/jira/browse/NETBEANS-1227
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 9.0
> Environment: Windows 8.1 and Windows 10
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
>
> As of Java 10.0.2, support for HiDPI monitors on Windows is quite good. All 
> the standard Swing components appear in high resolution, and Graphics2D 
> surfaces are automatically scaled appropriately for whichever monitor their 
> containing window is located on, including when windows are dragged between 
> monitors in a mixed-DPI multi-monitor setting.
> For this to work, however, the EXE file that launches NetBeans must contain a 
> manifest that declares the application to be DPI-aware. Such a manifest 
> currently exists in java.exe and javaw.exe, but not in the custom 
> netbeans64.exe launcher. A workaround for the missing manifest is to right 
> click the "bin\netbeans64.exe" file, or whichever shortcut is being used to 
> open NetBeans, go to the "Compatibility" tab, click "Change high DPI 
> settings", "Override high DPI scaling behavior", and select scaling performed 
> by "Application".
> An appropriate manifest should be added to netbeans64.exe to declare NetBeans 
> as per-monitor DPI aware.
> To see how the manifest should be declared, we can dump the manifest of 
> javaw.exe:
>  {code:xml}
> 
>  xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
>   processorArchitecture="X86" type="win32"/>
>  Java(TM) SE process
>  
>  
>   xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings;>
>  true/PM
>  
>  
>  
> 
> {code}
> This reveals that Java 10.0.2 considers itself DPI-aware at the "Per Monitor 
> V1" level (see the Microsoft documentation linked below). The NetBeans 
> launcher binary should declare the same.
> References:
> [https://docs.microsoft.com/en-us/windows/desktop/hidpi/high-dpi-desktop-application-development-on-windows]
> [https://msdn.microsoft.com/en-us/library/windows/desktop/mt846517(v=vs.85).aspx]
> [https://docs.microsoft.com/en-us/windows/desktop/sbscs/application-manifests]
> [https://blogs.msdn.microsoft.com/mithuns/2009/12/16/random-how-to-quickly-view-a-binarys-embedded-manifest]
> [https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-378) Font size and splash panel on a high-DPI display on Windows 10.

2018-09-11 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-378:
-
Labels: HiDPI  (was: )

> Font size and splash panel on a high-DPI display on Windows 10.
> ---
>
> Key: NETBEANS-378
> URL: https://issues.apache.org/jira/browse/NETBEANS-378
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - UI
>Reporter: Giulio D'Ambrosi
>Priority: Major
>  Labels: HiDPI
> Attachments: Installer.PNG, Screenshot_Idea.png, 
> Screenshot_Netbeans.png, Screenshot_Netbeans_Fontsize24.png, keymap.PNG, 
> plugins.PNG, tab.PNG
>
>
> I started using NetBeans with the 4K resolution and i cannot see anything 
> because everything on that JFrame becomes too small and I won't be able to 
> read anything.
> See attached images



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-426) png file not viewed in scale in retina display

2018-09-11 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-426:
-
Labels: HiDPI  (was: )

> png file not viewed in scale in retina display
> --
>
> Key: NETBEANS-426
> URL: https://issues.apache.org/jira/browse/NETBEANS-426
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - UI
>Affects Versions: 8.2
>Reporter: Peter
>Priority: Major
>  Labels: HiDPI
> Attachments: icon is not one-to-one in scale if in retina.png
>
>
> png file not viewed in scale in retina display



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1238) HiDPI icons in tabcontrol and openide.awt modules for Windows LAF

2018-09-11 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1238:
--
Description: 
On Windows 10, each monitor may be configured with an arbitrary scaling factor, 
such as 125%, 150%, 200%, or even 300%. For instance, high-density laptop 
displays are typically set to a scaling of 200% by default. On Java 9 and 10, 
Swing handles this "HiDPI" scaling automatically, making the UI take up more 
pixels without looking smaller, and without any changes in the client 
application. This makes bitmap icons blurry or ragged, however.

To look good on HiDPI displays on Windows 10, 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, the "_" 
button that collapses a sidebar, or the ">>" button that shows hidden toolbar 
icons. These icons reside in the tabcontrol and openide.awt modules.


  was:
On Windows 10, each monitor may be configured with an arbitrary scaling factor, 
such as 125%, 150%, 200%, or even 300%. For instance, high-density laptop 
displays are typically set to a scaling of 200% by default. On Java 9 and 10, 
Swing handles this "HiDPI" scaling automatically, making the UI take up more 
pixels without looking smaller, and without any changes in the client 
application. This makes bitmap icons blurry or ragged, however.

To look good on HiDPI displays on Windows 10, 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, the "_" 
button that collapses a sidebar, or the ">>" button that shows hidden toolbar 
icons.



> HiDPI icons in tabcontrol and openide.awt modules for Windows LAF
> -
>
> Key: NETBEANS-1238
> URL: https://issues.apache.org/jira/browse/NETBEANS-1238
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: Windows 8.1 and Windows 10 with high-density displays or 
> accessibility scaling
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
>
> On Windows 10, each monitor may be configured with an arbitrary scaling 
> factor, such as 125%, 150%, 200%, or even 300%. For instance, high-density 
> laptop displays are typically set to a scaling of 200% by default. On Java 9 
> and 10, Swing handles this "HiDPI" scaling automatically, making the UI take 
> up more pixels without looking smaller, and without any changes in the client 
> application. This makes bitmap icons blurry or ragged, however.
> To look good on HiDPI displays on Windows 10, 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, the 
> "_" button that collapses a sidebar, or the ">>" button that shows hidden 
> toolbar icons. These icons reside in the tabcontrol and openide.awt modules.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-743) Add a new option to the option screen to choose the scaling setting for hidpi monitors

2018-09-11 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-743:
-
Labels: HiDPI  (was: )

> Add a new option to the option screen to choose the scaling setting for hidpi 
> monitors
> --
>
> Key: NETBEANS-743
> URL: https://issues.apache.org/jira/browse/NETBEANS-743
> Project: NetBeans
>  Issue Type: Improvement
>Reporter: Peter Steele
>Priority: Major
>  Labels: HiDPI
>
> In java > 9 you can use
> -J-Dsun.java2d.uiScale=2.5
> To choose the scaling required. It would be good to have this as a changeable 
> setting or alternatively to use the OS scaling value.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1238) HiDPI icons in tabcontrol and openide.awt modules for Windows LAF

2018-09-11 Thread Eirik Bakke (JIRA)

Eirik Bakke created NETBEANS-1238:
-

 Summary: HiDPI icons in tabcontrol and openide.awt modules for 
Windows LAF
 Key: NETBEANS-1238
 URL: https://issues.apache.org/jira/browse/NETBEANS-1238
 Project: NetBeans
  Issue Type: Bug
  Components: platform - Window System
Affects Versions: 9.0
 Environment: Windows 8.1 and Windows 10 with high-density displays or 
accessibility scaling
Reporter: Eirik Bakke


On Windows 10, each monitor may be configured with an arbitrary scaling factor, 
such as 125%, 150%, 200%, or even 300%. For instance, high-density laptop 
displays are typically set to a scaling of 200% by default. On Java 9 and 10, 
Swing handles this "HiDPI" scaling automatically, making the UI take up more 
pixels without looking smaller, and without any changes in the client 
application. This makes bitmap icons blurry or ragged, however.

To look good on HiDPI displays on Windows 10, 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, the "_" 
button that collapses a sidebar, or the ">>" button that shows hidden toolbar 
icons.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1238) HiDPI icons in tabcontrol and openide.awt modules for Windows LAF

2018-09-11 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1238:
--
Attachment: NETBEANS-1238 Before patch.png
NETBEANS-1238 After patch.png

> HiDPI icons in tabcontrol and openide.awt modules for Windows LAF
> -
>
> Key: NETBEANS-1238
> URL: https://issues.apache.org/jira/browse/NETBEANS-1238
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: Windows 8.1 and Windows 10 with high-density displays or 
> accessibility scaling
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: NETBEANS-1238 After patch.png, NETBEANS-1238 Before 
> patch.png, VectorIconTester output.png
>
>
> On Windows 10, each monitor may be configured with an arbitrary scaling 
> factor, such as 125%, 150%, 200%, or even 300%. For instance, high-density 
> laptop displays are typically set to a scaling of 200% by default. On Java 9 
> and 10, Swing handles this "HiDPI" scaling automatically, making the UI take 
> up more pixels without looking smaller, and without any changes in the client 
> application. This makes bitmap icons blurry or ragged, however.
> To look good on HiDPI displays on Windows 10, 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, the 
> "_" button that collapses a sidebar, or the ">>" button that shows hidden 
> toolbar icons. These icons reside in the tabcontrol and openide.awt modules.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-952) JDK9-64Bit is not detected currectkly by harness

2018-09-18 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-952:
--

There was a similar bug on on the maven side (this issue is marked with Ant), 
fixed here https://github.com/mojohaus/nbm-maven-plugin/pull/46 .

> JDK9-64Bit is not detected currectkly by harness
> 
>
> Key: NETBEANS-952
> URL: https://issues.apache.org/jira/browse/NETBEANS-952
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Harness, debugger - Ant
>Affects Versions: 9.0
>Reporter: Jens Hofschröer
>Priority: Minor
>  Labels: windows
>
> When starting to debug an Apache Netbeans Platform Application with a JDK9+ 
> Runtime (on windows?) the 32-bit version of the nbexec is used to start the 
> application. Since (nearly) all builds of Java9+ on Windows are 64-Bit only 
> the current detection of 32 or 64 Bit JRE is not working. There is no "jre" 
> folder is a JDK 9+
> {{}}
> {{}}
> {{    }}
> {{}}
> The result of this is, that no ouput from the application is shown in the 
> output window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1260) HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF

2018-09-18 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1260:
--
Attachment: VectorIconTest Output with Aqua and Windows vector icons.png

> HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF
> --
>
> Key: NETBEANS-1260
> URL: https://issues.apache.org/jira/browse/NETBEANS-1260
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: NETBEANS-1260 MacOS Retina After Patch.png, 
> NETBEANS-1260 MacOS Retina Before Patch.png, VectorIconTest Output with Aqua 
> and Windows vector icons.png
>
>
> To look good on MacBook Pro and other Apple computers with Retina screens, 
> the various icons that are part of NetBeans' window system must be made 
> available in both 100% and 200% sizes. This includes, for instance, the "X" 
> button that is used to close tabs, the "_" button that collapses a sidebar, 
> or the ">>" button that shows hidden toolbar icons. These icons reside in the 
> tabcontrol and openide.awt modules.
> I'll soon submit a pull request that fixes this by providing vectorized 
> versions of the relevant window system icons. The approach is the same as is 
> taken for the Windows LAF, in NETBEANS-1238.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1260) HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF

2018-09-18 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1260:
--
Attachment: NETBEANS-1260 MacOS Retina Before Patch.png
NETBEANS-1260 MacOS Retina After Patch.png

> HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF
> --
>
> Key: NETBEANS-1260
> URL: https://issues.apache.org/jira/browse/NETBEANS-1260
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: NETBEANS-1260 MacOS Retina After Patch.png, 
> NETBEANS-1260 MacOS Retina Before Patch.png
>
>
> To look good on MacBook Pro and other Apple computers with Retina screens, 
> the various icons that are part of NetBeans' window system must be made 
> available in both 100% and 200% sizes. This includes, for instance, the "X" 
> button that is used to close tabs, the "_" button that collapses a sidebar, 
> or the ">>" button that shows hidden toolbar icons. These icons reside in the 
> tabcontrol and openide.awt modules.
> I'll soon submit a pull request that fixes this by providing vectorized 
> versions of the relevant window system icons. The approach is the same as is 
> taken for the Windows LAF, in NETBEANS-1238.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1227) Mark Windows launcher binary as per-monitor DPI aware

2018-09-13 Thread Eirik Bakke (JIRA)



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

Eirik Bakke edited comment on NETBEANS-1227 at 9/13/18 3:51 PM:


The manifest in Java 11 is updated to mark Java as having "PerMonitorV2" 
support. This fixes another issue where title bars would appear too small or 
too large in a multi-monitor setup involving one HiDPI screen; see 
https://bugs.openjdk.java.net/browse/JDK-8199627 . The NetBeans IDE and 
Platform launchers should do the same. It wouldn't hurt to include the 
"compatibility" section of the manifest as well, to tell Windows explicitly 
that Java (and by extension, NetBeans) supports Windows 8.1, Windows 10 etc. 
Here are the relevant sections from javaw.exe in JDK 11ea:

{code:xml}
  
http://schemas.microsoft.com/SMI/2005/WindowsSettings; 
xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings;>
  true/PM
  PerMonitorV2, PerMonitor, system

  
  

  
  
  
  
  

  
{code}



was (Author: ebakke):
The manifest in Java 11 is updated to mark Java as having "PerMonitorV2" 
support. See https://bugs.openjdk.java.net/browse/JDK-8199627 . The NetBeans 
IDE and Platform launchers should do the same. It wouldn't hurt to include the 
"compatibility" section of the manifest as well, to tell Windows explicitly 
that Java (and by extension, NetBeans) supports Windows 8.1, Windows 10 etc. 
Here are the relevant sections from javaw.exe in JDK 11ea:

{code:xml}
  
http://schemas.microsoft.com/SMI/2005/WindowsSettings; 
xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings;>
  true/PM
  PerMonitorV2, PerMonitor, system

  
  

  
  
  
  
  

  
{code}


> Mark Windows launcher binary as per-monitor DPI aware
> -
>
> Key: NETBEANS-1227
> URL: https://issues.apache.org/jira/browse/NETBEANS-1227
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 9.0
> Environment: Windows 8.1 and Windows 10
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
>
> As of Java 10.0.2, support for HiDPI monitors on Windows is quite good. All 
> the standard Swing components appear in high resolution, and Graphics2D 
> surfaces are automatically scaled appropriately for whichever monitor their 
> containing window is located on, including when windows are dragged between 
> monitors in a mixed-DPI multi-monitor setting.
> For this to work, however, the EXE file that launches NetBeans must contain a 
> manifest that declares the application to be DPI-aware. Such a manifest 
> currently exists in java.exe and javaw.exe, but not in the custom 
> netbeans64.exe launcher. A workaround for the missing manifest is to right 
> click the "bin\netbeans64.exe" file, or whichever shortcut is being used to 
> open NetBeans, go to the "Compatibility" tab, click "Change high DPI 
> settings", "Override high DPI scaling behavior", and select scaling performed 
> by "Application".
> An appropriate manifest should be added to netbeans64.exe to declare NetBeans 
> as per-monitor DPI aware.
> To see how the manifest should be declared, we can dump the manifest of 
> javaw.exe:
>  {code:xml}
> 
>  xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
>   processorArchitecture="X86" type="win32"/>
>  Java(TM) SE process
>  
>  
>   xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings;>
>  true/PM
>  
>  
>  
> 
> {code}
> This reveals that Java 10.0.2 considers itself DPI-aware at the "Per Monitor 
> V1" level (see the Microsoft documentation linked below). The NetBeans 
> launcher binary should declare the same.
> References:
> [https://docs.microsoft.com/en-us/windows/desktop/hidpi/high-dpi-desktop-application-development-on-windows]
> [https://msdn.microsoft.com/en-us/library/windows/desktop/mt846517(v=vs.85).aspx]
> [https://docs.microsoft.com/en-us/windows/desktop/sbscs/application-manifests]
> [https://blogs.msdn.microsoft.com/mithuns/2009/12/16/random-how-to-quickly-view-a-binarys-embedded-manifest]
> [https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1227) Mark Windows launcher binary as per-monitor DPI aware

2018-09-13 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-1227:
---

The manifest in Java 11 is updated to mark Java as having "PerMonitorV2" 
support. See https://bugs.openjdk.java.net/browse/JDK-8199627 . The NetBeans 
IDE and Platform launchers should do the same. It wouldn't hurt to include the 
"compatibility" section of the manifest as well, to tell Windows explicitly 
that Java (and by extension, NetBeans) supports Windows 8.1, Windows 10 etc. 
Here are the relevant sections from javaw.exe in JDK 11ea:

{code:xml}
  
http://schemas.microsoft.com/SMI/2005/WindowsSettings; 
xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings;>
  true/PM
  PerMonitorV2, PerMonitor, system

  
  

  
  
  
  
  

  
{code}


> Mark Windows launcher binary as per-monitor DPI aware
> -
>
> Key: NETBEANS-1227
> URL: https://issues.apache.org/jira/browse/NETBEANS-1227
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 9.0
> Environment: Windows 8.1 and Windows 10
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
>
> As of Java 10.0.2, support for HiDPI monitors on Windows is quite good. All 
> the standard Swing components appear in high resolution, and Graphics2D 
> surfaces are automatically scaled appropriately for whichever monitor their 
> containing window is located on, including when windows are dragged between 
> monitors in a mixed-DPI multi-monitor setting.
> For this to work, however, the EXE file that launches NetBeans must contain a 
> manifest that declares the application to be DPI-aware. Such a manifest 
> currently exists in java.exe and javaw.exe, but not in the custom 
> netbeans64.exe launcher. A workaround for the missing manifest is to right 
> click the "bin\netbeans64.exe" file, or whichever shortcut is being used to 
> open NetBeans, go to the "Compatibility" tab, click "Change high DPI 
> settings", "Override high DPI scaling behavior", and select scaling performed 
> by "Application".
> An appropriate manifest should be added to netbeans64.exe to declare NetBeans 
> as per-monitor DPI aware.
> To see how the manifest should be declared, we can dump the manifest of 
> javaw.exe:
>  {code:xml}
> 
>  xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
>   processorArchitecture="X86" type="win32"/>
>  Java(TM) SE process
>  
>  
>   xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings;>
>  true/PM
>  
>  
>  
> 
> {code}
> This reveals that Java 10.0.2 considers itself DPI-aware at the "Per Monitor 
> V1" level (see the Microsoft documentation linked below). The NetBeans 
> launcher binary should declare the same.
> References:
> [https://docs.microsoft.com/en-us/windows/desktop/hidpi/high-dpi-desktop-application-development-on-windows]
> [https://msdn.microsoft.com/en-us/library/windows/desktop/mt846517(v=vs.85).aspx]
> [https://docs.microsoft.com/en-us/windows/desktop/sbscs/application-manifests]
> [https://blogs.msdn.microsoft.com/mithuns/2009/12/16/random-how-to-quickly-view-a-binarys-embedded-manifest]
> [https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1901) Display bug on a space followed by a tab

2019-03-20 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-1901:
---

I can reproduce it on Windows 10 on NetBeans 10.0 (Java 11.0.1). (I just pasted 
the example into a Java file.) Not sure why it happens, though.

> Display bug on a space followed by a tab
> 
>
> Key: NETBEANS-1901
> URL: https://issues.apache.org/jira/browse/NETBEANS-1901
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Painting  Printing
>Affects Versions: 10.0
> Environment: MacOS Mojave, Netbeans 10, iMac 5k, PHP7.1
>Reporter: Admeen
>Priority: Minor
>  Labels: editor, formatting
> Attachments: 20190319_actual_result.png, 20190319_example_code.php, 
> 20190319_expected_result.png, 20190320_syntax_settings.png, 
> editor_bug_space_tab.png, formatting_settings.png, netbeans-1901-jy-01.png, 
> netbeans-1901-jy-02.png
>
>
> There appears to be a bug in the editor when a space is followed by a tab. 
> The editor does not display the space and tab, but the space and tab 
> characters are present in the file.
> The editor / code formatting does not appear to be functioning correctly here.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-49) Please add smooth scrolling

2019-04-05 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-49:
-

If you want you can Skype me (username eirikbakke--you'll reach me eventually) 
from a computer where you are observing the problems, and you can share your 
screen so I can better understand what the problem is.

> Please add smooth scrolling 
> 
>
> Key: NETBEANS-49
> URL: https://issues.apache.org/jira/browse/NETBEANS-49
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Window System
>Reporter: Christian Lenz
>Priority: Major
>  Labels: pull-request-available
> Fix For: 10.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Inside the editor, when I scroll with my touchpad to the bottom, it jumps 9 
> lines to the next, this is a lot. I don't like such gappings I would like to 
> have a smooth stepless scrolling, like in chrome or other windows native 
> apps. Please add this for horizontal and vertical scrolling, it will be much 
> better. Not only in editors, it should be available everywhere, where we have 
> scrollbars.
> Regards
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1261) Thin grey line under active tab on MacOS retina screens

2019-04-05 Thread Eirik Bakke (JIRA)



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

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

> Thin grey line under active tab on MacOS retina screens
> ---
>
> Key: NETBEANS-1261
> URL: https://issues.apache.org/jira/browse/NETBEANS-1261
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS with Retina display
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: HiDPI, pull-request-available
> Fix For: 10.0
>
> Attachments: Thin grey line fixed.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> There is a small rendering artifact, visible on retina screens (e.g. MacBook 
> Pro) on the Aqua LAF, under the active TopComponent tab--a thin grey line 
> that should not be there. See the attached screenshot. I'll submit a patch 
> fixing this after making sure it doesn't cause other problems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-2360) HiDPI scaling not applied automatically on Linux

2019-04-07 Thread Eirik Bakke (JIRA)

Eirik Bakke created NETBEANS-2360:
-

 Summary: HiDPI scaling not applied automatically on Linux
 Key: NETBEANS-2360
 URL: https://issues.apache.org/jira/browse/NETBEANS-2360
 Project: NetBeans
  Issue Type: Improvement
  Components: platform - LaunchersCLI
Affects Versions: 11.0
 Environment: Kubuntu 18.03
Oracle JDK 11.0.2
Reporter: Eirik Bakke
 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 GTK_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
(v7.6.3#76005)

-
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-1260) HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF

2019-03-17 Thread Eirik Bakke (JIRA)



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

Eirik Bakke resolved NETBEANS-1260.
---
   Resolution: Fixed
Fix Version/s: (was: Next)
   11.0

> HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF
> --
>
> Key: NETBEANS-1260
> URL: https://issues.apache.org/jira/browse/NETBEANS-1260
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS with retina screens (e.g. MacBook Pro)
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, pull-request-available
> Fix For: 11.0
>
> Attachments: NETBEANS-1260 MacOS Retina After Patch.png, 
> NETBEANS-1260 MacOS Retina Before Patch.png, VectorIconTest Output with Aqua 
> and Windows vector icons.png
>
>
> To look good on MacBook Pro and other Apple computers with Retina screens, 
> the various icons that are part of NetBeans' window system must be made 
> available in both 100% and 200% sizes. This includes, for instance, the "X" 
> button that is used to close tabs, the "_" button that collapses a sidebar, 
> or the ">>" button that shows hidden toolbar icons. These icons reside in the 
> tabcontrol and openide.awt modules.
> I'll soon submit a pull request that fixes this by providing vectorized 
> versions of the relevant window system icons. The approach is the same as is 
> taken for the Windows LAF, in NETBEANS-1238.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1658) Switch to NIO based file access causes regression

2019-03-17 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1658:
--
Fix Version/s: 11.0

> Switch to NIO based file access causes regression
> -
>
> Key: NETBEANS-1658
> URL: https://issues.apache.org/jira/browse/NETBEANS-1658
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 9.0
>Reporter: Matthias Bläsing
>Assignee: Matthias Bläsing
>Priority: Major
> Fix For: 11.0
>
>
> With the git commit:
> [https://github.com/apache/incubator-netbeans/commit/4b82e6adb31e294c74fd2fa99779ce9e27ae6184]
> several file accesses were switched from FileInputStream to NIO based input 
> streams. These new stream differ in behavior. On Thread#interrupt the new 
> streams raise a ClosedByInterruptException. At most places this exception is 
> not handled and thus causes unexpected behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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] [Reopened] (NETBEANS-1260) HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF

2019-03-17 Thread Eirik Bakke (JIRA)



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

Eirik Bakke reopened NETBEANS-1260:
---

> HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF
> --
>
> Key: NETBEANS-1260
> URL: https://issues.apache.org/jira/browse/NETBEANS-1260
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: MacOS with retina screens (e.g. MacBook Pro)
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, pull-request-available
> Fix For: Next
>
> Attachments: NETBEANS-1260 MacOS Retina After Patch.png, 
> NETBEANS-1260 MacOS Retina Before Patch.png, VectorIconTest Output with Aqua 
> and Windows vector icons.png
>
>
> To look good on MacBook Pro and other Apple computers with Retina screens, 
> the various icons that are part of NetBeans' window system must be made 
> available in both 100% and 200% sizes. This includes, for instance, the "X" 
> button that is used to close tabs, the "_" button that collapses a sidebar, 
> or the ">>" button that shows hidden toolbar icons. These icons reside in the 
> tabcontrol and openide.awt modules.
> I'll soon submit a pull request that fixes this by providing vectorized 
> versions of the relevant window system icons. The approach is the same as is 
> taken for the Windows LAF, in NETBEANS-1238.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1238) HiDPI icons in tabcontrol and openide.awt modules for Windows LAF

2019-03-17 Thread Eirik Bakke (JIRA)



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

Eirik Bakke resolved NETBEANS-1238.
---
   Resolution: Fixed
Fix Version/s: (was: Next)
   11.0

> HiDPI icons in tabcontrol and openide.awt modules for Windows LAF
> -
>
> Key: NETBEANS-1238
> URL: https://issues.apache.org/jira/browse/NETBEANS-1238
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: Windows 8.1 and Windows 10 with high-density displays or 
> accessibility scaling
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, pull-request-available
> Fix For: 11.0
>
> Attachments: NETBEANS-1238 After patch.png, NETBEANS-1238 Before 
> patch.png, VectorIconTester output.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> On Windows 10, each monitor may be configured with an arbitrary scaling 
> factor, such as 125%, 150%, 200%, or even 300%. For instance, high-density 
> laptop displays are typically set to a scaling of 200% by default. On Java 9 
> and 10, Swing handles this "HiDPI" scaling automatically, making the UI take 
> up more pixels without looking smaller, and without any changes in the client 
> application. This makes bitmap icons blurry or ragged, however.
> To look good on HiDPI displays on Windows 10, 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, the 
> "_" button that collapses a sidebar, or the ">>" button that shows hidden 
> toolbar icons. These icons reside in the tabcontrol and openide.awt modules.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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] [Reopened] (NETBEANS-1238) HiDPI icons in tabcontrol and openide.awt modules for Windows LAF

2019-03-17 Thread Eirik Bakke (JIRA)



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

Eirik Bakke reopened NETBEANS-1238:
---

> HiDPI icons in tabcontrol and openide.awt modules for Windows LAF
> -
>
> Key: NETBEANS-1238
> URL: https://issues.apache.org/jira/browse/NETBEANS-1238
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
> Environment: Windows 8.1 and Windows 10 with high-density displays or 
> accessibility scaling
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, pull-request-available
> Fix For: Next
>
> Attachments: NETBEANS-1238 After patch.png, NETBEANS-1238 Before 
> patch.png, VectorIconTester output.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> On Windows 10, each monitor may be configured with an arbitrary scaling 
> factor, such as 125%, 150%, 200%, or even 300%. For instance, high-density 
> laptop displays are typically set to a scaling of 200% by default. On Java 9 
> and 10, Swing handles this "HiDPI" scaling automatically, making the UI take 
> up more pixels without looking smaller, and without any changes in the client 
> application. This makes bitmap icons blurry or ragged, however.
> To look good on HiDPI displays on Windows 10, 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, the 
> "_" button that collapses a sidebar, or the ">>" button that shows hidden 
> toolbar icons. These icons reside in the tabcontrol and openide.awt modules.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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] [Assigned] (NETBEANS-1586) Make ImageUtilities.createDisabledIcon work with HiDPI icons

2019-05-27 Thread Eirik Bakke (JIRA)



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

Eirik Bakke reassigned NETBEANS-1586:
-

Assignee: Eirik Bakke

> Make ImageUtilities.createDisabledIcon work with HiDPI icons
> 
>
> Key: NETBEANS-1586
> URL: https://issues.apache.org/jira/browse/NETBEANS-1586
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: Next
> Environment: Windows, Linux, MacOS
>Reporter: Eirik Bakke
>Assignee: Eirik Bakke
>Priority: Major
>  Labels: HiDPI, pull-request-available
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> After the introduction of the org.openide.util.VectorIcon class in 
> https://github.com/apache/incubator-netbeans/pull/859 , 
> ImageUtilities.createDisabledIcon should be updated to work with such 
> resolution-independent icons, as well as ImageIcon instances that delegate to 
> a MultiResolutionImage. I have a patch ready that will fix this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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] [Assigned] (NETBEANS-2604) Support SVG icon loading from ImageUtilities

2019-05-27 Thread Eirik Bakke (JIRA)



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

Eirik Bakke reassigned NETBEANS-2604:
-

Assignee: Eirik Bakke

> Support SVG icon loading from ImageUtilities
> 
>
> Key: NETBEANS-2604
> URL: https://issues.apache.org/jira/browse/NETBEANS-2604
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 11.0
> Environment: Windows, MacOS, and Linux.
>Reporter: Eirik Bakke
>Assignee: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
>
> Support SVG image loading from ImageUtilities, primarily for icons. This 
> would be implemented as a special subclass of javax.swing.Icon, rather than 
> through MultiResolutionImage. Eirik Bakke already has most of this code ready.
> Motivation: To look good on HiDPI/Retina displays, the NetBeans IDE, and 
> NetBeans Platform (RCP) applications, will eventually need to provide 
> high-resolution versions of various image asset (typically icons). Two 
> approaches are possible: (1) allow each icon to be supplied as multiple 
> bitmap (i.e. PNG) files, one for each resolution, or (2) allow each icon to 
> be supplied as a single SVG file. This issue deals with the latter approach. 
> (The multiple resolution approach is discussed in NETBEANS-1583 .)
> On Windows, arbitrary HiDPI scaling factors may be specified, such as 150%, 
> 175%, 200%, or 250%. Additionally, MultiResolutionImage does not work 
> properly on Windows due to https://bugs.openjdk.java.net/browse/JDK-8212226 . 
> Thus, I now consider the SVG approach to be the most feasible one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-2604) Support SVG icon loading from ImageUtilities

2019-05-27 Thread Eirik Bakke (JIRA)

Eirik Bakke created NETBEANS-2604:
-

 Summary: Support SVG icon loading from ImageUtilities
 Key: NETBEANS-2604
 URL: https://issues.apache.org/jira/browse/NETBEANS-2604
 Project: NetBeans
  Issue Type: Improvement
  Components: platform - Other
Affects Versions: 11.0
 Environment: Windows, MacOS, and Linux.
Reporter: Eirik Bakke


Support SVG image loading from ImageUtilities, primarily for icons. This would 
be implemented as a special subclass of javax.swing.Icon, rather than through 
MultiResolutionImage. Eirik Bakke already has most of this code ready.

Motivation: To look good on HiDPI/Retina displays, the NetBeans IDE, and 
NetBeans Platform (RCP) applications, will eventually need to provide 
high-resolution versions of various image asset (typically icons). Two 
approaches are possible: (1) allow each icon to be supplied as multiple bitmap 
(i.e. PNG) files, one for each resolution, or (2) allow each icon to be 
supplied as a single SVG file. This issue deals with the latter approach. (The 
multiple resolution approach is discussed in NETBEANS-1583 .)

On Windows, arbitrary HiDPI scaling factors may be specified, such as 150%, 
175%, 200%, or 250%. Additionally, MultiResolutionImage does not work properly 
on Windows due to https://bugs.openjdk.java.net/browse/JDK-8212226 . Thus, I 
now consider the SVG approach to be the most feasible one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-2604) Support SVG icon loading from ImageUtilities

2019-05-27 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-2604:
--
Labels: HiDPI  (was: )

> Support SVG icon loading from ImageUtilities
> 
>
> Key: NETBEANS-2604
> URL: https://issues.apache.org/jira/browse/NETBEANS-2604
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 11.0
> Environment: Windows, MacOS, and Linux.
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
>
> Support SVG image loading from ImageUtilities, primarily for icons. This 
> would be implemented as a special subclass of javax.swing.Icon, rather than 
> through MultiResolutionImage. Eirik Bakke already has most of this code ready.
> Motivation: To look good on HiDPI/Retina displays, the NetBeans IDE, and 
> NetBeans Platform (RCP) applications, will eventually need to provide 
> high-resolution versions of various image asset (typically icons). Two 
> approaches are possible: (1) allow each icon to be supplied as multiple 
> bitmap (i.e. PNG) files, one for each resolution, or (2) allow each icon to 
> be supplied as a single SVG file. This issue deals with the latter approach. 
> (The multiple resolution approach is discussed in NETBEANS-1583 .)
> On Windows, arbitrary HiDPI scaling factors may be specified, such as 150%, 
> 175%, 200%, or 250%. Additionally, MultiResolutionImage does not work 
> properly on Windows due to https://bugs.openjdk.java.net/browse/JDK-8212226 . 
> Thus, I now consider the SVG approach to be the most feasible one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1583) Support MultiResolutionImage loading from ImageUtilities

2019-05-27 Thread Eirik Bakke (JIRA)

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

The same naming convention for multi-resolution image assets should be used as
in the JDK. See Philip Race's comment on
[JDK-8151787|https://bugs.openjdk.java.net/browse/JDK-8151787] :

As part of this patch, other ImageUtilities methods such as createDisabledIcon,
createDisabledImage, and mergeImages should also be updated to support both
MultiResolutionImage and the new org.openide.util.VectorIcon class (introduced
at https://github.com/apache/incubator-netbeans/pull/859/files ). Emilian Bold
has done some work on this in the past; see
https://github.com/emilianbold/nextbeans/commit/0f99dba0c1b3e8e0bc4e7cec407b53d30e85ead1
. Eirik Bakke also has a [Pull
Request|https://github.com/apache/incubator-netbeans/pull/998] for
createDisabledIcon in particular, which works with the VectorIcon class and any
other Icon instance.

Last, note that there are two ways to create icons that look good on HiDPI
displays: either by using MultiResolutionImage, or by hand-painting vector
graphics in a custom implementation of the Icon class. This issue deals with
the MultiResolutionImage approach; the vector painting approach is supported
via the existing helper class org.openide.util.VectorIcon. Both approaches are
valid and should be supported by the NetBeans Platform. (Update on 2019-05-27:
There's a third approach, which is to supply each icon as an SVG file. That one
is probably the better approach. See
https://issues.apache.org/jira/browse/NETBEANS-2604 .)

The same naming convention for multi-resolution image assets should be used as
in the JDK. See Philip Race's comment on
[JDK-8151787|https://bugs.openjdk.java.net/browse/JDK-8151787] :

As far as I know, only MacOS currently supports the automatic loading of such
assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support
the underlying

[jira] [Commented] (NETBEANS-1583) Support MultiResolutionImage loading from ImageUtilities

2019-05-27 Thread Eirik Bakke (JIRA)



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

Eirik Bakke commented on NETBEANS-1583:
---

I have concluded that it's better to support vectorized icons via SVG; see 
https://issues.apache.org/jira/browse/NETBEANS-2604 . While the 
MultiResolutionImage approach could be nice to support as well, SVG loading 
support would make the latter lower-priority.

> Support MultiResolutionImage loading from ImageUtilities 
> -
>
> Key: NETBEANS-1583
> URL: https://issues.apache.org/jira/browse/NETBEANS-1583
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 10.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: HiDPI
>
> To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans 
> Platform (RCP) applications, will eventually need to provide high-resolution 
> versions of various image asset (typically icons). In Swing, multi-resolution 
> image assets are supported via the 
> [MultiResolutionImage|https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html]
>  class; such images are automatically loaded by methods such as 
> Toolkit.getImage based on a standard naming convention. For instance, on 
> MacOS, Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" 
> if present, returning a MultiResolutionImage (implemented in 
> [JDK-8011059|https://bugs.openjdk.java.net/browse/JDK-8011059]). NetBeans' 
> ImageUtilities.loadImage and friends should do the same.
> The same naming convention for multi-resolution image assets should be used 
> as in the JDK. See Philip Race's comment on 
> [JDK-8151787|https://bugs.openjdk.java.net/browse/JDK-8151787] :
> {quote}The proposed name convention for splash screens *and* other multi-res 
> images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
> ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
> and also because we already supported @2x on retina Mac.
> {quote}
>  
> On the naming convention, see also 
> [JDK-8090575|https://bugs.openjdk.java.net/browse/JDK-8090575]. Also make 
> sure to retain the ability to add a "_dark" suffix for dark LAFs.
> As far as I know, only MacOS currently supports the automatic loading of such 
> assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
> the underlying MultiResolutionImage class. So it's already possible to 
> implement this on the latest JDK. Note, however, that we should probably wait 
> for [JDK-8212226|https://bugs.openjdk.java.net/browse/JDK-8212226] to be 
> fixed before enabling this on Windows.
> As part of this patch, other ImageUtilities methods such as 
> createDisabledIcon, createDisabledImage, and mergeImages should also be 
> updated to support both MultiResolutionImage and the new 
> org.openide.util.VectorIcon class (introduced at 
> https://github.com/apache/incubator-netbeans/pull/859/files ). Emilian Bold 
> has done some work on this in the past; see 
> https://github.com/emilianbold/nextbeans/commit/0f99dba0c1b3e8e0bc4e7cec407b53d30e85ead1
>  . Eirik Bakke also has a [Pull 
> Request|https://github.com/apache/incubator-netbeans/pull/998] for 
> createDisabledIcon in particular, which works with the VectorIcon class and 
> any other Icon instance.
> Last, note that there are two ways to create icons that look good on HiDPI 
> displays: either by using MultiResolutionImage, or by hand-painting vector 
> graphics in a custom implementation of the Icon class. This issue deals with 
> the MultiResolutionImage approach; the vector painting approach is supported 
> via the existing helper class org.openide.util.VectorIcon. Both approaches 
> are valid and should be supported by the NetBeans Platform. (Update on 
> 2019-05-27: There's a third approach, which is to supply each icon as an SVG 
> file. That one is probably the better approach. See 
> https://issues.apache.org/jira/browse/NETBEANS-2604 .)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-1583) Support MultiResolutionImage loading from ImageUtilities

2019-05-27 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-1583:
--
Priority: Minor  (was: Major)

> Support MultiResolutionImage loading from ImageUtilities 
> -
>
> Key: NETBEANS-1583
> URL: https://issues.apache.org/jira/browse/NETBEANS-1583
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 10.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: HiDPI
>
> To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans 
> Platform (RCP) applications, will eventually need to provide high-resolution 
> versions of various image asset (typically icons). In Swing, multi-resolution 
> image assets are supported via the 
> [MultiResolutionImage|https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html]
>  class; such images are automatically loaded by methods such as 
> Toolkit.getImage based on a standard naming convention. For instance, on 
> MacOS, Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png" 
> if present, returning a MultiResolutionImage (implemented in 
> [JDK-8011059|https://bugs.openjdk.java.net/browse/JDK-8011059]). NetBeans' 
> ImageUtilities.loadImage and friends should do the same.
> The same naming convention for multi-resolution image assets should be used 
> as in the JDK. See Philip Race's comment on 
> [JDK-8151787|https://bugs.openjdk.java.net/browse/JDK-8151787] :
> {quote}The proposed name convention for splash screens *and* other multi-res 
> images is @125pct @150pct @200pct @2x @250pct @300pct @3x 
> ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively 
> and also because we already supported @2x on retina Mac.
> {quote}
>  
> On the naming convention, see also 
> [JDK-8090575|https://bugs.openjdk.java.net/browse/JDK-8090575]. Also make 
> sure to retain the ability to add a "_dark" suffix for dark LAFs.
> As far as I know, only MacOS currently supports the automatic loading of such 
> assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support 
> the underlying MultiResolutionImage class. So it's already possible to 
> implement this on the latest JDK. Note, however, that we should probably wait 
> for [JDK-8212226|https://bugs.openjdk.java.net/browse/JDK-8212226] to be 
> fixed before enabling this on Windows.
> As part of this patch, other ImageUtilities methods such as 
> createDisabledIcon, createDisabledImage, and mergeImages should also be 
> updated to support both MultiResolutionImage and the new 
> org.openide.util.VectorIcon class (introduced at 
> https://github.com/apache/incubator-netbeans/pull/859/files ). Emilian Bold 
> has done some work on this in the past; see 
> https://github.com/emilianbold/nextbeans/commit/0f99dba0c1b3e8e0bc4e7cec407b53d30e85ead1
>  . Eirik Bakke also has a [Pull 
> Request|https://github.com/apache/incubator-netbeans/pull/998] for 
> createDisabledIcon in particular, which works with the VectorIcon class and 
> any other Icon instance.
> Last, note that there are two ways to create icons that look good on HiDPI 
> displays: either by using MultiResolutionImage, or by hand-painting vector 
> graphics in a custom implementation of the Icon class. This issue deals with 
> the MultiResolutionImage approach; the vector painting approach is supported 
> via the existing helper class org.openide.util.VectorIcon. Both approaches 
> are valid and should be supported by the NetBeans Platform. (Update on 
> 2019-05-27: There's a third approach, which is to supply each icon as an SVG 
> file. That one is probably the better approach. See 
> https://issues.apache.org/jira/browse/NETBEANS-2604 .)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-2605) Prioritize icons to vectorize for HiDPI support

2019-05-27 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-2605:
--
Description: 
As part of the higher-level 
[effort|https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements]
 to support HiDPI for the NetBeans IDE and for NetBeans Platform applications, 
a commonly used subset of icons should be recreated using the scalable SVG 
format (see NETBEANS-2604).

As of 2019-05-27, there are 2740 unique files with extension 'png' or 'gif' in 
non-test sources in the NetBeans codebase's master branch. The page at 
https://people.csail.mit.edu/ebakke/misc/netbeans-icons shows all of these 
images. When there are multiple files with the same SHA256 checksum, only one 
is shown.

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 [this 
Illustrator 
template|https://people.csail.mit.edu/ebakke/misc/netbeans-icons/netbeans_icons_illustrator_template.ai]).
 Thus it's infeasible to do this for every icon in the codebase. Instead, icons 
commonly seen on the screen during a typical NetBeans IDE session should be 
prioritized.

This issue tracks the task of providing a prioritized list of icons for which 
we should try to provide SVG versions.

  was:
As part of the higher-level 
[effort|https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements]
 to support HiDPI for the NetBeans IDE and for NetBeans Platform applications, 
a commonly used subset of icons should be recreated using the scalable SVG 
format.

As of 2019-05-27, there are 2740 unique files with extension 'png' or 'gif' in 
non-test sources in the NetBeans codebase's master branch. The page at 
https://people.csail.mit.edu/ebakke/misc/netbeans-icons shows all of these 
images. When there are multiple files with the same SHA256 checksum, only one 
is shown.

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 [this 
Illustrator 
template|https://people.csail.mit.edu/ebakke/misc/netbeans-icons/netbeans_icons_illustrator_template.ai]).
 Thus it's infeasible to do this for every icon in the codebase. Instead, icons 
commonly seen on the screen during a typical NetBeans IDE session should be 
prioritized.

This issue tracks the task of providing a prioritized list of icons for which 
we should try to provide SVG versions.


> Prioritize icons to vectorize for HiDPI support
> ---
>
> Key: NETBEANS-2605
> URL: https://issues.apache.org/jira/browse/NETBEANS-2605
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 11.0
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: effort_required.png
>
>
> As part of the higher-level 
> [effort|https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements]
>  to support HiDPI for the NetBeans IDE and for NetBeans Platform 
> applications, a commonly used subset of icons should be recreated using the 
> scalable SVG format (see NETBEANS-2604).
> As of 2019-05-27, there are 2740 unique files with extension 'png' or 'gif' 
> in non-test sources in the NetBeans codebase's master branch. The page at 
> https://people.csail.mit.edu/ebakke/misc/netbeans-icons shows all of these 
> images. When there are multiple files with the same SHA256 checksum, only one 
> is shown.
> 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 
> [this Illustrator 
> template|https://people.csail.mit.edu/ebakke/misc/netbeans-icons/netbeans_icons_illustrator_template.ai]).
>  Thus it's infeasible to do this for every icon in the codebase. Instead, 
> icons commonly seen on the screen during a typical NetBeans IDE session 
> should be prioritized.
> This issue tracks the task of providing a prioritized list of icons for which 
> we should try to provide SVG versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-2605) Prioritize icons to vectorize for HiDPI support

2019-05-27 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-2605:
--
Labels: HiDPI  (was: )

> Prioritize icons to vectorize for HiDPI support
> ---
>
> Key: NETBEANS-2605
> URL: https://issues.apache.org/jira/browse/NETBEANS-2605
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 11.0
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: effort_required.png
>
>
> As part of the higher-level 
> [effort|https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements]
>  to support HiDPI for the NetBeans IDE and for NetBeans Platform 
> applications, a commonly used subset of icons should be recreated using the 
> scalable SVG format.
> As of 2019-05-27, there are 2740 unique files with extension 'png' or 'gif' 
> in non-test sources in the NetBeans codebase's master branch. The page at 
> https://people.csail.mit.edu/ebakke/misc/netbeans-icons shows all of these 
> images. When there are multiple files with the same SHA256 checksum, only one 
> is shown.
> 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 
> [this Illustrator 
> template|https://people.csail.mit.edu/ebakke/misc/netbeans-icons/netbeans_icons_illustrator_template.ai]).
>  Thus it's infeasible to do this for every icon in the codebase. Instead, 
> icons commonly seen on the screen during a typical NetBeans IDE session 
> should be prioritized.
> This issue tracks the task of providing a prioritized list of icons for which 
> we should try to provide SVG versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-2605) Prioritize icons to vectorize for HiDPI support

2019-05-27 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-2605:
--
Description: 
As part of the higher-level 
[effort|https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements]
 to support HiDPI for the NetBeans IDE and for NetBeans Platform applications, 
a commonly used subset of icons should be recreated using the scalable SVG 
format.

As of 2019-05-27, there are 2740 unique files with extension 'png' or 'gif' in 
non-test sources in the NetBeans codebase's master branch. The page at 
https://people.csail.mit.edu/ebakke/misc/netbeans-icons shows all of these 
images. When there are multiple files with the same SHA256 checksum, only one 
is shown.

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 [this 
Illustrator 
template|https://people.csail.mit.edu/ebakke/misc/netbeans-icons/netbeans_icons_illustrator_template.ai]).
 Thus it's infeasible to do this for every icon in the codebase. Instead, icons 
commonly seen on the screen during a typical NetBeans IDE session should be 
prioritized.

This issue tracks the task of providing a prioritized list of icons for which 
we should try to provide SVG versions.

  was:
As part of the higher-level 
[effort|https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements]
 to support HiDPI for the NetBeans IDE and for NetBeans Platform applications, 
a commonly used subset of icons should be recreated using the scalable SVG 
format.

As of 2019-05-27, there are 2740 unique files named '*.png' or '*.gif' in 
non-test sources in the NetBeans codebase's master branch. The page at 
https://people.csail.mit.edu/ebakke/misc/netbeans-icons shows all of these 
images. When there are multiple files with the same SHA256 checksum, only one 
is shown.

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 [this 
Illustrator 
template|https://people.csail.mit.edu/ebakke/misc/netbeans-icons/netbeans_icons_illustrator_template.ai]).
 Thus it's infeasible to do this for every icon in the codebase. Instead, icons 
commonly seen on the screen during a typical NetBeans IDE session should be 
prioritized.

This issue tracks the task of providing a prioritized list of icons for which 
we should try to provide SVG versions.


> Prioritize icons to vectorize for HiDPI support
> ---
>
> Key: NETBEANS-2605
> URL: https://issues.apache.org/jira/browse/NETBEANS-2605
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 11.0
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: effort_required.png
>
>
> As part of the higher-level 
> [effort|https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements]
>  to support HiDPI for the NetBeans IDE and for NetBeans Platform 
> applications, a commonly used subset of icons should be recreated using the 
> scalable SVG format.
> As of 2019-05-27, there are 2740 unique files with extension 'png' or 'gif' 
> in non-test sources in the NetBeans codebase's master branch. The page at 
> https://people.csail.mit.edu/ebakke/misc/netbeans-icons shows all of these 
> images. When there are multiple files with the same SHA256 checksum, only one 
> is shown.
> 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 
> [this Illustrator 
> template|https://people.csail.mit.edu/ebakke/misc/netbeans-icons/netbeans_icons_illustrator_template.ai]).
>  Thus it's infeasible to do this for every icon in the codebase. Instead, 
> icons commonly seen on the screen during a typical NetBeans IDE session 
> should be prioritized.
> This issue tracks the task of providing a prioritized list of icons for which 
> we should try to provide SVG versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-2605) Prioritize icons to vectorize for HiDPI support

2019-05-27 Thread Eirik Bakke (JIRA)

Eirik Bakke created NETBEANS-2605:
-

 Summary: Prioritize icons to vectorize for HiDPI support
 Key: NETBEANS-2605
 URL: https://issues.apache.org/jira/browse/NETBEANS-2605
 Project: NetBeans
  Issue Type: Improvement
  Components: platform - Other
Affects Versions: 11.0
Reporter: Eirik Bakke
 Attachments: effort_required.png

As part of the higher-level 
[effort|https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements]
 to support HiDPI for the NetBeans IDE and for NetBeans Platform applications, 
a commonly used subset of icons should be recreated using the scalable SVG 
format.

As of 2019-05-27, there are 2740 unique files named '*.png' or '*.gif' in 
non-test sources in the NetBeans codebase's master branch. The page at 
https://people.csail.mit.edu/ebakke/misc/netbeans-icons shows all of these 
images. When there are multiple files with the same SHA256 checksum, only one 
is shown.

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 [this 
Illustrator 
template|https://people.csail.mit.edu/ebakke/misc/netbeans-icons/netbeans_icons_illustrator_template.ai]).
 Thus it's infeasible to do this for every icon in the codebase. Instead, icons 
commonly seen on the screen during a typical NetBeans IDE session should be 
prioritized.

This issue tracks the task of providing a prioritized list of icons for which 
we should try to provide SVG versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-2605) Prioritize icons to vectorize for HiDPI support

2019-05-27 Thread Eirik Bakke (JIRA)



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

Eirik Bakke updated NETBEANS-2605:
--
Description: 
As part of the higher-level 
[effort|https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements]
 to support HiDPI for the NetBeans IDE and for NetBeans Platform applications, 
a commonly used subset of icons should be recreated using the scalable SVG 
format (see NETBEANS-2604).

As of 2019-05-27, there are 2740 unique files with extension 'png' or 'gif' in 
non-test sources in the [NetBeans codebase's master 
branch|https://github.com/apache/netbeans]. The page at 
https://people.csail.mit.edu/ebakke/misc/netbeans-icons shows all of these 
images. When there are multiple files with the same SHA256 checksum, only one 
is shown.

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 [this 
Illustrator 
template|https://people.csail.mit.edu/ebakke/misc/netbeans-icons/netbeans_icons_illustrator_template.ai]).
 Thus it's infeasible to do this for every icon in the codebase. Instead, icons 
commonly seen on the screen during a typical NetBeans IDE session should be 
prioritized.

This issue tracks the task of providing a prioritized list of icons (with file 
names) for which we should try to provide SVG versions. For example, in 
prioritized order:
# Every icon in the editor toolbar
# Every icon in the application toolbar, with default NetBeans settings.
# Icons used in the menu bar menus.
# Any other icon seen on the screen when a blank NetBeans IDE installation is 
started up.
# Icons shown in the Projects pane when working with a simple Java project.
# Icons shown in the Projects pane when working with a Java project in a git 
repository.
# etc.

  was:
As part of the higher-level 
[effort|https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements]
 to support HiDPI for the NetBeans IDE and for NetBeans Platform applications, 
a commonly used subset of icons should be recreated using the scalable SVG 
format (see NETBEANS-2604).

As of 2019-05-27, there are 2740 unique files with extension 'png' or 'gif' in 
non-test sources in the [NetBeans codebase's master 
branch|https://github.com/apache/netbeans]. The page at 
https://people.csail.mit.edu/ebakke/misc/netbeans-icons shows all of these 
images. When there are multiple files with the same SHA256 checksum, only one 
is shown.

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 [this 
Illustrator 
template|https://people.csail.mit.edu/ebakke/misc/netbeans-icons/netbeans_icons_illustrator_template.ai]).
 Thus it's infeasible to do this for every icon in the codebase. Instead, icons 
commonly seen on the screen during a typical NetBeans IDE session should be 
prioritized.

This issue tracks the task of providing a prioritized list of icons for which 
we should try to provide SVG versions.


> Prioritize icons to vectorize for HiDPI support
> ---
>
> Key: NETBEANS-2605
> URL: https://issues.apache.org/jira/browse/NETBEANS-2605
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Other
>Affects Versions: 11.0
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: HiDPI
> Attachments: effort_required.png
>
>
> As part of the higher-level 
> [effort|https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements]
>  to support HiDPI for the NetBeans IDE and for NetBeans Platform 
> applications, a commonly used subset of icons should be recreated using the 
> scalable SVG format (see NETBEANS-2604).
> As of 2019-05-27, there are 2740 unique files with extension 'png' or 'gif' 
> in non-test sources in the [NetBeans codebase's master 
> branch|https://github.com/apache/netbeans]. The page at 
> https://people.csail.mit.edu/ebakke/misc/netbeans-icons shows all of these 
> images. When there are multiple files with the same SHA256 checksum, only one 
> is shown.
> 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 
> [this Illustrator 
> template|https://people.csail.mit.edu/ebakke/misc/netbeans-icons/netbeans_icons_illustrator_template.ai]).
>  Thus it's infeasible to do this for every icon in the codebase. Instead, 
> icons commonly seen on the screen during a typical NetBeans IDE session 
> should be prioritized.
> This issue tracks the task of providing a prioritized list of icons (with 
> file names) for which we should try to provide SVG versions. For example, in 
> prioritized order:
> # Every icon in the

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

2019-06-03 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.

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, the following prioritized list of icons to convert was
produced:

https://people.csail.mit.edu/ebakke/misc/netbeans-icons/prioritized.html

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.
Note that in cases where an icon file has been copied around to various places
in the NetBeans codebase, only one of the paths is shown in the list above.

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

h2. Proposed Style Guide for Vectorized Icons
* Vector icons should be drawn in Adobe 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...)
* For each icon to be vectorized, place the old bitmap version of the icon in
the "Old Bitmap Icons" layer in Illustrator. 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. (The color scheme is not too hard to change later, but we should
do this only once most of the IDE icons have been vectorized.)
* 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.
* 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.
* 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 toolbar icons, which exist in both 16x16 and 24x24 sizes, base the vector
version on the smaller 16x16 one, which is sometimes simpler. (This is already
done in the prioritized icon list above.)

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

In NETBEANS-2605, the following prioritized list of icons to convert was
produced:

https://people.csail.mit.edu/ebakke/misc/netbeans-icons/prioritized.html

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

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

2019-05-30 Thread Eirik Bakke (JIRA)

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

In NETBEANS-2605, the following prioritized list of icons to convert was
produced:

https://people.csail.mit.edu/ebakke/misc/netbeans-icons/prioritized.html

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.

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

h2. Proposed Style Guide for Vectorized Icons
* Vector icons should be drawn in Adobe 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...)
* For each icon to be vectorized, place the old bitmap version of the icon in
the "Old Bitmap Icons" layer in Illustrator. 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. (The color scheme is not too hard to change later, but we should
do this only once most of the IDE icons have been vectorized.)
* If the old bitmap icon is complex, it is fine to simplify it a bit when
drawing vectorized versions.
* Omit gradients and unnecessary drop shadows. They take more time to draw, and
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.
* 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.
* Horizontal and vertical strokes must be aligned to the pixel grid.
* It's OK to "outline" strokes for the purposes of applying boolean operations
(e.g. subtracting another shape) and such.
* For toolbar icons, which exist in both 16x16 and 24x24 sizes, base the vector
version on the smaller 16x16 one, which is sometimes simpler. (This is already
done in the prioritized icon list above.)