Up until now, ColorSelect would generate a transparent color, and so the black base layer was required to fix it. However, with better type detection ColorSelect isn’t transparent anymore, which means that the compiler will complain.
This can be fixed of course, I could allow non-transparent layers in the middle of the stack, but I’m not sure if that’s a good idea.
On the other hand, I don’t really want to break backwards compatibility either…
I will allow non-transparent layers to follow “Black” in the layer stack.
So the case above will compile, but if you change the “Black” to yellow, or any other color then it won’t work anymore.
How does this impact ColorSelect<> without TrSelect<>, etc? I use ColorSelect<> throughout the library for many other effects, not just the base layer, including for “masking” layers that contain a mix of transparent and solid layers to be used at various points. I can’t recall if any currently use TrSelect<> or TrRandom<> though, I’ll have to dive into the scripts a bit to check.
I know I use ColorSelect<…,…,AlphaL<White,Int<0>>, Solid> in quite a few instances though to turn on or off masking layers.
That could work for some uses but I have to look closer, a lot of uses were written a while ago, this was just an example. Also, there’s a high chance these uses are already “in the wild” so changing the behavior would make existing configs no longer work correctly in the next OS. I’ve been incorporating various applications of ColorSelect for many effects for a while now, especially since OS7 released so changing an existing behavior may impact compatibility going forward for users even if I find alternatives moving forward.
What are the downsides of allowing an opaque layer over something not Black? If the style is written to intentionally cover another opaque layer I’d think we’d allow? Is it possible to just counteract the change by allowing ColorSelect to cover other layers, especially if they were built to specifically do that?
Less strictness allows more bugs basically.
Opaque layers will overwrite the base color unconditionally. I can’t imagine a case when someone would do that on purpose.
Note that ColorSelect<A,B,Transparent, Opaque> is not an opaque layer, not even some of the time. ColorSelect can only return one type of color, and that type will be transparent since an opaque layer can be transformed into a transparent one without loosing any information. (The opposite is not possible.)
I agree that is bad. However, I think the vast majority of cases will either:
a) already work
b) be fixed by allowing Layers<Black, Opaque>
If not, we’ll hopefully find it in the alpha/beta phase and I can fix it then.
When it comes to AlphaL vs. ColorSelect: both will continue to work, I just think AlphaL might be more efficient.
Let me try to dive into the library scripts to see any other uses, I can’t recall if I have TrSelect<> or TrRandom<> on the ColorSelect<> layers that are meant to “mask” the base layer (which would mean not “Black”). If there are none in the library then there’s nothing on my end to worry about. I just have a nagging feeling I have some effects that use ColorSelect<> and TrSelect<> together for some uses, while I may be able to rewrite they may already be out “in the wild” so we’ll need a contingency.
Ideally you shouldn’t have to rewrite anything.
Please let me know if you find something that doesn’t work as it should on OS8, and I will try to fix it.