Closed Batwam closed 1 year ago
Thanks @Batwam. Looks and behaves well, i will merge it right now.
I agree a whitelist isn't useful on it's own (i will add something to make it more useful in a bit), and maybe we can make it disappear if we add a call to this.players.next()
at the end.
First pass proposal for filter implementation. This is in relation to https://github.com/Moon-0xff/gnome-mpris-label/issues/4#issue-1463356957
Note that I am only doing a blacklist filtering here. I am not sure why we might require a white list?
The implementation should be self-explanatory but basically, I tried to keep it as simple and robust as possible by simply checking if the
source_name
is somewhere in the blacklist. I tested this and it worked fine. I can't really think of any case which would create "false positives". The added benefit is that if the user takes some freedom on the syntax, adding spaces or using semicolons (or any other separator), it would still work since theSOURCES_BLACKLIST
syntax which is the one the user enters manually doesn't matter much.The only small thing I noticed is that if the currently playing source is blacklisted by a user, it won't disappear right away which would be neat. It will have to wait until the source is changed manually/automatically or the extension reloaded. Once it's flushed out, it won't come back. It's a bit of an edge case but I just wanted to point it out in case you notice it too. I had a quick look to see if I could address this quickly but I didn't really want to start updating
extension.js
as this could start introducing some unintended regressions.Let me know if you want me to update the merge request to be against
main
rather thanfilter-list
.PS: obviously, all chromium based browsers will end up being filtered as the same time but that's kind of inevitable