Re: [RESULT] [VOTE] Recommend 'Apache NetBeans graduation to Top Level Project' resolution to board

[Tushar Joshi]

I totally agree and resonate with the feeling Wade has shared
Happy to be with NetBeans and seeing it graduate to top level project in
Apache

with regards
Tushar


On Fri, Apr 12, 2019 at 5:34 AM Wade Chandler 
wrote:

> Great news indeed! Thanks and congratulations to everyone who has
> contributed in any way including the Apache mentors Bertrand, Ate, Daniel,
> and Jim.
>
> A big special thanks to Geertjan, Jirka, Jarda, Tim, Jesse, Bruno, Milos,
> Tomas, Jan, and all the other old hats from NetBeans including the NBDT
> members; a lot of years and hard work behind all of this; decades!
>
> Everything we ever did looks like it will have a long and open life! I'm so
> proud of you all.
>
> After Bruno Souza and some of us started the "Dream Team" (say that without
> feeling cheesy), we created a mission statement:
>
> "The NetBeans Dream Team strives to make the NetBeans open source project
> more accessible to our user, contributor, and partner communities."
>
> Geertjan and Jirka helped us carry on that mission.
>
> I can't think of a better way to complete it than here at Apache with it's
> open and passion driven model "The Apache Way" and a TLP. Can it be more
> accessible?!
>
> Thanks for all the great years of fun, experiences and learning! Here's to
> more!
>
> Wade
>

Re: [RESULT] [VOTE] Recommend 'Apache NetBeans graduation to Top Level Project' resolution to board

[Wade Chandler]

Great news indeed! Thanks and congratulations to everyone who has
contributed in any way including the Apache mentors Bertrand, Ate, Daniel,
and Jim.

A big special thanks to Geertjan, Jirka, Jarda, Tim, Jesse, Bruno, Milos,
Tomas, Jan, and all the other old hats from NetBeans including the NBDT
members; a lot of years and hard work behind all of this; decades!

Everything we ever did looks like it will have a long and open life! I'm so
proud of you all.

After Bruno Souza and some of us started the "Dream Team" (say that without
feeling cheesy), we created a mission statement:

"The NetBeans Dream Team strives to make the NetBeans open source project
more accessible to our user, contributor, and partner communities."

Geertjan and Jirka helped us carry on that mission.

I can't think of a better way to complete it than here at Apache with it's
open and passion driven model "The Apache Way" and a TLP. Can it be more
accessible?!

Thanks for all the great years of fun, experiences and learning! Here's to
more!

Wade



On Thu, Apr 11, 2019, 08:50 Geertjan Wielenga
 wrote:

> Hi all,
>
> All the discussions and votes have succeeded -- and the Apache Board will
> be recommended to graduate Apache NetBeans to a top level project at its
> next meeting.
>
> Congrats everybody, for the great work done together and the even greater
> work to come!
>
> Thanks,
>
> Gj
>
> -- Forwarded message -
> From: Geertjan Wielenga 
> Date: Thu, Apr 11, 2019 at 1:18 PM
> Subject: [RESULT] [VOTE] Recommend 'Apache NetBeans graduation to Top
> Level Project' resolution to board
> To: 
>
>
> Hi all,
>
> Many thanks for the enthusiasm and encouragement -- the vote thread[1] has
> been open for 72 hours and the vote has passed:
>
> 18 +1 votes (and no 0 or -1 votes).
>
> Thanks,
>
> Geertjan
> on behalf of Apache NetBeans
>
> [1]
> https://lists.apache.org/thread.html/9d7c5d2048f8050fa0e438c5b14ea75c60a52ef479694f79f32e86b6@%3Cgeneral.incubator.apache.org%3E
>

Re: Editor tab control UI replacement

[Wade Chandler]

Great stuff Tim! Definitely work it in and contribute it. We need more of
that versus less, and who better! Certainly if it can be enabled and
disabled with a check box in settings it would be great; then can AB test
for which should be the default later. Maybe we should start some Apache
NetBeans feature surveys :-)

Thanks

Wade


On Wed, Apr 10, 2019, 15:56 Tim Boudreau  wrote:

