search

Tomas-M / xlunch

Graphical app launcher for X with minimal dependencies
http://xlunch.org
GNU General Public License v3.0
219 stars 37 forks source link

Auto detect applications #73

Closed Tomas-M closed 6 years ago

Tomas-M commented 6 years ago

New feature to consider.

Since I released Slax, I got lots of feedback for xlunch, and most commonly asked question was how to make xlunch autodetect .desktop entries instead of using static dsv. Because people install new stuff with apt-get and they expect to see icons added to the list automatically.

I know that there may be ways how to update the entries.dsv file automatically after apt-get. I know that lookup for .desktop files and their parsing may be time consuming. Also I know that icons lookup is even more painful if we really want to find some usable icon, since not all icons of all sizes exist. But I think if we support .desktop entries just partially, in a very simplistic way, ignoring entries with non-existing icons for our iconSize, it will be sufficient for vast majority of users. So I'd like to suggest few things which will simplify lookups.

If we're going to support autodetection of applications, we need to:

1) examine only one directory to search for .desktop files. By default it should be: /usr/share/applications

2) consider each .desktop file as a candidate for application, and examine lines starting with Name= Exec= Icon= Hidden=

3) examine only one direct file to search for icon. By default, it should be /usr/share/icons/{themeDir}/{iconSize}x{iconSize}/apps/{iconFileName}.png

So only files of name {iconFileName} (as configured by the Icon= parameter in .desktop file) are considered, with only png extension (no other extensions), and only in apps subdir. And applications where Hidden!=true and icon of given size exists, are added to the list.

This way, the lookup will be very fast, since we do only one glob() search for .desktop entries and and only one open() for each icon.

PMunch commented 6 years ago

Yeah I've thought about this a couple of times. On Arch (or other distros using the AUR) this is solved pretty nicely by installing a post-install hook with xlunch. The genentries script supports generating the icons and entry line for a single given .desktop file which is leveraged by passing the programmed installed to the script and appending the new entry to the entries.dsv file. This means that the entries.dsv file will always be sorted when installing/removing programs.

But that is a special case solution and depends on the package manager. The way you suggest however has several issues.

  1. It's not Freedesktop compliant, many icons will be wrong by doing it this way. The script isn't 100% compliant either, but it's pretty close.
  2. It requires us to reimplement many features of the genentries script in the C code, and maintain both.
  3. It won't support svg images. Many themes, including popular ones like Breeze and Papirus, are svg only and wouldn't work at all.

Because of this I'd like to suggest another option. Include a script that wraps the execution of xlunch. When run it will run a simple command to check the relevant applications directories (typically /usr/share/applications and $HOME/.local/share/applications) for .desktop files. It will then generate the correct entries line for each of the applications and store both the line, and the timestamp/file combination that generated it in a cache. Next time it is run it will compare the timestamp and folder names in the cache against what exists in the application directories and generate new/modified entries and add them to the cache. Finally it will extract all the entries and run xlunch. In the cache we also need to store the current icon theme as well, but I don't think we need to store the name of each icon. If the user manually modifies icons I think it's fair to let them manually delete the cache.

This has a number of benefits:

  1. Uses the existing script with support for svgs and mostly Freedesktop compliant
  2. Will automatically detect changes and only regenerate the changed entry
  3. Won't require maintaining two copies of code that does the same thing

The only disadvantage of this over the AUR post-installation hook method is that the load is moved to the start of xlunch. This means that after installing a program xlunch might take a bit longer than usual to start, especially if it's converting an icon from svg to png.

Tomas-M commented 6 years ago

This is good idea :) I think it will be sufficient for my purposes.

So I will make a simple script to work just the way I suggested since that is perfectly sufficient for me, I don't really need to care about svg icons, and it should be hopefully quick to start every time before xlunch, even without caching.