sfimage parameter is not effected by sfcolor
bringel opened this issue · 6 comments
Describe the bug
While working on a plugin, was using the sfimage and sfcolor parameters on my output expecting the color to change. This did not work until I changed to using the :sfsymbol.name.here: syntax in the text part of the output.
To Reproduce
Steps to reproduce the behavior:
- ...
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment:
- macOS version:
- SwiftBar version:
Plugin Example:
Sample plugin to reproduce the issue, link or code.
Additional Context:
- I don't run Bartender/Dozer/etc. or tested the issue without it running
I believe this would be a breaking change for existing plugins - right now sfcolor sets the colour of inline symbols in the menu item text. Making this change would mean existing plugin scripts that already use sfcolor for inline symbols, and which also use sfimage, would end up with weird / unwanted colours set for sfimage.
It's worth figuring out how to enable this, just calling out that it might not be so simple.
Personally I'd be more worried about having a confusing/overly-complicated API than backwards-compatibility: the plugin ecosystem is small and plugins are easily hackable.
But if this is a concern, adding an sfimagecolor parameter would make sense to me.
It's not just that - this would effectively link two unrelated symbols to the one colour directive, so something would have to change either way. One alternative I can think of would be to simply consider sfimage when counting the indexes for sfcolor, so if sfimage is present then it's considered to be at index 0, and inline symbols would then start from 1.
For reference, I was testing a beta build for an unrelated issue and found that multiple scripts of mine were all broken with random icon colours, now I know it was this change being tested :)
Ah, gotcha. Assigning the sfimage index 0 in the sfcolor list (would that be sfcolor0?) would work.
Not sure if there's precedent for this, but what about extending the format of sfimage so that it could take colors as extra parameters? For example: sfimage=exclamationmark.triangle,#ffe000,#ffffcc This could keep the color information "closer" to the symbol name, which might be nice.
It's already merged: #370
And yes, there are still some edge cases. This format takes the color for the first SF color. If you had an sfimage and inline icons, the color of the sfimage and the first sficon would be the same.
Is there a workaround for the concern I raised above? My scripts that use sfimage and inline icons now share a colour that was only intended for the inline icon. Indexing all available icons from 0 (starting with sfimage) or something would help