On Mon, Apr 8, 2019, 01:58 Antonio <anto...@vieiro.net> 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
