pop-os / freedesktop-desktop-entry

Rust crate for navigating Freedesktop desktop entries
Mozilla Public License 2.0
32 stars 17 forks source link

Hardcoded paths in `default_paths` ignore local setup #2

Closed WhyNotHugo closed 2 years ago

WhyNotHugo commented 2 years ago

The default_paths function currently returns a list of hardcoded paths: https://github.com/pop-os/freedesktop-desktop-entry/blob/ccb4e86e801f603041d8cae5205138f9ea2a26f8/src/lib.rs#L287-L318

This has two problems:

Both problems can results in unexpected behaviour inconsistent with system setup. The correct approach is to use XDG_DATA_DIRS, which will include the paths in the above linked function (if appropriate), but many include additional paths configured in the local system. For example, in my current setup it's:

/home/hugo/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/

Note that /usr/local/share/ is currently ignored by default_paths().

mmstick commented 2 years ago

Yeah that'd be fine to change it to generate one automatically, provided it still catches and can identify common paths and come up with a way to describe non-standard ones.

WhyNotHugo commented 2 years ago

I can try and write up a PR on this. Do you mean caching as in: reading them all once and not parsing them on each call? That'd make sense, since, AFAIK, an environment variable cannot change at runtime.

come up with a way to describe non-standard ones.

Describe them how? As in system-wide, user-wide, flatpak-specific, etc?

Some "guessing" can be done, but if someone has added a path like /opt/my-tools/applications, that won't match any of the existing PathSource. Even /usr/local/share/applications (which is very standard) doesn't quite match any of the existing ones: it's technically site-local, but Local seems to have a different meaning here...?.

The naming of PathSource is a bit odd -- /usr/local/share is a Local one, but it seems that user-specific ones are called Local... maybe they should be called User? That would be a breaking change though, and I'm not very sure what PathSource is used for, so a bit hard to say what's best.

What's the intended use of PathSource? (I'm mostly using the other bits of the desktop parsing, tbh).

mmstick commented 2 years ago

pop-launcher is the only consumer, and it's purely cosmetic, so breaking changes are fine. It can be helpful to know if an application being launched is from a Flatpak, or a system application, Nix, etc.

Caching not necessary.