> Back in 2003/4, I wrote the tab control for the NetBeans 3.6 window system,
> which is still in use - the thing JTabbedPane should have been if it had
> been written with the needs of applications like NetBeans in mind (i.e.
> model driven, not using the AWT hierarchy as its model, capable of complex
> transforms on its contents with minimal redraws, etc.).
>
> Some time after that, NetBeans' Visual Library came into being, which makes
> easy a lot of things that are otherwise very hard in Swing - animation,
> glows around components that extend beyond the bounds of the component,
> smooth scrolling and more.  So I've had it in my head for years that
> someone ought to write a replacement UI delegate for the editor tabs which
> uses it.  Needing to take a break from another project, the other day I
> finally wrote that.  It should work on any Swing look and feel (and I
> tested it on a bunch) - it derives its colors from those of the look and
> feel.  And all of the gradient painting logic is carefully memory managed
> using cached BufferedImages (10-40x faster than caching GradientPaint in my
> tests and far more consistent in its performance).
>
> What it does differently are mainly animation and bling, and highlighting
> for the selected tab that sits outside the tab.  It does have really lovely
> built-in tab-dragging support, but since drag support in the window system
> is implemented via an AWTEventListener in core.windows...I can disable that
> with a not-too-evil hack (have the UI delegate implement Tabbed.Adapter and
> then return null for its Tabbed instance), but then model changes aren't
> known to the window system, so it "corrects" them, undoing the drag on the
> next move.  But the existing tab dragging support (with its ugly polygons)
> works fine, so that's disabled by default.
>
> So, two things:
> 1.  If you'd like a little more (gratuitous?) bling in your editor tabs,
> please test it (download link below)
> 2.  I'd be happy to contribute it to NetBeans if there's interest - it's
> already licensed compatibly
>
> Screen shot (running on my own Dark Look and Feel plugin):
> https://timboudreau.com/files/screen/04-10-2019_15-48-36.png
>
> Binary download compatible w/ JDK 8 and up, NetBeans 8.2 and up:
> https://timboudreau.com/files/visual-library-tabbedcontrol-0.3.1.nbm
>
> Github repo w/ source code:
> https://github.com/timboudreau/visual-library-tabcontrol
>
> Feedback appreciated.
>
> Thanks,
>
> Tim
>
> --
> http://timboudreau.com
>

RE: Editor tab control UI replacement

[Eirik Bakke]

I tried it on Windows 10--I must say I strongly prefer the previous tab 
appearance (which you also wrote, so no shame in that! :-)

UIs are usually improved by removing unnecessary "bling", not adding more of 
it. The existing tab controls look simple and professional, and attract just 
about the right amount of attention to them: enough to clearly indicate which 
tab is active, but not enough to be distracting. Perhaps things are different 
on Darcula? If so, maybe some smaller Darcula color tweaks would achieve the 
same?

Animations also quickly get tiring. They tend to take something that was 
previously an instantaneous operation, like selecting a tab or even just 
hovering over one, and make it into something that is now perceived to take 
500ms of time. There are a few cases where animations _can_ be warranted, e.g. 
to show that a window is being minimized to a hidden taskbar on MacOS. But 
there is no such need here.

(That said, I love the existing NetBeans tab control! It looks a lot better 
than the Eclipse ones, and I use it in my NetBeans Platform application.)

-- Eirik

-Original Message-
From: Tim Boudreau  
Sent: Wednesday, April 10, 2019 3:57 PM
To: d...@netbeans.apache.org
Subject: Editor tab control UI replacement

Back in 2003/4, I wrote the tab control for the NetBeans 3.6 window system, 
which is still in use - the thing JTabbedPane should have been if it had been 
written with the needs of applications like NetBeans in mind (i.e.
model driven, not using the AWT hierarchy as its model, capable of complex 
transforms on its contents with minimal redraws, etc.).

Some time after that, NetBeans' Visual Library came into being, which makes 
easy a lot of things that are otherwise very hard in Swing - animation, glows 
around components that extend beyond the bounds of the component, smooth 
scrolling and more.  So I've had it in my head for years that someone ought to 
write a replacement UI delegate for the editor tabs which uses it.  Needing to 
take a break from another project, the other day I finally wrote that.  It 
should work on any Swing look and feel (and I tested it on a bunch) - it 
derives its colors from those of the look and feel.  And all of the gradient 
painting logic is carefully memory managed using cached BufferedImages (10-40x 
faster than caching GradientPaint in my tests and far more consistent in its 
performance).

What it does differently are mainly animation and bling, and highlighting for 
the selected tab that sits outside the tab.  It does have really lovely 
built-in tab-dragging support, but since drag support in the window system is 
implemented via an AWTEventListener in core.windows...I can disable that with a 
not-too-evil hack (have the UI delegate implement Tabbed.Adapter and then 
return null for its Tabbed instance), but then model changes aren't known to 
the window system, so it "corrects" them, undoing the drag on the next move.  
But the existing tab dragging support (with its ugly polygons) works fine, so 
that's disabled by default.

