Run update-mime-database and update-desktop-database

[probonopd]

According to https://discourse.appimage.org/t/how-to-use-linuxdeployqt/275/15, appimaged should run

update-mime-database $HOME/.local/share/mime
update-desktop-database $HOME/.local/share/applications

(if these commands are available on the $PATH) in order to work correctly.

Note: This should not be done after each AppImage processed by appimaged in order to save CPU power, but only after the system has quiesced (e.g., no further AppImages have been processed in the last X seconds).

[TheAssassin]

Awesome idea. That might even fix these issues on e.g., XFCE, where the launcher won't show icons of recently integrated desktop files.

[probonopd]

Note: This should not be done after each AppImage processed by appimaged in order to save CPU power, but only after the system has quiesced (e.g., no further AppImages have been processed in the last X seconds).

Semi-OT while we are at it: I believe that some desktops do this kind of thing automatically; hence we should extract everything that we want to "install" to $HOME to a temporary location first, and then move everything into $HOME at once after the system has quiesced (e.g., no further AppImages have been processed in the last X seconds) - for the same reason.

[TheAssassin]

I don't think we should overengineer this. The commands run in a tiny fraction of a second on my host.

By the way:

> update-mime-database $HOME/.local/share/applications/
Directory '/home/user/.local/share/applications/packages' does not exist!

[KurtPfeifle]

@TheAssassin:

By the way:

update-mime-database $HOME/.local/share/applications/ Directory '/home/user/.local/share/applications/packages' does not exist!

Haven't you used the wrong command?

update-mime-database is for $HOME/.local/share/mime. Your $HOME/.local/share/applications/ should be used with update-desktop-database.

[TheAssassin]

You're right, @KurtPfeifle, thanks for noting this.

Calling this command correctly yields it takes really long, compared to update-desktop-database (15s < time < 30s). But we just need to call that command when actually installing files into that directory, which I'd say won't occur too often, as most apps don't add their own MIME types. @probonopd please confirm.

[cgarry]

"Awesome idea. That might even fix these issues on e.g., XFCE, where the launcher won't show icons of recently integrated desktop files."

When the icons do not show up I have found this fixes it: gtk-update-icon-cache PATH/TO/ICONS/

Details here: https://developer.gnome.org/gtk3/stable/gtk-update-icon-cache.html

[TheAssassin]

@cgarry awesome. I didn't get to testing this yet. Let's add this to the list of commands to run.

[cgarry]

I have just been testing my latest AppImage on a few different VMs with appimaged and I needed to issue all of the following commands to get it correctly working:

update-desktop-database ~/.local/share/applications/
update-mime-database ~/.local/share/mime/
gtk-update-icon-cache ~/.local/share/icons/hicolor/ -t

Note the -t option was required with the gtk-update-icon-cache command.

[TheAssassin]

