shemnon
commented
12 years ago These are some great architectural critiques.
It is important to note that insubstantial is principally in maintenance mode. Any changes that I post are all precipitated by bugs from my day job, and I personally lack the time out of work to engage in any refactoring.
Since this is also something that hasn't impacted my use, I also doubt my refactoring would achieve the described goals.
Even though I am closing this specific bug, I am not adverse to the ideas expressed in it. I just feel it should come in as a pull request.
kschaefe
BaseColorScheme API only allows the use of one of two SchemeDerivedColors (DerivedColorsResolverLight or DerivedColorResolversDark). While I can replace the color resolver on my BaseColorScheme subclass, the other BaseColorScheme subclasses will not take advantage of this. Here's an example:
DeriviedColorsResolverLight resolves getBackgroundFillColor to sheme.getExtraLightColor, getSelectionBackgroundColor to scheme.getExtraLightColor and getTextBackgroundFillColor to an interpolated value. Our color scheme would like to switch have getTextBackgroundFillColor to scheme.getExtraLightColor and getSelectionBackgroundColor to an interpolated value around scheme.getMidColor. I can easily do this, but anytime Substance derives a new SubstanceColorScheme, the derived schemes simply check the original scheme's isDark method to determine which resolver to use. If I want to propagate my specific resolver, I basically need to reimplement every class in the SubstanceColorScheme area.
If SchemeDeriveColors were redesigned as an immutable, flyweight then it could be shared between various color schemes. The BaseColorScheme subclasses that handled the DerivedColorSchemes could simply copy the resolver of the original BaseScheme without any issues.