You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@netbeans.apache.org by Eirik Bakke <eb...@ultorg.com> on 2019/04/05 23:02:02 UTC

NetBeans GUI icons, who drew them?

There are over 3000 bitmap icon images in the NetBeans codebase. Probably at least several hundred of these are frequently seen by everyday NetBeans users. The page below shows all the unique "gif" or "png" files that existed in the NetBeans mercurial repo prior to the Apache transition:

htps://people.csail.mit.edu/ebakke/misc/icons.html

THE QUESTION: Does anyone know who actually designed and drew these icons?

I assume some were cobbled together from various sources, but on the other hand, many of the frequently visible ones (e.g. the ones in the toolbars) seem to follow a quite consistent visual style.

(This question relates to the effort of making NetBeans look better on HiDPI/Retina screens; see separate email thread.)

-- Eirik

Re: NetBeans GUI icons, who drew them?

Posted by Glenn Holmer <ce...@kolabnow.com.INVALID>.

On 4/5/19 6:02 PM, Eirik Bakke wrote:
> There are over 3000 bitmap icon images in the NetBeans codebase.

> htps://people.csail.mit.edu/ebakke/misc/icons.html
> 
> THE QUESTION: Does anyone know who actually designed and drew these icons?

I remember a mailing list discussion back in "the old days" stating that
the color scheme had to do with the likelihood of color blindness (which
is higher than one might think, especially among males).

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

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

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

Re: AW: NetBeans GUI icons, who drew them?

Posted by Wade Chandler <wa...@apache.org>.

Top posting...

Indeed, sounds like some good info!

Thanks

Wade


On Mon, Apr 8, 2019, 11:28 Andreas Sewe <se...@cqse.eu> wrote:

> Hi,
>
> > I want to mention here the repo of IntelliJ the community edition. They
> do it as a package inside of the platform called Icons:
> https://github.com/JetBrains/intellij-community/tree/master/platform/icons
> as you can see, everything (I don’t know whether it is 100% or less but
> most of the Icons are inside of this package in subpackages. This is
> somehow centralized and not packed with each module and we don’t need find
> any Icon out. And as far as I can see, they use SVG Icons.
>
> some more input:
>
> The Eclipse platform (aka core) project has a single Git repository [1]
> but group the icons therein by plugin. Also, each plugin ships its own
> icons, aside from a few very generic icons like "Close", "Expand", etc,
> which are present in the org.eclipse.ui and org.eclipse.jface plugins.
>
> They then use a Maven plug-in [2] (internally using Batik, I believe) to
> render the SVGs as PNGs in both low and high DPI versions. The plug-in
> also has the option to apply different CSS stylesheets to the SVGs, to
> switch between dark and light mode icons, but I haven't used that
> feature yet.
>
> While the naming conventions used for generated files (e.g., "@2x"
> suffix) currently are probably Eclipse specific, the plug-in might be a
> good basis for NetBeans icon pipeline as well.
>
> Hope this helps,
>
> Andreas
>
> [1]
> <
> https://git.eclipse.org/c/platform/eclipse.platform.images.git/tree/org.eclipse.images/eclipse-svg
> >
> [2]
> <
> https://git.eclipse.org/c/platform/eclipse.platform.images.git/tree/org.eclipse.images.renderer/README.md
> >
>
> --
> Dr. Andreas Sewe | sewe@cqse.eu | +49 152 56342856
> CQSE GmbH | Centa-Hafenbraedl-Strasse 59 | 81249 Muenchen | www.cqse.eu
> Amtsgericht Muenchen | HRB 177678 | GF: F. Deissenboeck, M. Feilkas
>
>

Re: AW: NetBeans GUI icons, who drew them?

Posted by Andreas Sewe <se...@cqse.eu>.

Hi,

> I want to mention here the repo of IntelliJ the community edition. They do it as a package inside of the platform called Icons: https://github.com/JetBrains/intellij-community/tree/master/platform/icons as you can see, everything (I don’t know whether it is 100% or less but most of the Icons are inside of this package in subpackages. This is somehow centralized and not packed with each module and we don’t need find any Icon out. And as far as I can see, they use SVG Icons.

some more input:

The Eclipse platform (aka core) project has a single Git repository [1]
but group the icons therein by plugin. Also, each plugin ships its own
icons, aside from a few very generic icons like "Close", "Expand", etc,
which are present in the org.eclipse.ui and org.eclipse.jface plugins.

They then use a Maven plug-in [2] (internally using Batik, I believe) to
render the SVGs as PNGs in both low and high DPI versions. The plug-in
also has the option to apply different CSS stylesheets to the SVGs, to
switch between dark and light mode icons, but I haven't used that
feature yet.

While the naming conventions used for generated files (e.g., "@2x"
suffix) currently are probably Eclipse specific, the plug-in might be a
good basis for NetBeans icon pipeline as well.

Hope this helps,

Andreas

[1]
<https://git.eclipse.org/c/platform/eclipse.platform.images.git/tree/org.eclipse.images/eclipse-svg>
[2]
<https://git.eclipse.org/c/platform/eclipse.platform.images.git/tree/org.eclipse.images.renderer/README.md>

-- 
Dr. Andreas Sewe | sewe@cqse.eu | +49 152 56342856
CQSE GmbH | Centa-Hafenbraedl-Strasse 59 | 81249 Muenchen | www.cqse.eu
Amtsgericht Muenchen | HRB 177678 | GF: F. Deissenboeck, M. Feilkas

AW: NetBeans GUI icons, who drew them?

Posted by Christian Lenz <ch...@gmx.net>.

The thing with the folder is, it has sub folders for each module and the use. This makes it much easiert to change all Icons at once, if you want another set of Icons to change it by your own. For example, of changing it via a look and feel. And searching for all Icons. We don’t have a pain in the ass to find and figure out duplicated Icons. IMHO.

Cheers

Chris

Von: Antonio
Gesendet: Montag, 8. April 2019 07:58
An: dev@netbeans.incubator.apache.org
Betreff: Re: NetBeans GUI icons, who drew them?

El 07/04/2019 a las 23:32, Wade Chandler escribió:
>
> I discourage such a merge where icons from various modules wind up inside a single module. The module code itself still has to reference these things, and as such now must touch more than one module just to add an image. Why would I want N graphic files if I am using the platform but not the modules which require the N graphics? I call that bloat. I think if we are having an issue finding icons, and need a solution, we should solve that versus a giant lump; it could be a module manifest marker or something similar.
>

Well, this can made optional.

Many icons in NetBeans are retrieved using a simple String that is sent
to ImageUtilities [1] in "openide.util.ui". This module in turn depends
on "openide.util".

We could define an "IconProvider" service interface API, responsible for
finding icons by name.

And then change ImageUtilities to lookup one (or more) IconProvider SPIs
at runtime. When an icon is requested to ImageUtilities (by name) then
let's send that request to all SPIs, and see if any returns a proper icon.

So we end up with a set of pluggable "IconProvider"'s that people can
extend to replace existing icons gradually, and modules won't have to be
modified/refactored.

Cheers,
Antonio

[1]
https://github.com/apache/incubator-netbeans/blob/master/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java

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

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

Re: NetBeans GUI icons, who drew them?

Posted by Neil C Smith <ne...@apache.org>.

On Mon, 8 Apr 2019 at 06:58, Antonio <an...@vieiro.net> wrote:
> We could define an "IconProvider" service interface API, responsible for
> finding icons by name.

Exactly!  Been saying this for a long time.  And also linked this
before, and in conversations with Emi and others on Twitter, but it's
worth a look at the xdg spec, and in particular the use of hyphens to
have more/less specific icon resolution.

https://developer.gnome.org/icon-naming-spec/

I think we could use that as a useful starting point, given the amount
of work that's gone into it, or even move to adopt it and benefit from
lots of pre-existing icon themes?!

Obviously we'd need to fallback to existing files for now.

> So we end up with a set of pluggable "IconProvider"'s that people can
> extend to replace existing icons gradually, and modules won't have to be
> modified/refactored.

I also put forward a suggestion for this, and for pluggable text
providers, last year but it didn't much of a good response and at
least one -1.

I would definitely get involved with this effort, as it's very high on
my list of annoyances with the platform at the moment.  It should be
possible to plug in and override all areas of branding to allow
different resolution strategies.

Best wishes,

Neil

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

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

Re: NetBeans GUI icons, who drew them?

Posted by Wade Chandler <wa...@apache.org>.

On Mon, Apr 8, 2019, 01:58 Antonio <an...@vieiro.net> wrote:

>
>
> El 07/04/2019 a las 23:32, Wade Chandler escribió:
> >
> > I discourage such a merge where icons from various modules wind up
> inside a single module. The module code itself still has to reference these
> things, and as such now must touch more than one module just to add an
> image. Why would I want N graphic files if I am using the platform but not
> the modules which require the N graphics? I call that bloat. I think if we
> are having an issue finding icons, and need a solution, we should solve
> that versus a giant lump; it could be a module manifest marker or something
> similar.
> >
>
> Well, this can made optional.
>
> Many icons in NetBeans are retrieved using a simple String that is sent
> to ImageUtilities [1] in "openide.util.ui". This module in turn depends
> on "openide.util".
>
> We could define an "IconProvider" service interface API, responsible for
> finding icons by name.
>
> And then change ImageUtilities to lookup one (or more) IconProvider SPIs
> at runtime. When an icon is requested to ImageUtilities (by name) then
> let's send that request to all SPIs, and see if any returns a proper icon.
>
> So we end up with a set of pluggable "IconProvider"'s that people can
> extend to replace existing icons gradually, and modules won't have to be
> modified/refactored.
>

Yes, the SPI could also support a notion of "get all icons" or "get all
icon parent folders or packages" which could be used for development and
debugging purposes. Or just support a new module manifest entry(ies) to
support the same notion.

We are building a self hosting IDE, and can take advantage of this fact to
solve problems associated with modular development versus relying on common
operating system tools or less refined options like image extension
searches.

Wade

Re: NetBeans GUI icons, who drew them?

Posted by Antonio <an...@vieiro.net>.

Well, this can made optional.

Many icons in NetBeans are retrieved using a simple String that is sent
to ImageUtilities [1] in "openide.util.ui". This module in turn depends
on "openide.util".

We could define an "IconProvider" service interface API, responsible for
finding icons by name.

So we end up with a set of pluggable "IconProvider"'s that people can
extend to replace existing icons gradually, and modules won't have to be
modified/refactored.

Cheers,
Antonio

[1]
https://github.com/apache/incubator-netbeans/blob/master/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java

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

Re: NetBeans GUI icons, who drew them?

Posted by Wade Chandler <wa...@apache.org>.

> On Apr 7, 2019, at 5:25 AM, Christian Lenz <ch...@gmx.net> wrote:
> 
> Hey guys,
> 
> I want to mention here the repo of IntelliJ the community edition. They do it as a package inside of the platform called Icons: https://github.com/JetBrains/intellij-community/tree/master/platform/icons as you can see, everything (I don’t know whether it is 100% or less but most of the Icons are inside of this package in subpackages. This is somehow centralized and not packed with each module and we don’t need find any Icon out. And as far as I can see, they use SVG Icons.
> 

I discourage such a merge where icons from various modules wind up inside a single module. The module code itself still has to reference these things, and as such now must touch more than one module just to add an image. Why would I want N graphic files if I am using the platform but not the modules which require the N graphics? I call that bloat. I think if we are having an issue finding icons, and need a solution, we should solve that versus a giant lump; it could be a module manifest marker or something similar.

> So all on all, I know that atm it is not possible to have it like this, but this is, imho the future, that what we want and will be a lot of work. But maybe we can start to move Icons one by one to such a public package. And yes, I know that this will change the platform too(?).

I do think we could have a module which is used to convert graphics etc, and can then use an SPI. We can of course support SVG etc this way, but then too, could allow any other image type to be plugged in by a module author as needed. It would be super handy too to be able to support SVG clip paths for sprites or similar for pixel based images.

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

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

AW: NetBeans GUI icons, who drew them?

Posted by Christian Lenz <ch...@gmx.net>.

Hey guys,

I want to mention here the repo of IntelliJ the community edition. They do it as a package inside of the platform called Icons: https://github.com/JetBrains/intellij-community/tree/master/platform/icons as you can see, everything (I don’t know whether it is 100% or less but most of the Icons are inside of this package in subpackages. This is somehow centralized and not packed with each module and we don’t need find any Icon out. And as far as I can see, they use SVG Icons.

So all on all, I know that atm it is not possible to have it like this, but this is, imho the future, that what we want and will be a lot of work. But maybe we can start to move Icons one by one to such a public package. And yes, I know that this will change the platform too(?).

Cheers

Chris

Von: Antonio
Gesendet: Sonntag, 7. April 2019 11:11
An: dev@netbeans.incubator.apache.org
Betreff: Re: NetBeans GUI icons, who drew them?

Great pieces of advice here (and in another threads).

A summary with some more ideas:

== Color Scheme:

If we're to redesign icons we may want to define a color scheme first.

As Glenn points out the color scheme should play nice with color blind 
users and also play nice with the different LaFs we use frequently 
(including dark ones such as Darcula).

== 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.

== 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=x6Hdgg@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 cached
> gradient BufferedImages vs GradientPaint and RadialGradientPaint with as
> much raster caching as you could do there - the result was blitting
> BufferedImages was 10x faster, and 40x faster if you ran a full GC between
> benchmark loops, meaning that performance with Paint objects is also much
> less predictable). One of the rationales for JavaFX's creation was to have
> a graphics toolkit that operated with the grain of how modern graphics
> cards work, rather than 1990s xterms did things.
> 
> -Tim
> 
> On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eb...@ultorg.com> wrote:
> 
>> There are over 3000 bitmap icon images in the NetBeans codebase. Probably
>> at least several hundred of these are frequently seen by everyday NetBeans
>> users. The page below shows all the unique "gif" or "png" files that
>> existed in the NetBeans mercurial repo prior to the Apache transition:
>>
>> htps://people.csail.mit.edu/ebakke/misc/icons.html
>>
>> THE QUESTION: Does anyone know who actually designed and drew these icons?
>>
>> I assume some were cobbled together from various sources, but on the other
>> hand, many of the frequently visible ones (e.g. the ones in the toolbars)
>> seem to follow a quite consistent visual style.
>>
>> (This question relates to the effort of making NetBeans look better on
>> HiDPI/Retina screens; see separate email thread.)
>>
>> -- Eirik
>>
>> --
> http://timboudreau.com
> 

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

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

