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/06/01 15:23:12 UTC
RE: NetBeans GUI icons, who drew them?
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
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
>