So, two things:
1.  If you'd like a little more (gratuitous?) bling in your editor tabs, please 
test it (download link below) 2.  I'd be happy to contribute it to NetBeans if 
there's interest - it's already licensed compatibly

Screen shot (running on my own Dark Look and Feel plugin):
https://timboudreau.com/files/screen/04-10-2019_15-48-36.png

Binary download compatible w/ JDK 8 and up, NetBeans 8.2 and up:
https://timboudreau.com/files/visual-library-tabbedcontrol-0.3.1.nbm

Github repo w/ source code:
https://github.com/timboudreau/visual-library-tabcontrol

Feedback appreciated.

Thanks,

Tim

--
http://timboudreau.com

Re: JavaFX debug

[Thomas Zimmermann]

This works for me:

   
    CUSTOM-debug
    debug
    
    install
    exec:exec@debug
    
    
    localhost:8000
    Listening for transport dt_socket at
   address
    
   

And in your pom.xml:

   
    org.codehaus.mojo
    exec-maven-plugin
    
    
    debug
    
    exec
    
    
    java
    
   
-agentlib:jdwp=transport=dt_socket,server=y,address=8000,suspend=y
    --module-path
    
    --module
   org.example/org.example.Main
    
    
    
    
   

This configuration is obviously for the module path, adapt to the 
classpath if needed.


Best regards,
Thomas


On 2019/04/06 10:26:36, joe schmo  wrote:
> I'm trying to debug a JavaFX program but it doesn't seem to recognize 
my breakpoints. Anyone else experience this? If so how did you fix it.>

>
> Thanks>
>
> BC>
>

Re: JavaFX debug

[joe schmo]

Doesn't work for me either

JDK 11.0.2
NetBeans 11.0
Windows 10

From: Glenn Holmer 
Sent: April 11, 2019 10:17 AM
To: dev@netbeans.incubator.apache.org
Subject: Re: JavaFX debug

On 4/11/19 3:30 AM, Luff,Chris wrote:
> Works for me…
>
> 
> debug
> 
> jar
> 
> 
> process-classes
> org.codehaus.mojo:exec-maven-plugin:1.5.0:exec
> 
> 
> 
> -agentlib:jdwp=transport=dt_socket,server=n,address=${jpda.address}
>  -classpath %classpath com.mypackage.MainApp
> java
> true
> 
> 
>
> You’re going to need to share some additional information - JDK, NetBeans 
> version etc.

Doesn't work for me.

JDK 11.0.2
NetBeans 11.0
Debian "buster" Linux

Sample project: https://gitlab.com/Cenbe/fxmaven

symptoms: Ignores "suspend=y" and "jpda.address" in jdwp settings,
breakpoints not hit. Trying to attach debugger at address shown in
debugger output results in a hang requiring NetBeans restart.

--
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

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

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

Re: JavaFX debug

[Glenn Holmer]

On 4/11/19 3:30 AM, Luff,Chris wrote:
> Works for me…
> 
> 
> debug
> 
> jar
> 
> 
> process-classes
> org.codehaus.mojo:exec-maven-plugin:1.5.0:exec
> 
> 
> 
> -agentlib:jdwp=transport=dt_socket,server=n,address=${jpda.address}
>  -classpath %classpath com.mypackage.MainApp
> java
> true
> 
> 
> 
> You’re going to need to share some additional information - JDK, NetBeans 
> version etc.

Doesn't work for me.

JDK 11.0.2
NetBeans 11.0
Debian "buster" Linux

Sample project: https://gitlab.com/Cenbe/fxmaven

symptoms: Ignores "suspend=y" and "jpda.address" in jdwp settings,
breakpoints not hit. Trying to attach debugger at address shown in
debugger output results in a hang requiring NetBeans restart.

-- 
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

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

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

Re: Fwd: [RESULT] [VOTE] Recommend 'Apache NetBeans graduation to Top Level Project' resolution to board

[Ate Douma]

On 11/04/2019 14.49, Geertjan Wielenga wrote:

Hi all,

All the discussions and votes have succeeded -- and the Apache Board 
will be recommended to graduate Apache NetBeans to a top level project 
at its next meeting. >
Congrats everybody, for the great work done together and the even 
greater work to come