RE: NetBeans GUI icons, who drew them?

Posted by Eirik Bakke <eb...@ultorg.com>.

> I think IDEA has white-on-black icons when in dark mode, and only some of the icons seem to be colored. That avoids overwhelming the user with colors. A good IDEA, I think ;-)

Those kinds of tricks are actually very easy to apply as an ImageFilter--ImageUtilities alreadys supports it (via the "nb.imageicon.filter" UIManager property).

For instance, you can convert each pixel color to the LAB color space, and only invert the L component. That makes icons white-on-black, but keeps the hue (e.g. green remains green). If the colors are still too intense, you can also go through the HSB color space and decrease the saturation by some percentage. With the latest PRs, this works for every single icon in the IDE, both SVG and bitmap.

-- Eirik

-----Original Message-----
From: Antonio <an...@vieiro.net> 
Sent: Monday, June 3, 2019 9:56 AM
To: dev@netbeans.apache.org
Subject: Re: NetBeans GUI icons, who drew them?

Sounds reasonable to go for SVG first and tackle redesign later, if required.

I think IDEA has white-on-black icons when in dark mode, and only some of the icons seem to be colored. That avoids overwhelming the user with colors. A good IDEA, I think ;-)

Cheers,
Antonio

El 03/06/2019 a las 15:36, Eirik Bakke escribió:
>> I was wondering how we're going to create SVG from the PNGs, if we want to do it by hand, and if so if we want to define a "color set" for icons, or some sort of guidelines for creating them.
> 
> I proposed some guidelines here: 
> https://issues.apache.org/jira/browse/NETBEANS-2617
> 
> It seems most of the current icons were made by a single graphic designer (Leos Tronicek), who already did the work to come up with a consistent set of colors and shapes. So my proposal is to keep new SVG icons mostly the same as the old ones, only "modernizing" them in ways that make vectorization easier: namely by removing gradients, bevels, and unnecessary drop shadows.
> 
> The proposed approach has a number of advantages:
> * The job of vectorizing icons will be much easier when basing them on 
> existing icons than if creating entirely new shapes and colors. (I've 
> tried both approaches myself.)
> * The new icons will still get a modernized feel.
> * For the many years during which we will have a mix of vector and bitmap icons, the two types of icons will look consistent next to each other.
> * A proposal to replace icons X, Y, and Z will always be 
> uncontroversial, because the new icons will be strictly better than 
> the old ones--mostly same, but better resolution. Any significant 
> redesign, on the other hand, is bound to generate "I liked the old 
> ones better!" or "They don't match the other icons" type responses. 
> (Including from me :-)
> * Once a large number of icons have been converted to SVG, it will be fairly easy to adjust the color scheme in one go, while seeing all the icons next to each other.
> 
> -- Eirik
> 
> -----Original Message-----
> From: Antonio <an...@vieiro.net>
> Sent: Monday, June 3, 2019 7:37 AM
> To: dev@netbeans.apache.org
> Subject: Re: NetBeans GUI icons, who drew them?
> 
> Pretty cool!!
> 
> I was wondering how we're going to create SVG from the PNGs, if we want to do it by hand, and if so if we want to define a "color set" for icons, or some sort of guidelines for creating them.
> 
> Right now we seem to have many different icon styles together...
> 
> Cheers,
> Antonio
> 
> El 01/06/2019 a las 17:23, Eirik Bakke escribió:
>> Thanks!
>>
>> I've now added three HiDPI-related Pull Requests (feel free to comment):
>> * Improved scaling quality for existing low-resolution bitmap icons:
>> https://github.com/apache/netbeans/pull/1273
>> * Support loading and painting of scalable SVG icons (via
>> ImageUtilities): https://github.com/apache/netbeans/pull/1278
>> * Make the splash screen look good on HiDPI displays:
>> https://github.com/apache/netbeans/pull/1246
>>
>> For now, I've kept the ImageUtilities API the same as before. Tim, feel free to see if my caching approach in the SVG loader PR above satisfies your performance concerns. IntelliJ also uses Batik to load SVG icons at runtime, so I figured if it works for them, it should work for us as well. Though I've taken care to make sure the Batik JARs (3.6MB) are loaded lazily in a separate service provider module, so they don't have to become part of the core openide.util.ui module .
>>
>> I have also made a list of icons that would be good to prioritize for future replacement with SVG versions, and a proposed style guide in the related JIRA issue:
>> https://people.csail.mit.edu/ebakke/misc/netbeans-icons/prioritized.h
>> t
>> ml
>> https://issues.apache.org/jira/browse/NETBEANS-2617
>>
>> -- Eirik
>>
>> -----Original Message-----
>> From: Christian Lenz <ch...@gmx.net>
>> Sent: Thursday, April 11, 2019 3:13 AM
>> To: dev@netbeans.incubator.apache.org
>> Subject: AW: NetBeans GUI icons, who drew them?
>>
>> 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-201
>>> 7
>>> -
>>> 4125254
>>>
>>> Cheers,
>>> Antonio
>>>
>>> [1]
>>>
>>> http://mail-archives.apache.org/mod_mbox/netbeans-dev/201904.mbox/%3
>>> c
>>> C
>>> A+qecRNnE=L49v5t46q_LVc=rpTqJD3U7zt4-0DAroG=x6Hdgg@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 cached gradient BufferedImages vs 
>>>> GradientPaint and RadialGradientPaint with as much raster caching 
>>>> as you could do there - the result was blitting BufferedImages was 
>>>> 10x faster, and 40x faster if you ran a full GC
>>> between
>>>> benchmark loops, meaning that performance with Paint objects is 
>>>> also much less predictable). One of the rationales for JavaFX's 
>>>> creation was to
>>> have
>>>> a graphics toolkit that operated with the grain of how modern 
>>>> graphics cards work, rather than 1990s xterms did things.
>>>>
>>>> -Tim
>>>>
>>>> On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eb...@ultorg.com> wrote:
>>>>
>>>>> There are over 3000 bitmap icon images in the NetBeans codebase.
>>> Probably
>>>>> at least several hundred of these are frequently seen by everyday
>>> NetBeans
>>>>> users. The page below shows all the unique "gif" or "png" files 
>>>>> that existed in the NetBeans mercurial repo prior to the Apache transition:
>>>>>
>>>>> htps://people.csail.mit.edu/ebakke/misc/icons.html
>>>>>
>>>>> THE QUESTION: Does anyone know who actually designed and drew 
>>>>> these
>>> icons?
>>>>>
>>>>> I assume some were cobbled together from various sources, but on 
>>>>> the
>>> other
>>>>> hand, many of the frequently visible ones (e.g. the ones in the
>>> toolbars)
>>>>> seem to follow a quite consistent visual style.
>>>>>
>>>>> (This question relates to the effort of making NetBeans look 
>>>>> better on HiDPI/Retina screens; see separate email thread.)
>>>>>
>>>>> -- Eirik
>>>>>
>>>>> --
>>>> http://timboudreau.com
>>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: 
>>> dev-unsubscribe@netbeans.incubator.apache.org
>>> For additional commands, e-mail:
>>> dev-help@netbeans.incubator.apache.org
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>
>>>
>>>
>>>
>>
>> --
>> http://timboudreau.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> 
> 

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

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

