Автозапуск приложений в KDE Plasma 5

Ещё в кедах есть баг (или фича?), что когда включен авто-логин, то не срабатывает «Plasma Workspace Login» нотификейшн

Ты уверен, что по этому? По моему просто к тому времени нотификейшны ещё не успевают, потому что всё грузится в хаосе. А при горячем перезапуске всё отрабатывает гораздо чётче, потому что всё в кэше.

Ты уверен, что по этому?

Нет, но причина и не важна. Важен результат: звука входа при авто-логине нету, а без авто-логина - есть.

По моему просто к тому времени нотификейшны ещё не успевают, потому что всё грузится в хаосе.

Может быть и так. В любом случае меня полностью бы устроил костыль, который позволял бы запускать мои скрипты после того как плазма полностью запустится, а не во время «хаоса».

Я не понял, чем тебя не устраивает вариант прописать в скрипт sleep, в него всё из автозагрузки и кинуть в автозагрузку его?

прописать в скрипт sleep

Как я написал в оп, я это уже сделал, но загрузка плазмы занимает случайное время и иногда не укладывается в мои 5 секунд. Ставить, например, 5 минут не имеет смысла, потому что это слишком долго.

Мне нужен какой-нибудь условный initrc, запускающий сессию, чтобы я мог добавить в него свои костыли.

Вообще, странно, что она у тебя так долго стартует. Я бы на твоём месте попробовал запускать средствами systemd в таком случае. Посмотри список таргетов командой

systemctl list-units --type=target --all

Не совсем понятно при чём тут systemd. Ну, допустим, SDDM может запускаться как-то через systemd, но после этого уже SDDM решает какую сессию и когда запустить. В случае плазмы запускается startkde, который запускает kdeinit5, а затем ksmserver.

Вот тут я нашёл интересный атериал для чтения: https://github.com/KDE/plasma-workspace/blob/master/ksmserver/README

К сожалению он не помогает решить задачу.

Думаю, я попробую сделать свою сессию, которая будет сначала запускать startkde, а потом мой костыльный автозапуск.

путём чтения исходников удалось найти два параметра, которые можно добавлять в .desktop-файлы:

X-KDE-autostart-phase=2 X-KDE-autostart-after=panel

Однако никакая их комбинация не приводит к желаемому эффекту: всё равно сначала грузится браузер на полный экран, и только потом, с задержкой, плазма-панель

#!/bin/zsh
a=true
while $a ; do
if [ $(pgrep kwrite)>'0' ] ; then
$(/usr/bin/dolphin);
a=false
else
sleep 1s;
fi
done

На. Задай сам условия после какого приложения стартовать и что запускать.

Спасибо за идею, но к сожалению мне не известны никакие процессы, которые бы запускались после того как плазма закончит грузиться. Если ждать появления какого-нибудь процесса plasmashell, то мы поймаем начало загрузки, а не окончание. Более того, процессы, которые грузят плазму, остаются висеть всю сессию, так что отлавливать пропадание процесса тоже не катит.

Судя по исходникам, в нужный мне момент

происхот вот такой вызов:

QDBusMessage ksplashProgressMessage = QDBusMessage::createMethodCall(QStringLiteral("org.kde.KSplash"),
                                                                     QStringLiteral("/KSplash"),
                                                                     QStringLiteral("org.kde.KSplash"),
                                                                     QStringLiteral("setStage"));
ksplashProgressMessage.setArguments(QList<QVariant>() << QStringLiteral("ready"));
QDBusConnection::sessionBus().asyncCall(ksplashProgressMessage);

Как подслушать из скрипта чужие D-Bus сообщения?

Я думаю, ты можешь что-то придумать, если внимательно посмотришь список процессов. Попробуй вообще загрузиться без иксов, открыть top на tty2, потом стартануть плазму на tty1, переключиться и посмотреть, в каком порядке всё запускается, или ещё каким-то способом. У меня например окно для ввода пароля от kwallet открывается самым последним, когда уже всё загружено и ноут коннектится к вайфаю. Даже браузер раньше открывается почему-то. А kdeconnect например вроде стартует, когда остальное прогрузилось, ибо там виджет на рабочий стол. Но точно я не проверю это. А как дбас месседжи пытаться перехватить - я не знаю...

Хотя это, dbus-monitor вроде умеет.

dbus-monitor

Да, я тоже его нагуглил. Оказалось, что есть даже более подходящий stage, который называется не «ready», а «desktop».

В итоге я добавил в автозапуск скрипт-трамплин

#!/bin/bash
"${HOME}/autostart.sh" &> /tmp/autostart.log &

#!/bin/bash
echo 'Waiting for desktop stage'
exec 3< <(dbus-monitor "interface='org.kde.KSplash',member='setStage'")
sed '/string "desktop"$/q' <&3 ; exec 3<&-

<запуск прог>

Осталась одна проблема - dbus-monitor остаётся висеть, а я хотел бы, чтобы он закрывался. Я копипастил отсюда: https://stackoverflow.com/a/21002153 и добавил exec 3<&- в надежде, что он будет прибивать dbus-monitor, но нет, не работает.

Есть какой-нибудь способ его прибить? (желательно по pid)

kill $(pidof dbus-monitor)

Я имел в виду, что хотел бы прибивать не любой dbus-monitor, а запущенный именно в этом скрипте. Ну, то есть либо получить как-то пид при запуске, либо применить какую-то конструкцию типа exec 3<&-, чтобы оно прибивалось средствами баша

Возможнон, решение покажется тебе не таким красивым и элегантным. Но ты можешь запускать монитор из скрипта с уникальным именем, он будет дочерним процессом. По окончании запуска всех приложений - килять этот скрипт.

в смыле сделать что-то типа

my-dbus-monitor.sh:

#!/bin/bash
dbus-monitor $@

а потом kill $(pidof my-dbus-monitor.sh) из автостарт-скрипта? Да, это должно работать, попробую вечером, спасибо.

Но ведь наверняка же должен быть способ сделать без подкостыливания. Наверное, спрошу в новом треде именно про это.

В итоге сделал так:

exec 3< <(dbus-monitor "interface='org.kde.KSplash',member='setStage'" & echo $!)
read pid <&3
sed '/string "desktop"$/q' <&3 ; kill $pid