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 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?
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-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NetBeans GUI icons, who drew them?
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 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?
On Sat, Apr 6, 2019 at 7:50 PM Tim Boudreau 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 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?
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 wrote: > On Sat, Apr 6, 2019 at 7:50 PM Tim Boudreau 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 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?
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 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
Re: NetBeans GUI icons, who drew them?
> On Apr 7, 2019, at 5:25 AM, Christian Lenz 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-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: 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-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NetBeans GUI icons, who drew them?
On Mon, 8 Apr 2019 at 06:58, Antonio 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-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NetBeans GUI icons, who drew them?
On Mon, Apr 8, 2019, 01:58 Antonio 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?
== Precompiling > > As Tim points out we don't want to waste CPU/GPU time rendering > gradients for icons at runtime. > > We could define some "standard" sizes for icons and precompile them to > these sizes. Very much like native mobile apps do for Android an iOS. In > iOS, for example, they have @1x, @2x, @3x suffixes for different icons > sizes. > > That, of course will require a project/repository of its own. > I don't think so, regarding a repo. Either: - Compile them to images of several sizes when building the module jar (from reading the comments in VectorIcon, it sounds like particularly on Windows hidpi, this can vary wildly, so I'm not sure this is a perfect solution), or - Compile them to a Java class that adds up to "painting instructions" (much faster load time and no dep on batik) - it's not that hard to write a Graphics2D implementation that outputs Java code for everything done to it, so you could load an SVG image into Batik, and have it paint into that and generate a class from the result); on first load, load it, paint it into a BufferedImage and save that to the IDE's cache directory, subdirectory by screen resolution, with the SHA-1 hash of the original SVG as the name. - Or, let the installer do this at the end of install - it actually knows the screen resolution likely to be needed, so that is the perfect time to do it, and let the IDE do the above for anything missing I don't think a repository just for icons solves much of anything, and probably creates some new problems. If you have a checkout of the IDE, `find . -name *.svg` does a fine job for locating everying; disconnect them from the code that uses them, and you're guaranteed to wind up with a pile of old icons used by nothing that nobody is sure if are unused or not. -Tim > > > == Standardizing > > If we're to precompile icons we may also want to standardize them > somehow. We could separate icons by cluster (in the repository above), > and create a cluster-specific module responsible for returning icons (of > appropriate size depending on DPI) for all modules in that cluster. > > The objective being making all "folder" icons look similar. We now have > blue folders and yellow folders all around. > > == Generating SVG from PNG > > See Tim's response in another thread [1]. I think Emilian set up a > website in 2017 to do this [2]. > > I don't think automatic conversion is worth the effort: we'll end up > having to fine-tune the results by hand, as Emilian tried to do back in > 2017. > > Also note that Adobe Illustrator seems to have a way to do this: > > https://www.lifewire.com/use-image-trace-in-adobe-illustrator-cc-2017-4125254 > > Cheers, > Antonio > > [1] > > http://mail-archives.apache.org/mod_mbox/netbeans-dev/201904.mbox/%3cCA+qecRNnE=L49v5t46q_LVc=rpTqJD3U7zt4-0DAroG=x6h...@mail.gmail.com%3e > > [2] > https://jaxenter.com/netbeans/netbeans-retina > > El 06/04/2019 a las 19:50, Tim Boudreau escribió: > > I did most of the icons in 1999 (a few of them still exist in core as > tree > > icons for nodes that are not typically shown anymore); in 2000 they were > > taken over by Sun's Human Interface Engineering team, and everything was > > converted to the (awful) "flush 3d" metal look and feel look. Circa 2004 > we > > got out from under the tyrrany of metal look and feel, and they were > > redesigned again by a guy whose name I can't remember, but could probably > > dig up - that redesign established the shapes still in use for things > like > > classes, fields and methods. Since then there was one reworking of the > > icons that made them more cartoonish (I remember Wade calling it > "NetBeans > > for babies"). > > > > I think in the long run, switching to vector icons is smart. That said, I > > would not run with SVG without precompiling it into code that drives a > > Graphics2D and either renders and caches images, or deals with > performance > > and memory allocation issues around GradientPaint and friends in the JDK > > (both allocate large rasters on every paint, and vertical and horizontal > > and radial gradients can be cached and reused instead - AND the pixel > > pushing approach of those has a serious impedance mismatch with modern > > graphics pipelines - it happens that just this week I benchmarked 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 wrote: > > > >> There are over 3000 bitmap icon images in the NetBeans codebase. > Probably > >> at least several hundred