Matching order causes issues with windows with dynamic titles.

[molguin92]

The documentation states:

Windows names are detected by inspecting in the following priority
- name
- title
- instance
- class

This causes issues with windows with dynamic names. Take for instance Firefox - if the current webpage title begins with a string matching any of the configured icons, the icon is changed:

• Normal Firefox window (name doesn't match anything other than Firefox):
  

• Visiting the Scipy signal processing toolkit documentation (matches the Signal icon):
  

• Searching for "Chrome" on Google (matches the Chrome/Chromium icon):
  

• Just to show that it's not just Firefox. I launched a terminal (Alacritty) and changed the title to Chrome using

while true; do; echo -en "\e]2;Chrome\a" && sleep 1; done

IMO, to prevent this, the matching order should actually be the inverse:

1. Class
2. Instance
3. Title
4. Name

I could do this myself (from looking at the code, it wouldn't even take 5 minutes), but I wonder if there's any specific reason the matching is done in that order?

[luukvbaal]

This can be prevented using regex anchors for an exact match e.g.: ^signal$ . Though with the current matching, this would have to be done for all icons which you want to match exactly, whereas icons which you want to match loosely can be entered normally in app-icons.json. Since the former is probably more common, perhaps the inverse behavior would be preferred (up for discussion).

Regarding the matching order of class, instance, etc., this is required because the class is usually the least specific/most static. Making class the top priority would prevent setting a specific icon for e.g. browser web apps which would always have the browsers' class and match with that instead of the web app instance.

[luukvbaal]

I also don't see this being too much of an issue. I think having regex matching as default is worth it vs the off chance that you might be googling for that term in your browser.

[molguin92]

Oh, I had not considered the fact matching was done by regex. That makes sense, and I agree - using anchors fixes my use case perfectly.

Can I suggest adding this to the README though?