Congratulations to everyone indeed!

Now, with the submission of the resolution to the board, preparation for
a press release can/should start as described here:

https://incubator.apache.org/guides/graduation.html#press_releases_for_new_tlps

Regards,
Ate



Thanks,

Gj

-- Forwarded message -
From: *Geertjan Wielenga* >

Date: Thu, Apr 11, 2019 at 1:18 PM
Subject: [RESULT] [VOTE] Recommend 'Apache NetBeans graduation to Top 
Level Project' resolution to board

To: mailto:gene...@incubator.apache.org>>


Hi all,

Many thanks for the enthusiasm and encouragement -- the vote thread[1] 
has been open for 72 hours and the vote has passed:


18 +1 votes (and no 0 or -1 votes).

Thanks,

Geertjan
on behalf of Apache NetBeans

[1] 
https://lists.apache.org/thread.html/9d7c5d2048f8050fa0e438c5b14ea75c60a52ef479694f79f32e86b6@%3Cgeneral.incubator.apache.org%3E


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

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

Fwd: [RESULT] [VOTE] Recommend 'Apache NetBeans graduation to Top Level Project' resolution to board

[Geertjan Wielenga]

Hi all,

All the discussions and votes have succeeded -- and the Apache Board will
be recommended to graduate Apache NetBeans to a top level project at its
next meeting.

Congrats everybody, for the great work done together and the even greater
work to come!

Thanks,

Gj

-- Forwarded message -
From: Geertjan Wielenga 
Date: Thu, Apr 11, 2019 at 1:18 PM
Subject: [RESULT] [VOTE] Recommend 'Apache NetBeans graduation to Top Level
Project' resolution to board
To: 


Hi all,

Many thanks for the enthusiasm and encouragement -- the vote thread[1] has
been open for 72 hours and the vote has passed:

18 +1 votes (and no 0 or -1 votes).

Thanks,

Geertjan
on behalf of Apache NetBeans

[1]
https://lists.apache.org/thread.html/9d7c5d2048f8050fa0e438c5b14ea75c60a52ef479694f79f32e86b6@%3Cgeneral.incubator.apache.org%3E

Re: JavaFX debug

[Luff,Chris]

Works for me…


debug

jar


process-classes
org.codehaus.mojo:exec-maven-plugin:1.5.0:exec



-agentlib:jdwp=transport=dt_socket,server=n,address=${jpda.address} 
-classpath %classpath com.mypackage.MainApp
java
true



You’re going to need to share some additional information - JDK, NetBeans 
version etc.

> On 6 Apr 2019, at 11:26, joe schmo  wrote:
>
> I'm trying to debug a JavaFX program but it doesn't seem to recognize my 
> breakpoints.  Anyone else experience this?  If so how did you fix it.
>
> Thanks
>
> BC



CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only for the addressee. The information 
contained in this message is confidential and may constitute inside or 
non-public information under international, federal, or state securities laws. 
Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail or you may call Cerner's corporate offices in Kansas 
City, Missouri, U.S.A at (+1) (816)221-1024. Cerner Limited, Registered in 
England no 2519305, Registered Office 37 North Wharf Road, London W2 1AF.

Re: Editor tab control UI replacement

[Geertjan Wielenga]

Very cool, would be great to have all tabs like that, sure, it should be
optional.

Gj

On Thu, Apr 11, 2019 at 9:13 AM Christian Lenz 
wrote:

