cadence-launcher: cross-distro way for tools detection

[nick87720z]

As far as i remember, launcher detects tools via package-manager. This makes it useless in distros, using other PM, than apt (rpm-based, arch, etc).

There are two other ways for that:

1. PackageKit was designed as generic, cross-distro package management tool. So.. even installation of missing tools, registered in database, might be possible. Just like they did for codecs.
2. For cases, when pk doesn't work (either no backend or it is broken), presence of required executable (e.g. output of which) is enough to assume it available.

[falkTX]

...you're talking about claudia-launcher right?

cause if yes, it's 100% intentional.
there's no way to know if an app in a distro has a certain feature or not.
kxstudio for example has non-mixer with lv2 support, which is my own patch. no other distro includes that.
features are added in new versions of app (like muse getting vst fx support), so it's tricky to know if something is supported or not.

[nick87720z]

Oh, yep.
Yes, i heared, packagekit can only (de)install packages, but not tune their features.
However, how missing features may break app from launch and consider it unsuitable?
May be lack for both jack and alsa support might make it unsuitable for music session, but how it relates to plugin support?

[simonvanderveldt]

@falkTX Why is knowing which features a certain application supports necessary?
Is it only for the UI to fill in the "Plugin support" check marks or for something else?

[falkTX]

The idea was for each distro to modify the list as needed.
Considering cadence is on 0% of distros, this doesn't matter anyway.

[simonvanderveldt]

In that case would it be an option to simplify the detection of applications from the list/database to checking if the executable exists?

[falkTX]

problem with that is missing icons.
if it's a package we know where the icon is and what its name is.
but not sure how important that is.

I guess searching for binaries will make sense...

[simonvanderveldt]

Regarding missing icons, an alternative option could be to read the .desktop files in /usr/share/applications, they should have an Icon value.

[falkTX]

hmm yes, in that case we should look for desktop files instead of binaries.

[simonvanderveldt]

hmm yes, in that case we should look for desktop files instead of binaries.

Well, both using the XDG spec as well as trying to use the icons defined in a .desktop file seem to be more effort than it's worth:

• There's only 1 python package implementing the XDG spec including the handling of .desktop files. https://github.com/takluyver/pyxdg It hasn't been updated since 2014. so even if it would still work today it's pretty much a given it will fail to work at some point in the future, be it because the XDG spec changed or because it's no longer compatible with the python version the launcher is compatible with.
• Getting the icon seems to be pretty hard as well, because there's apparently no way to get the icon as the desktop environment sees it. In other words if a user uses an icon theme it's pretty difficult to get the correct icon, and knowing how to get it depends on how the desktop environment works. Not a can of worms you want to open.
  See http://askubuntu.com/a/66424 and a GTK specific example http://stackoverflow.com/a/15286059-
  Scratch that, I had a look at the code and noticed you already have something that works relatively well in place using Qt's QIcon.fromTheme and some default path's as a faillback.

So keeping the above in mind, I think a simple check if the executable exists might save a lot of headache :)
A simple shutil.which() would be enough to check if an executable exists.

[simonvanderveldt]

Allright, so code reading and trial and error further :)

problem with that is missing icons.
if it's a package we know where the icon is and what its name is.
but not sure how important that is.

@falkTX I might be misunderstanding you, but knowing that a package is installed doesn't give us any kind of information about if and where the relevant icon is placed, right?
I've just replaced the if SHOW_ALL or Package in pkglist:with if SHOW_ALL or shutil.which(Binary): in claudia_launcher.py#L705 I get the relevant icons just fine.

The only issue is that it's actually showing a different icon than I'm using in my theme. For example for LMMS, the way the code is right now I get the icon from this repo.

If I don't add the /tmp/.claudia-icons directory to the themeSearchPath by commenting out claudia_launcher.py#L160 I get the following, which seems to be the default icon for LMMS included with the package I've installed.

If I disable the QIcon.setThemeName("claudia-hicolor") from
claudia_launcher.py#L161 I do get the icon from my actual theme. It's a bit squashed though the way it's shown in the right panel.

So 3 conclusions/observations:

• No difference between checking if a package is installed vs checking if an executable exists with regards to the icons
• The way the icons are looked up through the theme(path) tree seems to be the wrong way around
• Note the missing cross/checkmark icons here and there. IMHO it would be a lot cleaner to use a read-only QCheckBox or a plain yes/no string to show if those options are enabled.