[Launcher] Better mapping between favourites, executables and window classes

[JakeStanger]

Is your feature request related to a problem? Please describe.

The launcher favorites option accepts any value that xdg-open takes, but for grouping to work this value has to match that of the window app_id / class.

Describe the solution you'd like

Either the favorites or grouping logic (or both) should be smarter to make it easier to configure. Some well-knowns should be handled without requiring user configuration.

Describe alternatives you've considered

None yet.

Additional context

Discussed in #465.

Properties in the .desktop file such as StartupWMClass may potentially lend a hand.

[slowsage]

Two thoughts:

1. How compatible is gtk-launch with wayland? Can we use that as a guide? gtk-launch code works vs code-url-handler in ironbar favorites.
2. Apps using older version of electron do not set class properly (eg: Spotify). Maybe this sort of mapping can be set in the config versus requiring users to modify desktop files with StartupWMClass. Corn config allows mixed types. So maybe something like:

    $launcher = {
        type = "launcher"
        favorites = ["kitty" "code" {name: "spotify", title: "Spotify Premium", class: ""} ]
    }

When an entry is not a string:

• name corresponds the part before .desktop
• title - will match and track the window with that title exposed through wayland.
• class - same as title

title and class are optional. When only one is specified, the launcher entry is matched with that value for title or class. When both are specified, it should match both (AND).

One thing I am unclear on is initialTitle and initialClass and how that can be mapped/tracked.

[JakeStanger]

Ironbar currently uses gtk-launch to start favourites. This is probably why it's relatively smart in its current state.

Spotify is CEF rather than Electron, not that it matters too much. I'll have a look at that one in particular because there should be a way of identifying it properly without needing to parse a desktop file.

I'd consider reading the desktop files a last resort. That said, there is already code for doing exactly that to pull out icons. Some tweaks there if necessary would give us a service + cache for any additional properties we would need.

I generally stay clear of mixed types where I can, but I think you're right to suggest it here. It may be that this is a place to introduce some pattern matching.

[slowsage]

Re: Spotify see this.
+1 on the pattern matching - regexes to track windows would be great.

I also think instead of name we can use launch or something that cannot be confused with name/app_id/wm_class in the code (which uses file_name).