Re: NetBeans GUI icons, who drew them?

Posted by Antonio <an...@vieiro.net>.

Sounds reasonable to go for SVG first and tackle redesign later, if 
required.

I think IDEA has white-on-black icons when in dark mode, and only some 
of the icons seem to be colored. That avoids overwhelming the user with 
colors. A good IDEA, I think ;-)

Cheers,
Antonio

El 03/06/2019 a las 15:36, Eirik Bakke escribió:
>> I was wondering how we're going to create SVG from the PNGs, if we want to do it by hand, and if so if we want to define a "color set" for icons, or some sort of guidelines for creating them.
> 
> I proposed some guidelines here: https://issues.apache.org/jira/browse/NETBEANS-2617
> 
> It seems most of the current icons were made by a single graphic designer (Leos Tronicek), who already did the work to come up with a consistent set of colors and shapes. So my proposal is to keep new SVG icons mostly the same as the old ones, only "modernizing" them in ways that make vectorization easier: namely by removing gradients, bevels, and unnecessary drop shadows.
> 
> The proposed approach has a number of advantages:
> * The job of vectorizing icons will be much easier when basing them on existing icons than if creating entirely new shapes and colors. (I've tried both approaches myself.)
> * The new icons will still get a modernized feel.
> * For the many years during which we will have a mix of vector and bitmap icons, the two types of icons will look consistent next to each other.
> * A proposal to replace icons X, Y, and Z will always be uncontroversial, because the new icons will be strictly better than the old ones--mostly same, but better resolution. Any significant redesign, on the other hand, is bound to generate "I liked the old ones better!" or "They don't match the other icons" type responses. (Including from me :-)
> * Once a large number of icons have been converted to SVG, it will be fairly easy to adjust the color scheme in one go, while seeing all the icons next to each other.
> 
> -- Eirik
> 
> -----Original Message-----
> From: Antonio <an...@vieiro.net>
> Sent: Monday, June 3, 2019 7:37 AM
> To: dev@netbeans.apache.org
> Subject: Re: NetBeans GUI icons, who drew them?
> 
> Pretty cool!!
> 
> I was wondering how we're going to create SVG from the PNGs, if we want to do it by hand, and if so if we want to define a "color set" for icons, or some sort of guidelines for creating them.
> 
> Right now we seem to have many different icon styles together...
> 
> Cheers,
> Antonio
> 
> El 01/06/2019 a las 17:23, Eirik Bakke escribió:
>> Thanks!
>>
>> I've now added three HiDPI-related Pull Requests (feel free to comment):
>> * Improved scaling quality for existing low-resolution bitmap icons:
>> https://github.com/apache/netbeans/pull/1273
>> * Support loading and painting of scalable SVG icons (via
>> ImageUtilities): https://github.com/apache/netbeans/pull/1278
>> * Make the splash screen look good on HiDPI displays:
>> https://github.com/apache/netbeans/pull/1246
>>
>> For now, I've kept the ImageUtilities API the same as before. Tim, feel free to see if my caching approach in the SVG loader PR above satisfies your performance concerns. IntelliJ also uses Batik to load SVG icons at runtime, so I figured if it works for them, it should work for us as well. Though I've taken care to make sure the Batik JARs (3.6MB) are loaded lazily in a separate service provider module, so they don't have to become part of the core openide.util.ui module .
>>
>> I have also made a list of icons that would be good to prioritize for future replacement with SVG versions, and a proposed style guide in the related JIRA issue:
>> https://people.csail.mit.edu/ebakke/misc/netbeans-icons/prioritized.ht
>> ml
>> https://issues.apache.org/jira/browse/NETBEANS-2617
>>
>> -- Eirik
>>
>> -----Original Message-----
>> From: Christian Lenz <ch...@gmx.net>
>> Sent: Thursday, April 11, 2019 3:13 AM
>> To: dev@netbeans.incubator.apache.org
>> Subject: AW: NetBeans GUI icons, who drew them?
>>
>> 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/%3c
>>> C
>>> A+qecRNnE=L49v5t46q_LVc=rpTqJD3U7zt4-0DAroG=x6Hdgg@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 cached gradient BufferedImages vs GradientPaint
>>>> and RadialGradientPaint with as much raster caching as you could do
>>>> there - the result was blitting BufferedImages was 10x faster, and
>>>> 40x faster if you ran a full GC
>>> between
>>>> benchmark loops, meaning that performance with Paint objects is also
>>>> much less predictable). One of the rationales for JavaFX's creation
>>>> was to
>>> have
>>>> a graphics toolkit that operated with the grain of how modern
>>>> graphics cards work, rather than 1990s xterms did things.
>>>>
>>>> -Tim
>>>>
>>>> On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eb...@ultorg.com> wrote:
>>>>
>>>>> There are over 3000 bitmap icon images in the NetBeans codebase.
>>> Probably
>>>>> at least several hundred of these are frequently seen by everyday
>>> NetBeans
>>>>> users. The page below shows all the unique "gif" or "png" files
>>>>> that existed in the NetBeans mercurial repo prior to the Apache transition:
>>>>>
>>>>> htps://people.csail.mit.edu/ebakke/misc/icons.html
>>>>>
>>>>> THE QUESTION: Does anyone know who actually designed and drew these
>>> icons?
>>>>>
>>>>> I assume some were cobbled together from various sources, but on
>>>>> the
>>> other
>>>>> hand, many of the frequently visible ones (e.g. the ones in the
>>> toolbars)
>>>>> seem to follow a quite consistent visual style.
>>>>>
>>>>> (This question relates to the effort of making NetBeans look better
>>>>> on HiDPI/Retina screens; see separate email thread.)
>>>>>
>>>>> -- Eirik
>>>>>
>>>>> --
>>>> http://timboudreau.com
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>>> For additional commands, e-mail:
>>> dev-help@netbeans.incubator.apache.org
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>
>>>
>>>
>>>
>>
>> --
>> http://timboudreau.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> 
> 

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

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

