Discord's entry is `discord --url -- %u`. The flag went in before the
field code, which put it after the double dash, and that is where
Chromium stops reading switches and starts treating everything as an
address. The feature never came on.
Discord no longer ships its application. /usr/bin/discord is a few lines
of shell that run updater_bootstrap, which downloads Electron into the
user's config directory on first start and execs it from there. So there
is no binary next to the launcher to find markers around, and the path it
hands over to is built out of $HOME and the version it just downloaded,
which the script reader cannot resolve. Discord came out as "not
Chromium" and was dropped from the list entirely.
The name of the bootstrap it ships is the one thing left that says
Discord, so that is the hint now.
Every AppImage came out as "cannot tell" because the payload is a
compressed filesystem and none of the Chromium markers is on disk to be
found. The names are reachable, though: squashfs keeps the name of
everything it holds in one table of a few kilobytes, and a name is all
this question needs. That table is now read and inflated in place -
nothing is unpacked, and the image is never run, which a scan started by
the path unit has no business doing anyway.
So a Tauri AppImage such as Modrinth is recognised as WebKitGTK and
dropped from the list instead of being offered as something that could be
switched on - there is no autoscroll in WebKit to ask for - and an
Electron one is covered like any other application.
Left as "cannot tell": lzo and lz4, which squashfs stores as bare blocks
no tool will read without their own framing, and the original ISO9660
layout.
Alongside:
- The detect cache carries a format line. Its entries are keyed on size
and mtime, so an AppImage that has not changed would otherwise keep
answering the way an older version decided it did, forever.
- A marker list for whole-tree searches, which is what a Flatpak, a snap
and an AppImage need. icudtl.dat, snapshot_blob.bin and resources.pak
are out of it: Flutter ships an icudtl.dat in data/, and next to a
binary those names are evidence while four directories down they are
not. The Flatpak and snap searches now share that list.
KDE's own middle-click paste is turned off along with everything else. Inside a
Chromium application the flag already settles it - with autoscroll on, Blink
stops pasting the primary selection - but everywhere else on the desktop middle
click goes on pasting, which is the thing this program exists to get away from.
KWin has a switch for it on a Wayland session, where the paste is a protocol
the compositor either offers or does not, and that is what gets written. It is
true from the next login on. What the key said before is recorded, so disable
puts it back, and a key that already said no is left alone and never switched
back on. X11 has no such switch and nothing is written there.
Off under Settings for anyone who wants the paste kept.
A build with a prefix of its own put them in $(PREFIX)/lib/systemd/user, which
is right for /usr/local and wrong for the one prefix an install without root
can use: systemd searches $XDG_DATA_HOME/systemd/user and never
~/.local/lib/systemd/user. An install into ~/.local came out with a working
program whose watcher could not be enabled at all.
They go under share now, which both a system prefix and a home one are
searched for. Nothing changes for the packages - the deb and the rpm pass
USERUNITDIR in themselves.
That prefix is what an atomic distribution leaves a user, so the readme says
how to install on Bazzite: layer the rpm and reboot, or put the whole thing in
$HOME, which is where everything it writes ends up anyway.
Felitendo