> 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 <[email protected]> Sent: Monday, June 3, 2019 6:24 AM To: dev <[email protected]> Cc: [email protected] 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, <[email protected]> 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 >
