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=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 <eba...@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-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