What exactly does that parameter -t do? What platform(s) did require that flag (and which one didn't)?

[cgarry]

Without the -t option gtk-update-icon-cache just returns the error: No theme index file.

From https://developer.gnome.org/gtk3/stable/gtk-update-icon-cache.html:

--ignore-theme-index, -t Don't check for the existence of index.theme in the icon theme directory. Without this option, gtk-update-icon-cache refuses to create an icon cache in a directory which does not appear to be the toplevel directory of an icon theme.

The -t option will be required on all platforms where there is no index.theme file present in the specified icon directory. So I think it is sensible to always use it. This was tested on Ubuntu 16.04. where I deleted a previous version of my AppImage and added a new version.

[TheAssassin]

I think we can assume the parameter is safe to use on all platforms, if it only disables a check.

[TheAssassin]

I just tried this on Nitrux (Plasma 5 based), and it seems like the gtk-update-icon-cache command doesn't fix the issue of icons not being shown in the launcher.

[TheAssassin]

CC @azubieta https://github.com/nomad-desktop/nx-software-center/issues/13#issuecomment-359274215

[cgarry]

"I just tried this on Nitrux (Plasma 5 based), and it seems like the gtk-update-icon-cache command doesn't fix the issue of icons not being shown in the launcher."

@TheAssassin I just tried this with a fresh install of Nitrux and it worked for me. Though I did have to log out and in again before the icons appeared.

[TheAssassin]

@TheAssassin I just tried this with a fresh install of Nitrux and it worked for me.

I was using a live ISO.

Though I did have to log out and in again before the icons appeared.

This is what we're trying to avoid. Users shouldn't have to log out and log in again.

[probonopd]

The commands run in a tiny fraction of a second on my host.

In this case I wonder why they don't get automatically run by the system (as in: GNOME, KDE Plasma, XFCE,... and/or systemd) "when needed" (using something like inotify on the directories that hold desktop and icon files), independently of appimaged.

[TheAssassin]

You mean, like appimaged does? There's a lot of issues to consider when implementing file system scans to automate processes like updating caches automatically.

Let's compare it to appimaged. appimaged's "initial" file scan can take very long, as it reads every single file in all the directories, and produces high IO load on systems with big Download folders. I guess you never run into this, given you're a distro nomad living off live ISOs, but please bear in mind the average user's directories will become larger and larger every day.

Same goes for inotify, by the way. Consider someone's compiling a program "by accident" in their Downloads directory, inotify notifications will go wild, and appimaged has to actually open and read all these files, as it doesn't filter files by their suffix (which is something I'd vote for, by the way, I mean AppImages which don't carry that suffix should just not be considered, that'd reduce the workload to a minimum).

Desktop environments probably made the same considerations, and don't perform all these actions when they might seem to be necessary. On Linux, in contrary to macOS, where you don't have so many different systems that need to work together with each other, so it's fairly easy to perform actions like these, as directories for screenshots and alike data are much more hidden from the user, it's easier to run cache updates, I'd say.

It's nearly impossible to expect everything working on macOS to work the same way on Linux. One can try to implement those features and have more automation in processes. But when limitations are found which can't be worked around easily, developers have to accept this.

By the way, I believe macOS doesn't scan file systems or use something like inotify to be notified for anything. It's much more likely that the tools installed on macOS trigger events like "application downloaded", causing the necessary processes to be run by the system. A push system is, by far, more efficient than any inotify based solution. So why not implement these cache updates as a "push"-like system in appimaged? Whenever there's AppImages to be integrated, we should either notify the system it has to run cache updates (if possible, probably also possible by calling a command, similar to running the update commands directly) or run the cache update commands directly.

[probonopd]

By the way, I believe macOS doesn't scan file systems or use something like inotify to be notified for anything. It's much more likely that the tools installed on macOS trigger events like "application downloaded", causing the necessary processes to be run by the system. A push system is, by far, more efficient than any inotify based solution.

We should actually try to find out how they do it. It's so beautiful - this kind of stuff "just always works" without having to fiddle around.

https://developer.apple.com/documentation/coreservices/launch_services

[TheAssassin]

The problem is, in macOS, such functionality is integrated well with the rest of the system. You could only implement it "like they do it" if AppImage was supported directly by a DE. Auxiliary daemons can't integrate that deeply if the DE lacks the relevant features.

appimaged will probably always remain a "workaround" solution for desktop integration. Perhaps you should start lobbying for AppImage supports in desktop environments.

[probonopd]

I am talking about registering icons and mimetypes and such, nothing specific about AppImage.

[simoniz0r]

On all of the DEs/panels/file managers/etc I've ran, simply having the MimeType in the application's .desktop file and placing it in either ~/.local/share/applications or /usr/share/applications is enough for the app's mime types to be detected and for it to be added to my menu after the menu cache is rebuilt. AFAIK, doing xdg-desktop-menu forceupdate should be enough for adding the app to the user's menu.

For example, I use the tar.gz package for VSCode. After taking the .desktop file from the deb package of VSCode, modifying it to point to the proper directories, and placing it in ~/.local/share/applications, spacefm knows without me configuring anything that VSCode is an editor. Before placing the .desktop file, the mime types are not detected. I really don't think this is something that appimaged needs to worry about doing; if the app's author creates the .desktop file with the MimeType entry set, it should just work when the .desktop file is placed in ~/.local/share/applications.

This is what VSCode's .desktop file looks like:

[Desktop Entry]
Name=Visual Studio Code
Comment=Code Editing. Redefined.
GenericName=Text Editor
Exec=/usr/share/code/code %U
Icon=code
Type=Application
StartupNotify=true
StartupWMClass=Code
Categories=Utility;TextEditor;Development;IDE;
MimeType=text/plain;inode/directory;
Actions=new-window;
Keywords=vscode;

X-Desktop-File-Install-Version=0.22

[Desktop Action new-window]
Name=New Window
Name[de]=Neues Fenster
Name[es]=Nueva ventana
Name[fr]=Nouvelle fenêtre
Name[it]=Nuova finestra
Name[ja]=新規ウインドウ
Name[ko]=새 창
Name[ru]=Новое окно
Name[zh_CN]=新建窗口
Name[zh_TW]=開新視窗
Exec=/usr/share/code/code --new-window %U
Icon=code

[TheAssassin]

@simoniz0r the "adding to menu" part has been solved. We're now looking for a solution for another bug. The menu entries' icons are not shown, and we haven't found a solution to fix that problem.

[simoniz0r]

Perhaps it's a problem with the DE? Do icons for native software show up in the menu right after install? I haven't had any issues with this on Xfce, KDE, or LXQt.

[probonopd]

I did, with more than one of them. A DE restart is needed which we want to get rid of. The problem occurs (this is my hypothesis) when the directory we want to place an icon in did not exist at the time when the DE was launched.

[TheAssassin]

@simoniz0r not only @probonopd did, I have seen the exactly same issues on all DEs I tried so far, and other users report this regularly, too.

@probonopd can you test your theory? If that should be the case, I assume we should be able to work around this issue.

[simoniz0r]

The problem occurs (this is my hypothesis) when the directory we want to place an icon in did not exist at the time when the DE was launched.

That works fine on my end. Using lxpanel or lxqt-panel and running xdg-desktop-menu forceupdate finds the icons fine.

Personally, the only time I've had an AppImage's icon not show in my menu at all was when the AppImage didn't bundle the icon properly. No reboot/relog required for icons to show on my end.

[simoniz0r]

Also, I feel like you guys should be pressuring devs to make use of the desktopintegration script more so that appimaged doesn't have to add entries to the menu for them. Every AppImage that has a GUI should be asking whether or not the user wants a menu entry added.

With a couple of simple modifications to your current desktopintegration script (just add xmessage support), it could easily be a universal solution that would work on just about any Linux distro.

[probonopd]

Also, I feel like you guys should be pressuring devs to make use of the desktopintegration script more so that appimaged doesn't have to add entries to the menu for them.

In fact, we are thinking about deprecating it entirely, and encourage people to use the optional appimaged daemon instead.

[simoniz0r]

In fact, we are thinking about deprecating it entirely, and encourage people to use appimaged instead.

Please don't. I will not use appimaged on any of my systems. I really, really love the way that AppImages ask me to add them to my menu.

I honestly feel like appimaged shouldn't even have to be a thing. AppImages should be taking care of adding themselves to the user's menu themselves and also provide options for easily removing those files. Literally everything that appimaged does should be taken care of by the AppImage and not require an external tool to be ran.

Requiring appimaged for desktop menu integration steps away from your vision of how AppImage should work. They should not require external tools to function properly.

[TheAssassin]

I haven't had any issues with this on Xfce, KDE, or LXQt.

But then, you state:

Using lxpanel or lxqt-panel and running xdg-desktop-menu forceupdate finds the icons fine.

These two statements contradict. Did you even test the whole thing on the platforms you mentioned? I highly doubt it.

In fact, we are thinking about deprecating it entirely, and encourage people to use appimaged instead.

We don't just think about it. We're already working on it. Many AppImages don't ship with the desktop integration anymore.

An alternative to this is having desktop environments integrate AppImages, so an alternative daemon isn't necessary.

Please don't. I will not use appimaged on any of my systems. I really, really love the way that AppImages ask me to add them to my menu.

I honestly feel like appimaged shouldn't even have to be a thing. AppImages should be taking care of adding themselves to the user's menu themselves and also provide options for easily removing those files. Literally everything that appimaged does should be taken care of by the AppImage and not require an external tool to be ran.

Requiring appimaged for desktop menu integration steps away from your vision of how AppImage should work. They should not require external tools to function properly.

This is not the right place to discuss this topic. Also, you need to understand one thing: decisions are not made based on your or our or anybody's single, subjective, personal opinion. We analyze how other systems solve the problems we encounter, and which solution average users prefer (i.e., which one is easier to use, less work for the users, etc.). We really perform some research on those topics. And we accept when the results are on the contrary to what we think might be right. Just because you like the additional control, the average user often doesn't like to be bothered about such things. About desktop integration, for example, check out some YouTube videos about AppImages. A big share of video makers does not like these dialogs. Therefore, we consider to eliminate them. You really need to open your mind for the "average user" viewpoints. By the way, you are not the only one who suggests features a developer or advanced user might appreciate, while average users wouldn't. See #657 for example. Did you ever ask yourself how many things on your desktop are actually automatic processes you're not notified about or don't have a chance to confirm in before? The list is very long. For example, network connections, automatically started processes, ... The whole argument "I want to be asked" for the sake of being asked is bogus. Try to find some more objective reasons. I doubt there's many.

A general note on your discussion methods: You tend to post a "-1" on every explaining statement someone posts. This is really annoying, and not constructive at all. Instead, you discredit yourself, and your comments aren't taken seriously by people any more.

It is not like these postings would be any kind of "new" ideas which require user feedback. The purpose of such comments is to explain you decisions which have been made earlier. Posting a "-1" on an explaining post is just not quite appropriate. If you feel you have to re-discuss topics, consider posting your opinions on Discourse, the right place for conceptual discussions.

[simoniz0r]

Yes, I have tested it on the other platforms. I don't much like your tone, so I'm not even going to bother responding to the rest of that, tbh.

[probonopd]

Is anything blocking us from running update-desktop-database, e.g., once appimaged has not registered a new AppImage in the last 3 seconds?

[probonopd]

This is what apt actually runs:

Processing triggers for mime-support (3.60ubuntu1) ...
Processing triggers for desktop-file-utils (0.23-1ubuntu3) ...
Processing triggers for man-db (2.8.2-1) ...
Processing triggers for gnome-menus (3.13.3-11ubuntu1) ...

Maybe we need to run our version of this. Note that apt does not run this after each application installed, but only at the very end of the entire apt run (even if more than one application was installed).

[simoniz0r]

This sort of thing is something that should happen when the user runs the AppImage and never outside of that. The only valid alternative would be to have a package manager for AppImages that did these things when a user downloads the AppImage using the package manager.

Running these commands at random will bring up issues with lots of resources being used, unexpected things happening, etc. These commands are not things that you want to be running all the time; they take a pretty decent chunk of CPU to run especially if you're doing them at once or one right after another.

[probonopd]

@simoniz0r apppimaged is conceptually similar to what Launch Services does on the Mac. No "package manager" needed.

[simoniz0r]

I'm aware, but what you're trying to do isn't going to work at all.

[probonopd]

@simoniz0r sometimes you can be cryptic. What am I trying to do that isn't going to work?

[simoniz0r]

You are not going to be able to keep track of every AppImage a user has installed without some sort of standards set in place or bringing the user's system to a screaming halt every time appimaged tries to do things with a large amount of AppImages installed.

[probonopd]

Why? Isn't this what inotify is for? On the Mac, you can run applications from any place, there is no "installation". I want to replicate that user experience.

[simoniz0r]

You already can, but you should be doing this by having the AppImages basically "install" themselves the first time that they are ran and not by having an external application take care of it. There's no viable way that you will be able to watch every possible directory that a user would place an AppImage in and be able to keep track of them reliably without either having them "install" themselves or by having a small amount of standard directories for users to place AppImages in setup.

:EDIT: This self "install" could even be as simple as the AppImage creating a file in a directory that appimaged watches containing the path where the AppImage was last ran from. You could then have the AppImage pass an argument to appimaged to run the rest of the "install". Run appimaged's update checks once every 6-ish hours (it'd be nice if this time was configurable by the user to prevent bandwidth problems and such) and not on boot.

Also, a slightly unrelated side note, the AppImage update tools should be aware of GitHub's rate limit and possibly even allow users to login for checks made to GitHub's API if they are making use of GitHub's API. Only 60 checks per hour are allowed without authentication (this goes up to 5000 per hour with authentication); after you hit the limit, you just get an error response. A user could very easily hit that limit and even possibly raise some flags on GitHub's end if they continue to try to connect after hitting that limit.

[probonopd]

You already can, but you should be doing this by having the AppImages basically "install" themselves the first time that they are ran and not by having an external application take care of it.

In this case, you would need to run an application first before it is integrated. In a stateless (Live ISO) system this means that initially no applications would be integrated at all.

This self "install" could even be as simple as the AppImage creating a file in a directory that appimaged watches containing the path where the AppImage was last ran from.

This would reduce the number of directories to be watched with inotify from around 10 to 1, would that really make that big of a difference?

[probonopd]

Also, a slightly unrelated side note, the AppImage update tools should be aware of GitHub's rate limit

Please open an issue in https://github.com/AppImage/AppImageUpdate

[simoniz0r]

In this case, you would need to run an application first before it is integrated. In a stateless (Live ISO) system this means that initially no applications would be integrated at all.

I think that's pretty niche and should not be the default behavior. You should provide an option for appimaged to allow it to scan directories in the traditional method if you really want to provide that. The default behavior should be to watch the directory of files containing the last run location of each AppImage.

This would reduce the number of directories to be watched with inotify from around 10 to 1, would that really make that big of a difference?

It depends on how appimaged is handling this. If appimaged is processing each AppImage that it finds on boot and/or each time the check interval goes off, then yes, it more than likely would. If appimaged is only processing AppImages which haven't been previously added, then it probably wouldn't be as big, but either way, it's not going to hurt performance at all.

Watching this single directory would also make appimaged much more reliable for the average user. They actually would be able to put an AppImage pretty much anywhere on their PC and have appimaged keep track of it easily as long as they've ran it at least once. If the AppImage updates its location each time it is ran, the user would even be able to move AppImages at will and still have appimaged keep track of them easily. You could maybe even add like a --appimage-update-running-directory argument or something to AppImages which would allow them to offload this information without being ran.

[probonopd]

as long as they've ran it at least once

That's worse UX compared to the Mac (which is my standard).

[simoniz0r]

I feel like you only read that one part lol...

You could maybe even add like a --appimage-update-running-directory argument or something to AppImages which would allow them to offload this information without being ran.

With this, you could add an option/argument to appimaged which would allow it to scan common and/or specified directories for AppImages at will or when the check interval goes off to allow AppImages to be automatically added if the user wishes for that to happen.

[probonopd]

argument

Even worse. Mac users never need the command line and it still works. I want to create a user experience that equals the Mac. If you have no Mac experience, I suggest that you use one for a week and then we discuss again ;-)