RE: NetBeans GUI icons, who drew them?

Posted by Eirik Bakke <eb...@ultorg.com>.

> I was wondering how we're going to create SVG from the PNGs, if we want to do it by hand, and if so if we want to define a "color set" for icons, or some sort of guidelines for creating them.

I proposed some guidelines here: https://issues.apache.org/jira/browse/NETBEANS-2617

It seems most of the current icons were made by a single graphic designer (Leos Tronicek), who already did the work to come up with a consistent set of colors and shapes. So my proposal is to keep new SVG icons mostly the same as the old ones, only "modernizing" them in ways that make vectorization easier: namely by removing gradients, bevels, and unnecessary drop shadows.

The proposed approach has a number of advantages:
* The job of vectorizing icons will be much easier when basing them on existing icons than if creating entirely new shapes and colors. (I've tried both approaches myself.)
* The new icons will still get a modernized feel.
* For the many years during which we will have a mix of vector and bitmap icons, the two types of icons will look consistent next to each other.
* A proposal to replace icons X, Y, and Z will always be uncontroversial, because the new icons will be strictly better than the old ones--mostly same, but better resolution. Any significant redesign, on the other hand, is bound to generate "I liked the old ones better!" or "They don't match the other icons" type responses. (Including from me :-)
* Once a large number of icons have been converted to SVG, it will be fairly easy to adjust the color scheme in one go, while seeing all the icons next to each other.

-- Eirik

-----Original Message-----
From: Antonio <an...@vieiro.net> 
Sent: Monday, June 3, 2019 7:37 AM
To: dev@netbeans.apache.org
Subject: Re: NetBeans GUI icons, who drew them?

Pretty cool!!

I was wondering how we're going to create SVG from the PNGs, if we want to do it by hand, and if so if we want to define a "color set" for icons, or some sort of guidelines for creating them.

Right now we seem to have many different icon styles together...

Cheers,
Antonio

El 01/06/2019 a las 17:23, Eirik Bakke escribió:
> Thanks!
> 
> I've now added three HiDPI-related Pull Requests (feel free to comment):
> * Improved scaling quality for existing low-resolution bitmap icons: 
> https://github.com/apache/netbeans/pull/1273
> * Support loading and painting of scalable SVG icons (via 
> ImageUtilities): https://github.com/apache/netbeans/pull/1278
> * Make the splash screen look good on HiDPI displays: 
> https://github.com/apache/netbeans/pull/1246
> 
> For now, I've kept the ImageUtilities API the same as before. Tim, feel free to see if my caching approach in the SVG loader PR above satisfies your performance concerns. IntelliJ also uses Batik to load SVG icons at runtime, so I figured if it works for them, it should work for us as well. Though I've taken care to make sure the Batik JARs (3.6MB) are loaded lazily in a separate service provider module, so they don't have to become part of the core openide.util.ui module .
> 
> I have also made a list of icons that would be good to prioritize for future replacement with SVG versions, and a proposed style guide in the related JIRA issue:
> https://people.csail.mit.edu/ebakke/misc/netbeans-icons/prioritized.ht
> ml
> https://issues.apache.org/jira/browse/NETBEANS-2617
> 
> -- Eirik
> 
> -----Original Message-----
> From: Christian Lenz <ch...@gmx.net>
> Sent: Thursday, April 11, 2019 3:13 AM
> To: dev@netbeans.incubator.apache.org
> Subject: AW: NetBeans GUI icons, who drew them?
> 
> 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/%3c
>> C
>> A+qecRNnE=L49v5t46q_LVc=rpTqJD3U7zt4-0DAroG=x6Hdgg@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 cached gradient BufferedImages vs GradientPaint 
>>> and RadialGradientPaint with as much raster caching as you could do 
>>> there - the result was blitting BufferedImages was 10x faster, and 
>>> 40x faster if you ran a full GC
>> between
>>> benchmark loops, meaning that performance with Paint objects is also 
>>> much less predictable). One of the rationales for JavaFX's creation 
>>> was to
>> have
>>> a graphics toolkit that operated with the grain of how modern 
>>> graphics cards work, rather than 1990s xterms did things.
>>>
>>> -Tim
>>>
>>> On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eb...@ultorg.com> wrote:
>>>
>>>> There are over 3000 bitmap icon images in the NetBeans codebase.
>> Probably
>>>> at least several hundred of these are frequently seen by everyday
>> NetBeans
>>>> users. The page below shows all the unique "gif" or "png" files 
>>>> that existed in the NetBeans mercurial repo prior to the Apache transition:
>>>>
>>>> htps://people.csail.mit.edu/ebakke/misc/icons.html
>>>>
>>>> THE QUESTION: Does anyone know who actually designed and drew these
>> icons?
>>>>
>>>> I assume some were cobbled together from various sources, but on 
>>>> the
>> other
>>>> hand, many of the frequently visible ones (e.g. the ones in the
>> toolbars)
>>>> seem to follow a quite consistent visual style.
>>>>
>>>> (This question relates to the effort of making NetBeans look better 
>>>> on HiDPI/Retina screens; see separate email thread.)
>>>>
>>>> -- Eirik
>>>>
>>>> --
>>> http://timboudreau.com
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>> For additional commands, e-mail:
>> dev-help@netbeans.incubator.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>
> 
> --
> http://timboudreau.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> 
> 

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

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

Re: NetBeans GUI icons, who drew them?

Posted by Antonio <an...@vieiro.net>.

Pretty cool!!

I was wondering how we're going to create SVG from the PNGs, if we want 
to do it by hand, and if so if we want to define a "color set" for 
icons, or some sort of guidelines for creating them.

Right now we seem to have many different icon styles together...

Cheers,
Antonio

