How IntelliJ determines if it can create a desktop entry


I have Android Studio on a Debian computer, and it wouldn’t allow me to use its “Create Desktop Entry” option. And there’s no precious diagnostic about why. So here’s why. Android Studio is built on the IntelliJ platform, and there’s an open source project, IntelliJ IDEA Community Edition, that’s also built on IntelliJ, so we’ll try to find out by looking through IntelliJ IDEA Community Edition’s source code.

The function that decides if the action is available considers:

X Window System

The criteria for whether your system would reasonably be running the X Window System turns out to be a pretty simple heuristic:

The criteria for whether the system is any of several possible options is determined from the Java system property, and the Unix-ness is inferred from the system not being Windows.

I use Debian GNU/Linux, so that should mean my system would feasibly be running the X Window System. Incidentally, I think I do, because I’m using a proprietary Nvidia driver that wasn’t working right with Wayland or something.

Not “roaming” installation

The “external update manager’s” criteria for the installation to be “roaming” are:

whatever it means for it to be those.

The “actual” external update manager, for the cases we’re interested in, is inferred with string matching on the IDE’s “home path:”

There’s some big complex algorithm for figuring out the “home path.” To be clear, it’s not the user’s home directory. It’s some location specific to the IDE installation. The algorithm starts at a path from the class loader and walks up the tree looking for a directory with a bin/ file. Fancy.

I know I didn’t use Snap to install Android Studio. The only way to get the preview release is to download a tarball. I was lucky I didn’t extract it into a path including /apps/ though. So that should mean the external update manager considers the installation not to be roaming.

Toolbox is apparently JetBrains’s own software installer/updater program.


I didn’t look much into how it checks for xdg-open. It’s whatever PathExecLazyValue does.

I checked in a terminal, and I didn’t have it. So that should mean that I don’t have xdg-open, so that the action to create a desktop entry ought to be unavailable, which is consistent. I installed xdg-utils and after that I was able to have it create a desktop entry.

It looks like it uses another program, xdg-desktop-menu, that comes with xdg-utils. In that case, I guess it’s justified that they check for xdg-open as a proxy for whether xdg-desktop-menu is installed.

xdg-utils is reported installed in 55% of Debian installations. I must have been in that weird 45%. I found out today that Ubuntu recently updated their popcon data too. It’s installed on 92% of Ubuntu installations. But that data also says there’s a lot more i386 installations than amd64. Hm.

Additional comments

Here’s the desktop entry it generated, in ~/.local/share/applications/jetbrains-studio.desktop:

[Desktop Entry]
Name=Android Studio
Exec="/home/wh0/software/android-studio/bin/" %f
Comment=The Drive to Develop

I had extracted the tarball in a path that contained the substring /software/. Really dodged a bullet on that /apps/ check.

Anyway, I wrote this junk down so that we would have some evidence of why open source stuff is nice, even if you’re stuck with a non-free downstream project. There’s stuff that isn’t documented but that you would be able to look up in the source code.

Oh, and good on JetBrains for making a repo where there’s only one obvious .java file for each class name you see. And for not making everything an interface where you have to go searching for what implements it. Could we all please hold off on that until web code browsing has intelligent cross referencing?

My last post was about either How IntelliJ IDEA installs shellcheck or The 999 islands that failed to revolutionize salad dressing. Find out which.