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 <[email protected]>
Sent: Monday, June 3, 2019 7:37 AM
To: [email protected]
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 <[email protected]>
Sent: Thursday, April 11, 2019 3:13 AM
To: [email protected]
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: [email protected]
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=x6h...@mail.gmail.com%3e
[2]
https://jaxenter.com/netbeans/netbeans-retina
El 06/04/2019 a las 19:50, Tim Boudreau escribió:
I did most of the icons in 1999 (a few of them still exist in core
as
tree
icons for nodes that are not typically shown anymore); in 2000 they
were taken over by Sun's Human Interface Engineering team, and
everything was converted to the (awful) "flush 3d" metal look and
feel look. Circa 2004
we
got out from under the tyrrany of metal look and feel, and they were
redesigned again by a guy whose name I can't remember, but could
probably dig up - that redesign established the shapes still in use
for things
like
classes, fields and methods. Since then there was one reworking of
the icons that made them more cartoonish (I remember Wade calling it
"NetBeans
for babies").
I think in the long run, switching to vector icons is smart. That
said, I would not run with SVG without precompiling it into code
that drives a Graphics2D and either renders and caches images, or
deals with
performance
and memory allocation issues around GradientPaint and friends in the
JDK (both allocate large rasters on every paint, and vertical and
horizontal and radial gradients can be cached and reused instead -
AND the pixel pushing approach of those has a serious impedance
mismatch with modern graphics pipelines - it happens that just this
week I benchmarked 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 <[email protected]> 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: [email protected]
For additional commands, e-mail:
[email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