El 01/06/2019 a las 17:23, Eirik Bakke escribió:
> Thanks!
> 
> I've now added three HiDPI-related Pull Requests (feel free to comment):
> * Improved scaling quality for existing low-resolution bitmap icons: https://github.com/apache/netbeans/pull/1273
> * Support loading and painting of scalable SVG icons (via ImageUtilities): https://github.com/apache/netbeans/pull/1278
> * Make the splash screen look good on HiDPI displays: https://github.com/apache/netbeans/pull/1246
> 
> For now, I've kept the ImageUtilities API the same as before. Tim, feel free to see if my caching approach in the SVG loader PR above satisfies your performance concerns. IntelliJ also uses Batik to load SVG icons at runtime, so I figured if it works for them, it should work for us as well. Though I've taken care to make sure the Batik JARs (3.6MB) are loaded lazily in a separate service provider module, so they don't have to become part of the core openide.util.ui module .
> 
> I have also made a list of icons that would be good to prioritize for future replacement with SVG versions, and a proposed style guide in the related JIRA issue:
> https://people.csail.mit.edu/ebakke/misc/netbeans-icons/prioritized.html
> https://issues.apache.org/jira/browse/NETBEANS-2617
> 
> -- Eirik
> 
> -----Original Message-----
> From: Christian Lenz <ch...@gmx.net>
> Sent: Thursday, April 11, 2019 3:13 AM
> To: dev@netbeans.incubator.apache.org
> Subject: AW: NetBeans GUI icons, who drew them?
> 
> 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/%3cC
>> A+qecRNnE=L49v5t46q_LVc=rpTqJD3U7zt4-0DAroG=x6Hdgg@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 cached gradient BufferedImages vs GradientPaint
>>> and RadialGradientPaint with as much raster caching as you could do
>>> there - the result was blitting BufferedImages was 10x faster, and
>>> 40x faster if you ran a full GC
>> between
>>> benchmark loops, meaning that performance with Paint objects is also
>>> much less predictable). One of the rationales for JavaFX's creation
>>> was to
>> have
>>> a graphics toolkit that operated with the grain of how modern
>>> graphics cards work, rather than 1990s xterms did things.
>>>
>>> -Tim
>>>
>>> On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eb...@ultorg.com> wrote:
>>>
>>>> There are over 3000 bitmap icon images in the NetBeans codebase.
>> Probably
>>>> at least several hundred of these are frequently seen by everyday
>> NetBeans
>>>> users. The page below shows all the unique "gif" or "png" files
>>>> that existed in the NetBeans mercurial repo prior to the Apache transition:
>>>>
>>>> htps://people.csail.mit.edu/ebakke/misc/icons.html
>>>>
>>>> THE QUESTION: Does anyone know who actually designed and drew these
>> icons?
>>>>
>>>> I assume some were cobbled together from various sources, but on
>>>> the
>> other
>>>> hand, many of the frequently visible ones (e.g. the ones in the
>> toolbars)
>>>> seem to follow a quite consistent visual style.
>>>>
>>>> (This question relates to the effort of making NetBeans look better
>>>> on HiDPI/Retina screens; see separate email thread.)
>>>>
>>>> -- Eirik
>>>>
>>>> --
>>> http://timboudreau.com
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>> For additional commands, e-mail:
>> dev-help@netbeans.incubator.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>
> 
> --
> http://timboudreau.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> 
> 

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

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

RE: NetBeans GUI icons, who drew them?

Posted by Eirik Bakke <eb...@ultorg.com>.

> I'm somewhat -1 to the SVGLoader SPI approach checking by extension I think.

Yeah, it's a little controversial to load "icon.svg" when the client requested "icon.png". Perhaps I'll require the SVG file to be named explicitly for now.

> Why not a generic IconLoader SPI and first loader that handles the URL wins?

I think that would be a separate feature that could be added later. The main reason for the SVGLoader SPI is to delay loading of the Batik SVG library JARs until after the core startup modules have loaded (e.g. the splash screen). In fact, I'd love for the SVGLoader SPI to be a non-public implementation detail--is there a way I can do this?

In your proposed IconLoader SPI, how do you image that implementation modules will specify which URLs they can handle? If the implementation modules must do this programmatically, then they cannot be loaded lazily. So in that case the IconLoader SPI ends up being separate from the SVGLoader SPI in any case. Any thoughts on this?

-- Eirik

-----Original Message-----
From: Neil C Smith <ne...@apache.org> 
Sent: Monday, June 3, 2019 6:24 AM
To: dev <de...@netbeans.apache.org>
Cc: dev@netbeans.incubator.apache.org
Subject: Re: NetBeans GUI icons, who drew them?

Hi,

This looks great! Was going to comment on one of the PR but I've only had a chance to glance at the code so far. A query ...

On Sat, 1 Jun 2019, 17:23 Eirik Bakke, <eb...@ultorg.com> wrote:

> For now, I've kept the ImageUtilities API the same as before.
>

I'm somewhat -1 to the SVGLoader SPI approach checking by extension I think. Why not a generic IconLoader SPI and first loader that handles the URL wins? This allows other extension in future, for which I can think of a few uses, and removes handler specific logic.

Best wishes,

Neil

>

Re: NetBeans GUI icons, who drew them?

Posted by Neil C Smith <ne...@apache.org>.

Hi,

This looks great! Was going to comment on one of the PR but I've only had a
chance to glance at the code so far. A query ...

On Sat, 1 Jun 2019, 17:23 Eirik Bakke, <eb...@ultorg.com> wrote:

> For now, I've kept the ImageUtilities API the same as before.
>

I'm somewhat -1 to the SVGLoader SPI approach checking by extension I
think. Why not a generic IconLoader SPI and first loader that handles the
URL wins? This allows other extension in future, for which I can think of a
few uses, and removes handler specific logic.

Best wishes,

Neil

>

RE: NetBeans GUI icons, who drew them?

Posted by Eirik Bakke <eb...@ultorg.com>.

Thanks!

I've now added three HiDPI-related Pull Requests (feel free to comment):
* Improved scaling quality for existing low-resolution bitmap icons: https://github.com/apache/netbeans/pull/1273
* Support loading and painting of scalable SVG icons (via ImageUtilities): https://github.com/apache/netbeans/pull/1278
* Make the splash screen look good on HiDPI displays: https://github.com/apache/netbeans/pull/1246

For now, I've kept the ImageUtilities API the same as before. Tim, feel free to see if my caching approach in the SVG loader PR above satisfies your performance concerns. IntelliJ also uses Batik to load SVG icons at runtime, so I figured if it works for them, it should work for us as well. Though I've taken care to make sure the Batik JARs (3.6MB) are loaded lazily in a separate service provider module, so they don't have to become part of the core openide.util.ui module .

I have also made a list of icons that would be good to prioritize for future replacement with SVG versions, and a proposed style guide in the related JIRA issue:
https://people.csail.mit.edu/ebakke/misc/netbeans-icons/prioritized.html
https://issues.apache.org/jira/browse/NETBEANS-2617

-- Eirik

