Add Install -> Editor -> Jetbrains menu

[NicolasDorier]

Motivation

The main motivation is to make it easy to install any of Jetbrain's product.

But additionally, JetBrains 2026.1 Rider 2026.1 shipped with -Dawt.toolkit.name=WLToolkit enabled by default, but JetBrains reverted that change in 2026.1.1. As a result, the latest JetBrains Rider IDEs have XWayland-related quirks out of the box. These can be fixed by adding -Dawt.toolkit.name=WLToolkit to the VM options.

Because this is no longer the default, users have opened issues and PRs such as #5640 caused by XWayland quirks.

This PR remedies the situation by allowing users to install popular JetBrains editors directly from Omarchy’s menu. The setup adds -Dawt.toolkit.name=WLToolkit by default, so users do not have to think about it. This was suggested by @dhh here.

EDIT: I've confirmed that this issue actually only impact pre-2026.1 AND Rider 2026.1.1, not all Jetbrains product.

What It Does

• Downloads and installs the latest version of the selected JetBrains product
• Installs each product into a stable path under /opt, such as /opt/jetbrains-rider
• Stages the new version in a temporary install folder, such as /opt/jetbrains-rider-tmp
• Verifies the downloaded archive checksum before extraction
• Extracts the archive with the top-level folder stripped, so the stable install path does not change between versions
• Adds -Dawt.toolkit.name=WLToolkit to the product’s VM options file
• Sets up a desktop entry from the product metadata in product-info.json
• Adds a symlink to the launcher in /usr/local/bin

For Rider, the resulting layout looks like this:

/
├── opt/
│   └── jetbrains-rider/
│       ├── product-info.json
│       └── bin/
│           ├── rider
│           └── rider64.vmoptions
│               └── contains: -Dawt.toolkit.name=WLToolkit
├── usr/local/bin/
│   └── rider -> /opt/jetbrains-rider/bin/rider
└── home/<user>/.local/share/applications/
    └── jetbrains-rider.desktop

Sudo access is requested before the download starts, so the user can fire and forget while it downloads, and the installation can proceed without interruption.
If the same version is already installed at the selected install path, the installer exits early.

Screenshots

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[NicolasDorier]

This is ready to go. I've tested on DataGrip, PyCharm, Idea, Clion and it installed without issue.

[Tsurgcom]

It would be nice if this menu also had 'android studio'. android studio is based on jetbrains.

I think you can install it from the AUR android-studio

[NicolasDorier]

The problem is that android-studio is not shipped like other Jetbrains product. (It is not in their product list). So it would need different code that the rest of them.

I'd like to first merge this if possible before adding Android Studio. Also, I don't think Android Studio should be under "Jetbrains" menu. (Maybe directly under Editor?) Anyway, I feel it would deserve more attention in another PR.

[Tsurgcom]

Yeah that makes a lot more sense.

[pkwagner]

Great idea, but how are updates handled? If I recall correctly, the IDEs itself don't ship with an updater, but rely on either JetBrains Toolbox or the package manager.

It seems like with the current script, the user would be required to uninstall first and then do a full re-install in the Install > Editor menu. Given that there are multiple releases per year, is this really better than just providing a single Toolbox installer in the first place? There's even an AUR package for that.

[NicolasDorier]

@pkwagner

WIth this PR there are two ways to update.

Via the new menu

The omarchy-install-jetbrains scripts detect that a new version is out, install it, and remove the old one.

Via the IDE

The IDE actually has an updater, but it's a bit unconventional.
Imagine that I installed Rider on /opt/'JetBrains Rider-2025.2.3', if I update from the IDE to 2026.1.1, the folder name remains /opt/'JetBrains Rider-2025.2.3'. The only way you know for sure which version you are in is by checking the file /opt/'JetBrains Rider-2025.2.3'/product-info.json.

This is why I created a stable symlink. /opt/jetbrains-rider to the current version, so users don't have to guess what the folder name is.

This doesn't conflict with the update from new menu, as I am detecting installed version from the product-info.json.

However, I am wondering if I shouldn't just make jetbrains-rider the real folder and removing the top level JetBrains Rider-2025.2.3 when I untar... this would avoid people to be confused by the IDE's update. I rewrote it.

[NicolasDorier]

@pkwagner I've rewritten it, now /opt/jetbrains-rider isn't a symlink, but the real install. That will avoid confusion with folder names when people update from the IDE.

[Copilot]

Copilot wasn't able to review any files in this pull request.

[dhh]

I appreciate the effort here, but I don't really want to route around the package manager. We need to be able to get this through the AUR. So let's try a version that does that.

Also, what's the reason they flopped back from wayland?

[NicolasDorier]

Actually, it may be only limited to Rider, as there are some features from Jetbrains dotUltimate which didn't seem working properly.
IMHO those are power feature most do not care about.

It doesn't seem to be set by default by Android Studio either, but this PR doesn't cover that because Android Studio is distributed differently.

The other case on PyCharm that I've seen seems to be pre 2026.1.

I will double check if that's only a Rider problem. PyCharm isn't impacted, this is indeed a Rider only issue.

---

I can try to push it through AUR.
I've never done it, where would be the best place? https://github.com/omacom-io/omarchy-pkgs or the Arch AUR? Given this is a commercial product, it doesn't seem right to me to take ownership of it on Arch AUR.

Note that the advantage of my PR is that it doesn't need to be updated when there are new versions, because it automatically pick up the latest version.

However, if we do a package, it means that every times there is a jetbrains release we will need to push an update as well.

[NicolasDorier]

I have an argument about why this shouldn't be AUR though: Jetbrains has its own updater within the IDE itself.
If we use AUR, the actually installed version will drift from so the package version when the internal update is used... People will get confused.

Most people update jetbrains directly from within the IDE when the popup comes up.

[NicolasDorier]

@dhh can you reconsider this? This shouldn't be AUR as jetbrains has an internal updater. I am currently using it without any issue, and it has many thumbs up!

[guidonaselli]

Nice. If/when this lands, the natural follow-up is theme sync — same pattern as omarchy-theme-set-vscode (per-theme jetbrains.json, omarchy-cmd-present checks, skip-* toggle).

I have a working implementation against current Omarchy themes that I can port to bash and PR once this merges. It generates a real .icls editor scheme from colors.toml (with TEXT foreground+background, so dark themes don't bleed a light editor background through the parent) and optionally installs a small companion plugin for live-reload.

Happy to wait until this is in before opening anything.