mumble-voip/mumble — pull request #1461 by mkrautz (2014-11-02 22:58:00+00:00)
Title: Proposal: ensure up-to-date built-in overlay blacklist.

Things are only added to the built-in blacklist if they
create real problems for users. Most recently, I added
Spotify to the list because it could cause my Mumble
client's main thread to hang. (Causing, for example,
in-progress push-to-talk to continue transmitting until
Mumble un-freezes.)

Right now, the overlay DLL only uses the built-in blacklist
if nothing is specified in the registry key for the blacklist.
However, if a blacklist is specified in the registry, that list
is used, disregarding any new items added to the built-in blacklist.

Right now, the client doesn't try to solve that issue, but it seems
to me that it really is a problem.

After I added the spotify.exe entry, it wasn't added to my blacklist
until I wiped the blackley key in my registry.

Since this behavior of the built-in blacklist would mask a bugfix from
*all* existing Mumble users, I think it's time to revisit how we treat
the built-in blacklist.

This changeset makes the following modifications:

1. The overlay DLL is changed to always consider the built-in blacklist,
even if a blacklist is present in the registry.
For Mumble users who have been running with the old blacklist behavior,
this means that we'll be doing some duplicate checking for blacklist
entries, but I don't think this matters in practice.

2. Settings.cpp is changed to not do anything with overlay_blacklist.h.
Effectively, this means that qslBlacklist now represents the items
the user has added to the blacklist, and not the combination of both
an outdated built-in list and the user's own entries.

3. OverlayConfig.cpp is changed to always show all entries from
overlay_blacklist.h. Entries from the built-in list are 'disabled',
so they can't be interacted with.
Possibly not the best UX for signalling that the items are from the
built-in list. I'm open to ideas for how we should show it.
I think this is fine for now, though. See screenshot below:

![image](https://cloud.githubusercontent.com/assets/36527/4877284/a7f8098e-62e3-11e4-957f-4270fa58a88a.png)

I think this is a very reasonable way to handle the built-in blacklist
going forward. And the amount of code changed is minimal.

Comments welcomed.