-----Original Message-----
From: Christian Lenz <ch...@gmx.net> 
Sent: Thursday, April 11, 2019 3:13 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: NetBeans GUI icons, who drew them?

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/%3cC
> A+qecRNnE=L49v5t46q_LVc=rpTqJD3U7zt4-0DAroG=x6Hdgg@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 cached gradient BufferedImages vs GradientPaint 
> > and RadialGradientPaint with as much raster caching as you could do 
> > there - the result was blitting BufferedImages was 10x faster, and 
> > 40x faster if you ran a full GC
> between
> > benchmark loops, meaning that performance with Paint objects is also 
> > much less predictable). One of the rationales for JavaFX's creation 
> > was to
> have
> > a graphics toolkit that operated with the grain of how modern 
> > graphics cards work, rather than 1990s xterms did things.
> >
> > -Tim
> >
> > On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eb...@ultorg.com> wrote:
> >
> >> There are over 3000 bitmap icon images in the NetBeans codebase.
> Probably
> >> at least several hundred of these are frequently seen by everyday
> NetBeans
> >> users. The page below shows all the unique "gif" or "png" files 
> >> that existed in the NetBeans mercurial repo prior to the Apache transition:
> >>
> >> htps://people.csail.mit.edu/ebakke/misc/icons.html
> >>
> >> THE QUESTION: Does anyone know who actually designed and drew these
> icons?
> >>
> >> I assume some were cobbled together from various sources, but on 
> >> the
> other
> >> hand, many of the frequently visible ones (e.g. the ones in the
> toolbars)
> >> seem to follow a quite consistent visual style.
> >>
> >> (This question relates to the effort of making NetBeans look better 
> >> on HiDPI/Retina screens; see separate email thread.)
> >>
> >> -- Eirik
> >>
> >> --
> > http://timboudreau.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: 
> dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

--
http://timboudreau.com

AW: NetBeans GUI icons, who drew them?

Posted by Christian Lenz <ch...@gmx.net>.

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=x6Hdgg@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 cached
> > gradient BufferedImages vs GradientPaint and RadialGradientPaint with as
> > much raster caching as you could do there - the result was blitting
> > BufferedImages was 10x faster, and 40x faster if you ran a full GC
> between
> > benchmark loops, meaning that performance with Paint objects is also much
> > less predictable). One of the rationales for JavaFX's creation was to
> have
> > a graphics toolkit that operated with the grain of how modern graphics
> > cards work, rather than 1990s xterms did things.
> >
> > -Tim
> >
> > On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eb...@ultorg.com> wrote:
> >
> >> There are over 3000 bitmap icon images in the NetBeans codebase.
> Probably
> >> at least several hundred of these are frequently seen by everyday
> NetBeans
> >> users. The page below shows all the unique "gif" or "png" files that
> >> existed in the NetBeans mercurial repo prior to the Apache transition:
> >>
> >> htps://people.csail.mit.edu/ebakke/misc/icons.html
> >>
> >> THE QUESTION: Does anyone know who actually designed and drew these
> icons?
> >>
> >> I assume some were cobbled together from various sources, but on the
> other
> >> hand, many of the frequently visible ones (e.g. the ones in the
> toolbars)
> >> seem to follow a quite consistent visual style.
> >>
> >> (This question relates to the effort of making NetBeans look better on
> >> HiDPI/Retina screens; see separate email thread.)
> >>
> >> -- Eirik
> >>
> >> --
> > http://timboudreau.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

-- 
http://timboudreau.com

Re: NetBeans GUI icons, who drew them?

Posted by Tim Boudreau <ni...@gmail.com>.

== 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=x6Hdgg@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 cached
> > gradient BufferedImages vs GradientPaint and RadialGradientPaint with as
> > much raster caching as you could do there - the result was blitting
> > BufferedImages was 10x faster, and 40x faster if you ran a full GC
> between
> > benchmark loops, meaning that performance with Paint objects is also much
> > less predictable). One of the rationales for JavaFX's creation was to
> have
> > a graphics toolkit that operated with the grain of how modern graphics
> > cards work, rather than 1990s xterms did things.
> >
> > -Tim
> >
> > On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eb...@ultorg.com> wrote:
> >
> >> There are over 3000 bitmap icon images in the NetBeans codebase.
> Probably
> >> at least several hundred of these are frequently seen by everyday
> NetBeans
> >> users. The page below shows all the unique "gif" or "png" files that
> >> existed in the NetBeans mercurial repo prior to the Apache transition:
> >>
> >> htps://people.csail.mit.edu/ebakke/misc/icons.html
> >>
> >> THE QUESTION: Does anyone know who actually designed and drew these
> icons?
> >>
> >> I assume some were cobbled together from various sources, but on the
> other
> >> hand, many of the frequently visible ones (e.g. the ones in the
> toolbars)
> >> seem to follow a quite consistent visual style.
> >>
> >> (This question relates to the effort of making NetBeans look better on
> >> HiDPI/Retina screens; see separate email thread.)
> >>
> >> -- Eirik
> >>
> >> --
> > http://timboudreau.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

-- 
http://timboudreau.com

Re: NetBeans GUI icons, who drew them?

Posted by Antonio <an...@vieiro.net>.

Great pieces of advice here (and in another threads).

A summary with some more ideas:

== Color Scheme:

If we're to redesign icons we may want to define a color scheme first.

As Glenn points out the color scheme should play nice with color blind 
users and also play nice with the different LaFs we use frequently 
(including dark ones such as Darcula).

== 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.

== 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=x6Hdgg@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 cached
> gradient BufferedImages vs GradientPaint and RadialGradientPaint with as
> much raster caching as you could do there - the result was blitting
> BufferedImages was 10x faster, and 40x faster if you ran a full GC between
> benchmark loops, meaning that performance with Paint objects is also much
> less predictable). One of the rationales for JavaFX's creation was to have
> a graphics toolkit that operated with the grain of how modern graphics
> cards work, rather than 1990s xterms did things.
> 
> -Tim
> 
> On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eb...@ultorg.com> wrote:
> 
>> There are over 3000 bitmap icon images in the NetBeans codebase. Probably
>> at least several hundred of these are frequently seen by everyday NetBeans
>> users. The page below shows all the unique "gif" or "png" files that
>> existed in the NetBeans mercurial repo prior to the Apache transition:
>>
>> htps://people.csail.mit.edu/ebakke/misc/icons.html
>>
>> THE QUESTION: Does anyone know who actually designed and drew these icons?
>>
>> I assume some were cobbled together from various sources, but on the other
>> hand, many of the frequently visible ones (e.g. the ones in the toolbars)
>> seem to follow a quite consistent visual style.
>>
>> (This question relates to the effort of making NetBeans look better on
>> HiDPI/Retina screens; see separate email thread.)
>>
>> -- Eirik
>>
>> --
> http://timboudreau.com
> 

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

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

Re: NetBeans GUI icons, who drew them?

Posted by Tim Boudreau <ni...@gmail.com>.

Actually, Leos did the "NetBeans for babies" revision of that earlier work.
It was someone else in California who did the rev that got us to the
current set of shapes. Had to be circa 2003-4 since I was still living in
Prague at the time. But Leos was easily the most artistically talented
graphic designer I've worked with.

-Tim

On Sat, Apr 6, 2019 at 3:09 PM Geertjan Wielenga
<ge...@googlemail.com.invalid> wrote:

> On Sat, Apr 6, 2019 at 7:50 PM Tim Boudreau <ni...@gmail.com> wrote:
>
> > 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,
>
>
> Leos Tronicek.
>
> Gj
>
>
> >
>
> 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 cached
> > gradient BufferedImages vs GradientPaint and RadialGradientPaint with as
> > much raster caching as you could do there - the result was blitting
> > BufferedImages was 10x faster, and 40x faster if you ran a full GC
> between
> > benchmark loops, meaning that performance with Paint objects is also much
> > less predictable). One of the rationales for JavaFX's creation was to
> have
> > a graphics toolkit that operated with the grain of how modern graphics
> > cards work, rather than 1990s xterms did things.
> >
> > -Tim
> >
> > On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eb...@ultorg.com> wrote:
> >
> > > There are over 3000 bitmap icon images in the NetBeans codebase.
> Probably
> > > at least several hundred of these are frequently seen by everyday
> > NetBeans
> > > users. The page below shows all the unique "gif" or "png" files that
> > > existed in the NetBeans mercurial repo prior to the Apache transition:
> > >
> > > htps://people.csail.mit.edu/ebakke/misc/icons.html
> > >
> > > THE QUESTION: Does anyone know who actually designed and drew these
> > icons?
> > >
> > > I assume some were cobbled together from various sources, but on the
> > other
> > > hand, many of the frequently visible ones (e.g. the ones in the
> toolbars)
> > > seem to follow a quite consistent visual style.
> > >
> > > (This question relates to the effort of making NetBeans look better on
> > > HiDPI/Retina screens; see separate email thread.)
> > >
> > > -- Eirik
> > >
> > > --
> > http://timboudreau.com
> >
>
-- 
http://timboudreau.com

Re: NetBeans GUI icons, who drew them?

Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.

On Sat, Apr 6, 2019 at 7:50 PM Tim Boudreau <ni...@gmail.com> wrote:

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


Leos Tronicek.

Gj


>

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 cached
> gradient BufferedImages vs GradientPaint and RadialGradientPaint with as
> much raster caching as you could do there - the result was blitting
> BufferedImages was 10x faster, and 40x faster if you ran a full GC between
> benchmark loops, meaning that performance with Paint objects is also much
> less predictable). One of the rationales for JavaFX's creation was to have
> a graphics toolkit that operated with the grain of how modern graphics
> cards work, rather than 1990s xterms did things.
>
> -Tim
>
> On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eb...@ultorg.com> wrote:
>
> > There are over 3000 bitmap icon images in the NetBeans codebase. Probably
> > at least several hundred of these are frequently seen by everyday
> NetBeans
> > users. The page below shows all the unique "gif" or "png" files that
> > existed in the NetBeans mercurial repo prior to the Apache transition:
> >
> > htps://people.csail.mit.edu/ebakke/misc/icons.html
> >
> > THE QUESTION: Does anyone know who actually designed and drew these
> icons?
> >
> > I assume some were cobbled together from various sources, but on the
> other
> > hand, many of the frequently visible ones (e.g. the ones in the toolbars)
> > seem to follow a quite consistent visual style.
> >
> > (This question relates to the effort of making NetBeans look better on
> > HiDPI/Retina screens; see separate email thread.)
> >
> > -- Eirik
> >
> > --
> http://timboudreau.com
>

Re: NetBeans GUI icons, who drew them?

Posted by Tim Boudreau <ni...@gmail.com>.

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 cached
gradient BufferedImages vs GradientPaint and RadialGradientPaint with as
much raster caching as you could do there - the result was blitting
BufferedImages was 10x faster, and 40x faster if you ran a full GC between
benchmark loops, meaning that performance with Paint objects is also much
less predictable). One of the rationales for JavaFX's creation was to have
a graphics toolkit that operated with the grain of how modern graphics
cards work, rather than 1990s xterms did things.

-Tim

On Fri, Apr 5, 2019 at 7:09 PM Eirik Bakke <eb...@ultorg.com> wrote:

> There are over 3000 bitmap icon images in the NetBeans codebase. Probably
> at least several hundred of these are frequently seen by everyday NetBeans
> users. The page below shows all the unique "gif" or "png" files that
> existed in the NetBeans mercurial repo prior to the Apache transition:
>
> htps://people.csail.mit.edu/ebakke/misc/icons.html
>
> THE QUESTION: Does anyone know who actually designed and drew these icons?
>
> I assume some were cobbled together from various sources, but on the other
> hand, many of the frequently visible ones (e.g. the ones in the toolbars)
> seem to follow a quite consistent visual style.
>
> (This question relates to the effort of making NetBeans look better on
> HiDPI/Retina screens; see separate email thread.)
>
> -- Eirik
>
> --
http://timboudreau.com

AW: NetBeans GUI icons, who drew them?

Posted by Christian Lenz <ch...@gmx.net>.

We should try not to find what happens last years, we should unifiy them all in all. And do it by our own. No need to ask what was the reason for that. Just use modern, flat Icons that are free, SVG will be best, convert them into PNG if SVG is not possible in Swing and use them.

Cheers

Chris

Von: Wade Chandler
Gesendet: Samstag, 6. April 2019 03:20
An: dev@netbeans.incubator.apache.org
Betreff: Re: NetBeans GUI icons, who drew them?

You're looking at nearly a couple decades of work. I doubt anyone could
track down all names etc or even every single source. The best info would
come from the hg logs is my guess.

Wade

On Fri, Apr 5, 2019, 19:09 Eirik Bakke <eb...@ultorg.com> wrote:

> There are over 3000 bitmap icon images in the NetBeans codebase. Probably
> at least several hundred of these are frequently seen by everyday NetBeans
> users. The page below shows all the unique "gif" or "png" files that
> existed in the NetBeans mercurial repo prior to the Apache transition:
>
> htps://people.csail.mit.edu/ebakke/misc/icons.html
>
> THE QUESTION: Does anyone know who actually designed and drew these icons?
>
> I assume some were cobbled together from various sources, but on the other
> hand, many of the frequently visible ones (e.g. the ones in the toolbars)
> seem to follow a quite consistent visual style.
>
> (This question relates to the effort of making NetBeans look better on
> HiDPI/Retina screens; see separate email thread.)
>
> -- Eirik
>
>

Re: NetBeans GUI icons, who drew them?

Posted by Wade Chandler <wa...@apache.org>.

You're looking at nearly a couple decades of work. I doubt anyone could
track down all names etc or even every single source. The best info would
come from the hg logs is my guess.

Wade

On Fri, Apr 5, 2019, 19:09 Eirik Bakke <eb...@ultorg.com> wrote:

> There are over 3000 bitmap icon images in the NetBeans codebase. Probably
> at least several hundred of these are frequently seen by everyday NetBeans
> users. The page below shows all the unique "gif" or "png" files that
> existed in the NetBeans mercurial repo prior to the Apache transition:
>
> htps://people.csail.mit.edu/ebakke/misc/icons.html
>
> THE QUESTION: Does anyone know who actually designed and drew these icons?
>
> I assume some were cobbled together from various sources, but on the other
> hand, many of the frequently visible ones (e.g. the ones in the toolbars)
> seem to follow a quite consistent visual style.
>
> (This question relates to the effort of making NetBeans look better on
> HiDPI/Retina screens; see separate email thread.)
>
> -- Eirik
>
>