Closed luukvbaal closed 4 years ago
Sorry about the delay on this, haven't had a chance to look this over properly. I do worry though that this change might cause issues with config. Thank you for your contribution.
I've had some time to look over the code, and this has the potential to break things, I'd hesitate to merge it as is. I need to consider including wm instance in a new release at some point but I don't have time currently. Sorry for wasting yours. I'll leave this pull request open for now, and I'll look back into it when I have the chance.
Sure no problem. I haven't encountered any issues myself though so I'll keep using it for now.
I'm gonna close this pull request, I've published a version that borrows from this PR, and I've added you to the contributors list, since your PR was the inspiration for the latest version, just needed some tweaks.
Disclaimer: I never worked with rust before so I might have butchered the implementation but it does work. If I follow the code correctly, this PR will check if
WM_INSTANCE
is present in the config file and use that to match the icon. If no match is found it will still useWM_CLASS
. But I'm not 100% sure of this as I am not sure I quite understand theOk()
return used here.My goal here is to allow differentiating
WM_INSTANCE
fromWM_CLASS
and having it take precedence sinceWM_INSTANCE
is usually more specific as far as I know. Where this comes up for me is when using browser web-apps for instance by runningchromium --app="https://web.whatsapp.com"
. This PR allows the following behaviour: with both icons coming from the sameWM_CLASS
but differentWM_INSTANCE
. Feel free to adapt to rust coding conventions as I have no idea what I'm doing.