> Looks nice  but please make it optional if we will build in into
> NetBeans. Not everyone wants to have it. Otherwise, if it is a Plugin, that
> will be also fine. My 2 Cents.
>
>
> Cheers
>
> Chris
>
>
>
> Von: Tim Boudreau
> Gesendet: Mittwoch, 10. April 2019 21:56
> An: d...@netbeans.apache.org
> Betreff: Editor tab control UI replacement
>
> Back in 2003/4, I wrote the tab control for the NetBeans 3.6 window system,
> which is still in use - the thing JTabbedPane should have been if it had
> been written with the needs of applications like NetBeans in mind (i.e.
> model driven, not using the AWT hierarchy as its model, capable of complex
> transforms on its contents with minimal redraws, etc.).
>
> Some time after that, NetBeans' Visual Library came into being, which makes
> easy a lot of things that are otherwise very hard in Swing - animation,
> glows around components that extend beyond the bounds of the component,
> smooth scrolling and more.  So I've had it in my head for years that
> someone ought to write a replacement UI delegate for the editor tabs which
> uses it.  Needing to take a break from another project, the other day I
> finally wrote that.  It should work on any Swing look and feel (and I
> tested it on a bunch) - it derives its colors from those of the look and
> feel.  And all of the gradient painting logic is carefully memory managed
> using cached BufferedImages (10-40x faster than caching GradientPaint in my
> tests and far more consistent in its performance).
>
> What it does differently are mainly animation and bling, and highlighting
> for the selected tab that sits outside the tab.  It does have really lovely
> built-in tab-dragging support, but since drag support in the window system
> is implemented via an AWTEventListener in core.windows...I can disable that
> with a not-too-evil hack (have the UI delegate implement Tabbed.Adapter and
> then return null for its Tabbed instance), but then model changes aren't
> known to the window system, so it "corrects" them, undoing the drag on the
> next move.  But the existing tab dragging support (with its ugly polygons)
> works fine, so that's disabled by default.
>
> So, two things:
> 1.  If you'd like a little more (gratuitous?) bling in your editor tabs,
> please test it (download link below)
> 2.  I'd be happy to contribute it to NetBeans if there's interest - it's
> already licensed compatibly
>
> Screen shot (running on my own Dark Look and Feel plugin):
> https://timboudreau.com/files/screen/04-10-2019_15-48-36.png
>
> Binary download compatible w/ JDK 8 and up, NetBeans 8.2 and up:
> https://timboudreau.com/files/visual-library-tabbedcontrol-0.3.1.nbm
>
> Github repo w/ source code:
> https://github.com/timboudreau/visual-library-tabcontrol
>
> Feedback appreciated.
>
> Thanks,
>
> Tim
>
> --
> http://timboudreau.com
>
>

AW: Editor tab control UI replacement

[Christian Lenz]

Looks nice  but please make it optional if we will build in into NetBeans. Not 
everyone wants to have it. Otherwise, if it is a Plugin, that will be also 
fine. My 2 Cents.


Cheers

Chris



Von: Tim Boudreau
Gesendet: Mittwoch, 10. April 2019 21:56
An: d...@netbeans.apache.org
Betreff: Editor tab control UI replacement

Back in 2003/4, I wrote the tab control for the NetBeans 3.6 window system,
which is still in use - the thing JTabbedPane should have been if it had
been written with the needs of applications like NetBeans in mind (i.e.
model driven, not using the AWT hierarchy as its model, capable of complex
transforms on its contents with minimal redraws, etc.).

Some time after that, NetBeans' Visual Library came into being, which makes
easy a lot of things that are otherwise very hard in Swing - animation,
glows around components that extend beyond the bounds of the component,
smooth scrolling and more.  So I've had it in my head for years that
someone ought to write a replacement UI delegate for the editor tabs which
uses it.  Needing to take a break from another project, the other day I
finally wrote that.  It should work on any Swing look and feel (and I
tested it on a bunch) - it derives its colors from those of the look and
feel.  And all of the gradient painting logic is carefully memory managed
using cached BufferedImages (10-40x faster than caching GradientPaint in my
tests and far more consistent in its performance).

What it does differently are mainly animation and bling, and highlighting
for the selected tab that sits outside the tab.  It does have really lovely
built-in tab-dragging support, but since drag support in the window system
is implemented via an AWTEventListener in core.windows...I can disable that
with a not-too-evil hack (have the UI delegate implement Tabbed.Adapter and
then return null for its Tabbed instance), but then model changes aren't
known to the window system, so it "corrects" them, undoing the drag on the
next move.  But the existing tab dragging support (with its ugly polygons)
works fine, so that's disabled by default.

So, two things:
1.  If you'd like a little more (gratuitous?) bling in your editor tabs,
please test it (download link below)
2.  I'd be happy to contribute it to NetBeans if there's interest - it's
already licensed compatibly

Screen shot (running on my own Dark Look and Feel plugin):
https://timboudreau.com/files/screen/04-10-2019_15-48-36.png

Binary download compatible w/ JDK 8 and up, NetBeans 8.2 and up:
https://timboudreau.com/files/visual-library-tabbedcontrol-0.3.1.nbm

Github repo w/ source code:
https://github.com/timboudreau/visual-library-tabcontrol

Feedback appreciated.

Thanks,

Tim

-- 
http://timboudreau.com

AW: NetBeans GUI icons, who drew them?

[Christian Lenz]