[simoniz0r]

No. I suggest you take a poll of Linux users and see if they actually want what you're doing.

[simoniz0r]

With this, you could add an option/argument

The option could be taken care of in a config file. I know you're like ridiculously scared of config files for some reason, but you gotta wake up and realize that not everyone in the world wants the same things that you do. People want things to work in different ways and making your application flexible with config files is a great way to do this.

These things would only benefit AppImage in the long run and I really wish you'd just let go of the ridiculous macOS nonsense and start focusing on what Linux users actually want

[probonopd]

No. I suggest you take a poll of Linux users and see if they actually want what you're doing.

If anything, I might ask Mac-to-Linux switchers what they find annoying/complicated about Linux desktops, and what we would need to do to make it as elegant user experience as the Mac. The Linux desktop has the users it has because how it works. AppImage is here to make it work a bit more like on the Mac.

For example, a Mac user doesn't even understand why you would need to "install" an application. You can just download it, and open the application from the disk image (or copy it somewhere by drag-and-drop).

[simoniz0r]

There's just so much wrong with your vision. I guess my best hope is that someone else makes a fork of AppImage.

I'm honestly very sick and tired of having to reinvent the wheel every time that I work with AppImages because you're so stuck on your silly macOS philosophies that Linux users do not want at all even remotely.