Run update-mime-database and update-desktop-database about appimaged HOT 66 OPEN

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.

from appimaged.

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.

from appimaged.

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.

from appimaged.

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).

from appimaged.

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

from appimaged.

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.

from appimaged.

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!

from appimaged.

@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.

from appimaged.

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.

from appimaged.

"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

from appimaged.

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

from appimaged.

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.

from appimaged.

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

from appimaged.

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.

from appimaged.

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

from appimaged.

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.

from appimaged.

CC @azubieta Nitrux/nx-software-center#13 (comment)

from appimaged.

"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.

from appimaged.

@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.

from appimaged.

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.

from appimaged.

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.

from appimaged.

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

from appimaged.

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.

from appimaged.

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

from appimaged.

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

from appimaged.

@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.

from appimaged.

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.

from appimaged.

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.

from appimaged.

@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.

from appimaged.

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.

from appimaged.

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.

from appimaged.

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.

from appimaged.

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.

from appimaged.

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

from appimaged.

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.

from appimaged.

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

from appimaged.

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

from appimaged.

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

from appimaged.

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.

from appimaged.

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.

from appimaged.

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.

from appimaged.

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?

from appimaged.

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

from appimaged.

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.

from appimaged.

as long as they've ran it at least once

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

from appimaged.

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.

from appimaged.

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 ;-)

from appimaged.

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

from appimaged.

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

from appimaged.

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).

from appimaged.

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.

from appimaged.

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.

from appimaged.

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.

from appimaged.

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.

from appimaged.

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.

from appimaged.

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

from appimaged.

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.

from appimaged.

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...

from appimaged.

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

from appimaged.

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

from appimaged.

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.

from appimaged.

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.

from appimaged.

Closed and moved to the appimaged repository.

from appimaged.

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

from appimaged.

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

from appimaged.

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

from appimaged.