If you have a public repo or a public package with all Icons, you will not have 
that much duplicates or you have a good chance to find duplicate Icons easily. 
Now we can have mulitple times the same Icon for different stuff or different 
Icons for the same action. The magnify can look different in different packages 
but it should be the same if it is about searching. So you can Change one icon 
for search and each package, which uses this Icon changes. You don’t need to 
find out where to change exact that Icon which is a mess now.


Cheers

Chris



Von: Tim Boudreau
Gesendet: Mittwoch, 10. April 2019 23:05
An: dev@netbeans.incubator.apache.org
Betreff: Re: NetBeans GUI icons, who drew them?

== Precompiling

>
> As Tim points out we don't want to waste CPU/GPU time rendering
> gradients for icons at runtime.
>
> We could define some "standard" sizes for icons and precompile them to
> these sizes. Very much like native mobile apps do for Android an iOS. In
> iOS, for example, they have @1x, @2x, @3x suffixes for different icons
> sizes.
>
> That, of course will require a project/repository of its own.
>

I don't think so, regarding a repo.  Either:
 - Compile them to images of several sizes when building the module jar
(from reading the comments in VectorIcon, it sounds like particularly on
Windows hidpi, this can vary wildly, so I'm not sure this is a perfect
solution), or
 - Compile them to a Java class that adds up to "painting instructions"
(much faster load time and no dep on batik) - it's not that hard to write a
Graphics2D implementation that outputs Java code for everything done to it,
so you could load an SVG image into Batik, and have it paint into that and
generate a class from the result); on first load, load it, paint it into a
BufferedImage and save that to the IDE's cache directory, subdirectory by
screen resolution, with the SHA-1 hash of the original SVG as the name.
   - Or, let the installer do this at the end of install - it actually
knows the screen resolution likely to be needed, so that is the perfect
time to do it, and let the IDE do the above for anything missing

I don't think a repository just for icons solves much of anything, and
probably creates some new problems.  If you have a checkout of the IDE,
`find . -name *.svg` does a fine job for locating everying; disconnect them
from the code that uses them, and you're guaranteed to wind up with a pile
of old icons used by nothing that nobody is sure if are unused or not.

-Tim

>
>
> == Standardizing
>
> If we're to precompile icons we may also want to standardize them
> somehow. We could separate icons by cluster (in the repository above),
> and create a cluster-specific module responsible for returning icons (of
> appropriate size depending on DPI) for all modules in that cluster.
>
> The objective being making all "folder" icons look similar. We now have
> blue folders and yellow folders all around.
>
> == Generating SVG from PNG
>
> See Tim's response in another thread [1]. I think Emilian set up a
> website in 2017 to do this [2].
>
> I don't think automatic conversion is worth the effort: we'll end up
> having to fine-tune the results by hand, as Emilian tried to do back in
> 2017.
>
> Also note that Adobe Illustrator seems to have a way to do this:
>
> https://www.lifewire.com/use-image-trace-in-adobe-illustrator-cc-2017-4125254
>
> Cheers,
> Antonio
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/netbeans-dev/201904.mbox/%3cCA+qecRNnE=L49v5t46q_LVc=rpTqJD3U7zt4-0DAroG=x6h...@mail.gmail.com%3e
>
> [2]
> https://jaxenter.com/netbeans/netbeans-retina
>
> El 06/04/2019 a las 19:50, Tim Boudreau escribió:
> > I did most of the icons in 1999 (a few of them still exist in core as
> tree
> > icons for nodes that are not typically shown anymore); in 2000 they were
> > taken over by Sun's Human Interface Engineering team, and everything was
> > converted to the (awful) "flush 3d" metal look and feel look. Circa 2004
> we
> > got out from under the tyrrany of metal look and feel, and they were
> > redesigned again by a guy whose name I can't remember, but could probably
> > dig up - that redesign established the shapes still in use for things
> like
> > classes, fields and methods. Since then there was one reworking of the
> > icons that made them more cartoonish (I remember Wade calling it
> "NetBeans
> > for babies").
> >
> > I think in the long run, switching to vector icons is smart. That said, I
> > would not run with SVG without precompiling it into code that drives a
> > Graphics2D and either renders and caches images, or deals with
> performance
> > and memory allocation issues around GradientPaint and friends in the JDK
> > (both allocate large rasters on every paint, and vertical and horizontal
> > and radial gradients can be cached and reused instead - AND the pixel
> > pushing approach of those has a serious impedance mismatch with modern
> > graphics pipelines - it happens that just this week I benchmarked