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 Nitrux/nx-software-center#13 (comment)

[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]

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.

[TheAssassin]

It's funny and often a little ridiculous to see both of you claim to know what Linux users want. @probonopd is more focused on "easy-to-use, grandma can do it, Mac-like", whereas @simoniz0r represents the "classic Linux user, used to configurability, likes and enjoys the possibility to tune until the own preferences are sufficiently represented".

Both of you don't really know or are able to tell what Linux users want. The reason is: you both represent some fractions of the totality of Linux users. I would never claim something alike, but that might be because of my background in science.

@simoniz0r often you seem to be like "you're doing it wrong, you must change your way of doing things, I will explain you how to". This is not really a productive way of proposing changes.

AppImages have initially been designed to fit a specific purpose. The fact you don't like these doesn't make them wrong.

There are libraries available which allow you to design tools that make your AppImage experience fit your preferences. I personally don't use appimaged, and dislike some of its concepts. This is one of the reason why I took libappimage and work on my own desktop integration solution, which will soon be available in some distros.

I really recommend anybody to use and improve libappimage to build new applications dealing with AppImages.

[probonopd]

It's OK to have different viewpoints as long as one realizes that there are legitimately different viewpoints and different priorities. I don't claim to know what all Linux users want - in fact, "Linux users" want so many different opposing things that you can't please everyone. The AppImage project is not there to please "classic Linux users" - this was never its intention (as they are happy with things like Emacs and debhelper and autotools and whatnot), but rather to "the rest of us": multi-platform application authors, ISPs, users who are Mac converts and generally people who don't care about the system and just want to get things done.

[simoniz0r]

All I'm saying really is there's absolutely no reason why you can't provide both things. You can provide sane defaults and the ability to configure your applications to make both types of users happy.

[TheAssassin]

absolutely no reason

Using such strong terms will often backfire. If I'd want to really have such a discussion, I could throw in the maintenance overhead of developing and maintaining a configuration infrastructure... that works across all Linux distributions... etc.

appimaged is a highly specific tool, primarily written for @probonopd's use cases. Please don't use it if it doesn't work for you, and try the alternatives.

[simoniz0r]

appimaged is a highly specific tool, primarily written for probonopd's use cases. Please don't use it if it doesn't work for you, and try the alternatives.

That's kinda hard to believe when statements have been made suggesting that the current desktopintegration script would be completely abandoned in favor of using appimaged.

[TheAssassin]

@simoniz0r the script has been abandoned. Nobody's maintaining it. Also, alternatives to appimaged are already available...

[simoniz0r]

the script has been abandoned. Nobody's maintaining it. Also, alternatives to appimaged are already available...

That's pretty sad to hear, honestly. When paired with something like the lightweight dialog tool, AppImages that make use of this actually feel very professionally done and nice to use.

Is AppImageLauncher your alternative? Am I supposed to be bundling this 20MB AppImage in my existing AppImages? If not, you're requiring another piece of software to be installed for AppImages to work nicely which is against the main principles of AppImages to begin with.

[TheAssassin]

When paired with something like the lightweight dialog tool, AppImages that make use of this actually feel very professionally done and nice to use.

The tool is buggy, lacks lots of features, leaves traces on the system, can't handle removal, ... I could continue the list quite a bit.

The original desktop integration script some AppImages rely on is what I referred to. It has the same problems as the other tool that @darealshinji and I have been working on.

AppImageLauncher isn't meant to be bundled. If you had read its description:

Therefore, new, system-side solutions have been developed to perform the desktop integration.
[...]
AppImageLauncher integrates deeply in the system and intercepts all attempts to open an AppImage, becoming the first instance to handle all AppImage invocations.

Neither it goes against any AppImage principles. How could it possibly? Again a wild claim without any explanation...

[simoniz0r]

AppImages are supposed to work well without needing any additional software installed...

[TheAssassin]

Desktop integration is not a core requirement for AppImages to run...

[pchote]

Below are my two cents on the topic, written after a quick read through of the discussion above. Going through that again before submitting, I see that you are already going this way with https://github.com/TheAssassin/AppImageLauncher. I look forward to that tool progressing.

--

Similar to some of @simoniz0r's ideas above, I think a decent solution would be to keep appimaged running as a service, but require individual AppImages to explicitly register with it when they run. I guess this is similar in principle to the old approach of each image installing its own shortcuts, but the daemon can clean up automatically after deleted or moved AppImages. appimaged could then expose preferences for things like whether to prompt for integration on every new image or a location to automatically move images to.

This would mean giving up automatic registration when a user downloads an AppImage, but IMO this is a good thing: better to consistently require the first run to be manual than to have a hardcoded list of magic locations where AppImages are automatically integrated, and then everywhere else not integrating at all. The inotify problem goes away because you only need to monitor specific known AppImage file paths instead of arbitrarily large directories.

[probonopd]

https://github.com/TheAssassin/AppImageLauncher/blob/master/src/shared.cpp#L154-L159
seems to make the icons appear in the menu on XFCE

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

We need to fix #12 first, so that we don't invoke those commands after each processed AppImage.

[azubieta]

Closed and moved to the appimaged repository.

[probonopd]

Let's use GitHub's shiny new "Transfer Issue" beta feature for this. 👍

[TheAssassin]

That's what was used, wasn't it?

[probonopd]

No, at least it didn't seem to have worked for me... I now did it.