Плагины/индикаторы для индикации статуса синхронизации с Yandex-disk

[Rootdiv]

В Ubuntu Mate 22.04 иконка yd-go не показывается потому, что плагин панели индикаторов не поддерживает получение иконки от приложения в бинарном формате. К сожалению со стороны yd-go эту проблему не пофиксить (собственно yd-go отдает плагину все что нужно).

В Ubuntu Mate 24.04 всё так же.

На эту тему нашлось у них на github ишью, приписал свой вопрос (планируют ли добавить поддержку IconPixmap) приписал в него.

Это ишью так и висит с 2022 года, а по Вашей ссылке в ишью вообще 404, похоже они удалили Ваше сообщение.

[Sly_tom_cat]

К сожалению трудно сказать как решать такого рода проблемы. Разработчики многих open source библиотек просто не отвечают и ничего не делают. К сожалению столкнулся с этим уже не однократно....
Тут еще и сообщения от людей, у которых локация в профиле Россия - тоже по нынешнем временам не жалуют.... и иногда трут. Я то в профиле у себя на гитхабе давно уже неопределенную указываю... Но кто их там знает... может смотрят на каком языке ишью обсуждают в репах пользователя.... Политика, мать ее....
____

Посмотрел тут у себя в XUBUNTU 22.04 и в 24.04 - уже везде этот AyatanaAppIndicator затащили. Однако в XFCE yd-go работает нормально: иконку показывает.

Я там еще и нотификации на d-bus в последних версиях переделал и там в нотификации иконка тоже в pixBuf (хотя и в чуточку другом формате) идет прямо через d-bus (а не путем к файлу, или по имени иконки). В KDE/XFCE - это все работает нормально, а вот про Mate - как-то все без просвета...
Пользователь добавил сообщение 08 Мая 2025, 23:48:37:Но кстати у меня открывается ссылка из того сообщения :https://github.com/AyatanaIndicators/ayatana-indicator-application/issues/1 , и сообщения я там свои вижу.

Только вот теперь я уже вообще не понимаю.... Если и у меня сейчас стоит AyatanaIndicator... но он работает с pixBuf и для иконок трея и для иконок уведомлений. А что тогда сломано в Mate 


Пользователь добавил сообщение 09 Мая 2025, 00:02:05:А понял по какой ссылке 404 - там я находил еще одно ищью на тему но видимо там стерли само ишью, а не мое сообщение.

[Rootdiv]

Если и у меня сейчас стоит AyatanaIndicator... но он работает с pixBuf и для иконок трея и для иконок уведомлений. А что тогда сломано в Mate

Может где какие логи посмотреть?

Я сейчас запустил с отладкой утилиту выдало:

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

time=2025-05-09T12:25:04.587+03:00 level=DEBUG msg=language LANG=ru
time=2025-05-09T12:25:04.587+03:00 level=DEBUG msg=yandex-disk executable=/usr/bin/yandex-disk
time=2025-05-09T12:25:04.587+03:00 level=DEBUG msg=file_watcher status=added
time=2025-05-09T12:25:04.587+03:00 level=DEBUG msg=YDisk status=initialized path=/home/maindiv/Yandex.Disk
time=2025-05-09T12:25:04.587+03:00 level=DEBUG msg=daemon_event_handler status=started
time=2025-05-09T12:25:04.674+03:00 level=DEBUG msg=ui_event_handler status=started
time=2025-05-09T12:25:04.681+03:00 level=ERROR msg=daemon_status error="exit status 1" message="Ошибка: демон не запущен"
time=2025-05-09T12:25:04.688+03:00 level=DEBUG msg=timer interval=1
time=2025-05-09T12:25:04.694+03:00 level=DEBUG msg=change prev=unknown new=none S=false L=0 E=false
time=2025-05-09T12:25:04.694+03:00 level=DEBUG msg=last_synchronized length=0
time=2025-05-09T12:25:04.707+03:00 level=DEBUG msg=ui_change status=handled
time=2025-05-09T12:25:05.245+03:00 level=DEBUG msg=file_watcher event=WRITE path=/home/maindiv/Yandex.Disk/.sync/cli.log
time=2025-05-09T12:25:05.252+03:00 level=DEBUG msg=change prev=none new=paused S=false L=10 E=false
time=2025-05-09T12:25:05.252+03:00 level=DEBUG msg=last_synchronized length=10
time=2025-05-09T12:25:05.266+03:00 level=DEBUG msg=ui_change status=handled
time=2025-05-09T12:25:05.266+03:00 level=DEBUG msg=sending_message title="Индикатор Yandex.Disk" message="Утилита запущена"
time=2025-05-09T12:25:05.548+03:00 level=DEBUG msg=file_watcher event=WRITE path=/home/maindiv/Yandex.Disk/.sync/cli.log
time=2025-05-09T12:25:05.549+03:00 level=DEBUG msg=daemon_start message="Запуск демона...Готово"
time=2025-05-09T12:25:05.556+03:00 level=DEBUG msg=change prev=paused new=index S=false L=10 E=false
time=2025-05-09T12:25:05.571+03:00 level=DEBUG msg=ui_change status=handled
time=2025-05-09T12:25:05.571+03:00 level=DEBUG msg=sending_message title="Индикатор Yandex.Disk" message="Синхронизация начата"
time=2025-05-09T12:25:05.867+03:00 level=DEBUG msg=file_watcher event=WRITE path=/home/maindiv/Yandex.Disk/.sync/cli.log
time=2025-05-09T12:25:05.876+03:00 level=DEBUG msg=change prev=index new=busy S=false L=10 E=false
time=2025-05-09T12:25:05.910+03:00 level=DEBUG msg=ui_change status=handled
time=2025-05-09T12:25:05.965+03:00 level=DEBUG msg=file_watcher event=WRITE path=/home/maindiv/Yandex.Disk/.sync/cli.log
time=2025-05-09T12:25:05.974+03:00 level=DEBUG msg=change prev=busy new=index S=false L=10 E=false
time=2025-05-09T12:25:06.018+03:00 level=DEBUG msg=ui_change status=handled
time=2025-05-09T12:25:06.975+03:00 level=DEBUG msg=timer interval=1
time=2025-05-09T12:25:08.984+03:00 level=DEBUG msg=timer interval=2
time=2025-05-09T12:25:10.751+03:00 level=DEBUG msg=file_watcher event=WRITE path=/home/maindiv/Yandex.Disk/.sync/cli.log
time=2025-05-09T12:25:10.759+03:00 level=DEBUG msg=change prev=index new=idle S=true L=10 E=false
time=2025-05-09T12:25:10.794+03:00 level=DEBUG msg=ui_change status=handled
time=2025-05-09T12:25:10.795+03:00 level=DEBUG msg=sending_message title="Индикатор Yandex.Disk" message="Синхронизация закончена"
time=2025-05-09T12:25:11.760+03:00 level=DEBUG msg=timer interval=1
time=2025-05-09T12:25:13.770+03:00 level=DEBUG msg=timer interval=2
time=2025-05-09T12:25:17.782+03:00 level=DEBUG msg=timer interval=4


В syslog появилось:

Код: [Выделить]

2025-05-09T12:25:04.592107+03:00 UbuntuMate dbus-daemon[2452]: [session uid=1000 pid=2452] Activating service name='org.freedesktop.Notifications' requested by ':1.2584' (uid=1000 pid=67146 comm="./yd-go -debug" label="unconfined")
2025-05-09T12:25:04.673086+03:00 UbuntuMate dbus-daemon[2452]: [session uid=1000 pid=2452] Successfully activated service 'org.freedesktop.Notifications'Если нужно ещё что-то посмотреть, то подскажите где посмотреть и я посмотрю.

[Sly_tom_cat]

Я смотрел .... хм... долго пришлось вспоминать и лазить по меню запуска, что бы понять, что это было  ....

Оказалось утилита зовется d-feed - она показывает всех клиентов и сервисы, что работают с d-bus.

При запуске yd-go на закладке session bus внизу появится две коннекции yd-go (там одна для нотификаций и еще одна для иконки/меню) там ничего интересного, но нужно посмотреть PID. А вот выше должен еще появится объект org.kde.StatusNotifierItem-<PID>-1. вот он и есть представитель yd-do в D-Bus который общается с org.kde.StatusNotifierWatcher (это собственно имя провайдера, который отвечает за прорисовку иконки и меню в области уведомлений панели.
У меня там есть еще и org.ayatana.indicator.application - но вот я толком не пойму как он связан с всей этой кухней....

Там у каждого объекта есть путь или пути того чем они на самом деле реализованы (библиотеки/исполняемые файлы).

Все вот это как бы пароли адреса и явки, сам экшен смотрится либо в dbus‑monitor либо в Bustle.

... но вот как я смотрел обмен сообщениями (вроде я делал это через dbus‑monitor ) - я уже не могу сейчас не могу точно вспомнить. Надо поковыряться с утилитами....


Пользователь добавил сообщение 10 Мая 2025, 17:38:27:Кстати, по идее в syslog должно быть еще пара сообщений от dbus-daemon про то, что yd-go создает подключение к чему-то там типа org.kde.StatusNotifierWatcher.... но у меня в syslog таких сообщений вообще нет
Пользователь добавил сообщение 10 Мая 2025, 19:38:49:Как я понял обмен через D-bus посмотреть можно только в одном направлении:
От yd-go к провайдеру иконок в панели:

Код: [Выделить]

dbus-monitor --session "sender='org.kde.StatusNotifierItem-<PID>-1'"
От провайдера в адрес yd-go:

Код: [Выделить]

dbus-monitor --session "destination='org.kde.StatusNotifierItem-<PID>-1'"
Ну или по другому (со стороны сервиса иконок в панели):

Код: [Выделить]

dbus-monitor --session "destination='org.kde.StatusNotifierWatcher'"
dbus-monitor --session "sender='org.kde.StatusNotifierWatcher'"

На сколько я припомню, в Mаte этот org.kde.StatusNotifierWatcher (провайдером которого был avataya-service или что-то такое) пересылал то, что получал в Avataya (org.ayatana.indicator.application) и проблема была видна в том, что при этой пересылке терялись дополнительные атрибуты сообщений (в которых и передается pixMap объект с изображением иконки).

Но вот у меня в XFCE провайдером org.kde.StatusNotifierWatcher является /usr/lib/x86_64-linux-gnu/xfce4/panel/wrappr-2.0 и /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libstatusnotifier.so. И вот эта libstatusnotifier.so является самостоятельным сервисом, и ничего никуда не пересылает (хотя там тоже есть проблемка с тем что эта реализация требует строго синхронных ответов по d-bus, хотя спецификация d-bus не требует синхронности ответов - там в каждом ответе есть id сообщения отправителя, на которое отправлено это сообщение и именно по этим ID приложение должно сериализовать ответы).

Я думаю надо смотреть что там в mate происходит в d-bus что бы понять кто именно виноват в том что иконка не отображается.
Пользователь добавил сообщение 10 Мая 2025, 20:42:38:Я там посмотрел немного и понял, что в выводе того что шлет индикатор весь лог забивают бинарные данные картинок.

вот такой вариант:

Код: [Выделить]

dbus-monitor --session "destination='org.kde.StatusNotifierWatcher', sender='org.kde.StatusNotifierItem-18483-1'" | grep -vE '                     [0123456789abcdef]{2} '
Выводит все кроме этих бинарных данных. Причем сам заголовок этих данных выводится. Т.е. можно понять что данные передаются, но сами данные при этом не забивают логи.

[Sly_tom_cat]

Посмотрел тут документацию оказывается в вызове dbus-monitor можно указывать несколько условий для фильтрации.

Вот такого монстра наворотил, что бы видеть весь обмен, который касается индикатора и без простынок бинарных данных.

Код: [Выделить]

export SERVICE="'org.kde.StatusNotifierItem-4279-1'"; dbus-monitor --session "sender=${SERVICE}, type=signal" "sender=${SERVICE}" "destination=${SERVICE}" "destination=${SERVICE}, type=signal" | grep -vE '                     [0-9abcdef]{2} '

Тут пришлось отдельно прописать type=signal и type=method_return и без типа из-за того что если тип не указывать то показываются только return-ы (без сигналов которые являются неотъемлемой частью обмена по d-bus), а если указать type=signal, то будут показываться только сигналы. То же сделано и для destination. Но если еще полнее, то в d-bus ходит еще много широковещательных сообщений (с destination=null) и их получают все. Но это дело приложения обрабатывать или игнорировать такие сообщения.

По такому принципу можно на любой сервис нацепить логгирование того, что он делает в рамках взаимодействия по d-bus.

Если нужно то и на несколько сервисов можно натравить логиирование трафика, но там будет довольно трудно смотреть.
Лучше еще в параллель запускать трейс (dbus-monitor --profile ....) тогда каждая итерация сокращается до одной строки в которой видно кто кому и ID сообщения. По трейсу смотрится сам процесс обмена, а нужные сообщения ищутся по ID.

[Sly_tom_cat]

Уф, ну и история вышла.

Пользователи yd-go в GNOME пожаловались, что индикатор на старте вообще весь DE вешает   в 25.04.
Я долго пытался понять что не так, ведь в XFCE и KDE, да и в старых версиях GNOME - все работало нормально.   

С самого начала было понятно, что проблема связана с обменом по DBUS, потому что yd-go просто никак иначе с DE не взаимодействует. Я грешил на процесс инициализации и перелопачивал его несколько раз. В конце концов автор ишью просто перестал отвечать... Я все собирался себе в виртуалку Ubuntu 25.04 поставить что бы разобраться... но руки все никак не доходили....

А тут пришел человек с той же проблемой в GNOME только на 24.04. И он мне за несколько дней помог найти проблемный коммит и продиагностировать несколько версий правок этого коммита. Но обошлось и без сбора логов через dbus-monitor....

НО, главное. Проблему наши и я релизнул новую версию с фиксом.
Есть подозрение (точнее надежда), что MATE тоже может полегчать. По крайней мере попробовать стоит.

[Rootdiv]

Есть подозрение (точнее надежда), что MATE тоже может полегчать. По крайней мере попробовать стоит.

Не полегчало.

Выполнил команду

Код: [Выделить]

dbus-monitor --session "destination='org.kde.StatusNotifierWatcher'" "sender='org.kde.StatusNotifierWatcher'"в консоли появилось:

Код: [Выделить]

signal time=1749325007.487416 sender=org.freedesktop.DBus -> destination=:1.5153 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.5153"
signal time=1749325007.487450 sender=org.freedesktop.DBus -> destination=:1.5153 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string ":1.5153"
При запуске ya-go консоли появилось:

Код: [Выделить]

method call time=1749325011.915845 sender=:1.5163 -> destination=org.kde.StatusNotifierWatcher serial=3 path=/StatusNotifierWatcher; interface=org.kde.StatusNotifierWatcher; member=RegisterStatusNotifierItem
   string "/StatusNotifierItem"
method return time=1749325011.916616 sender=:1.42 -> destination=:1.5163 serial=34 reply_serial=3

Какое-то действие с Яндекс.Диском вывод в консоли не меняет.

[Sly_tom_cat]

Попробуйте так:

Код: [Выделить]

export SERVICE="'org.kde.StatusNotifierWatcher'"; dbus-monitor --session "sender=${SERVICE}, type=signal" "sender=${SERVICE}" "destination=${SERVICE}" "destination=${SERVICE}, type=signal" > dbus.log & sleep 1; ./yd-go & sleep 10; pkill -2 yd-go; sleep 1; pkill -2 dbus-monitor
Тут запишется и старт индикатора и его остановка через 10 секунд.

Еще посмотрите - может что-то в syslog или dmesg есть при старте индикатора.

Логи полные сюда приложите - я тут уже руку набил эти партянки изучать...

[Rootdiv]

Sly_tom_cat, при выполнении команды записывается очень мало почти тоже самое, что и ранее выкладывал

Код: [Выделить]

signal time=1749376029.890402 sender=org.freedesktop.DBus -> destination=:1.904 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.904"
signal time=1749376029.890453 sender=org.freedesktop.DBus -> destination=:1.904 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string ":1.904"
method call time=1749376030.936557 sender=:1.907 -> destination=org.kde.StatusNotifierWatcher serial=3 path=/StatusNotifierWatcher; interface=org.kde.StatusNotifierWatcher; member=RegisterStatusNotifierItem
   string "/StatusNotifierItem"
method return time=1749376030.937259 sender=:1.42 -> destination=:1.907 serial=29 reply_serial=3При этом в syslog такие записи:

Код: [Выделить]

2025-06-08T12:47:09.890620+03:00 UbuntuMate dbus-daemon[2572]: [session uid=1000 pid=2572] Connection :1.904 (uid=1000 pid=24738 comm="dbus-monitor --session sender='org.kde.StatusNotif" label="unconfined") became a monitor.
2025-06-08T12:47:10.937075+03:00 UbuntuMate dbus-daemon[2572]: [session uid=1000 pid=2572] Activating service name='org.freedesktop.Notifications' requested by ':1.908' (uid=1000 pid=24794 comm="./yd-go" label="unconfined")
2025-06-08T12:47:11.013239+03:00 UbuntuMate dbus-daemon[2572]: [session uid=1000 pid=2572] Successfully activated service 'org.freedesktop.Notifications'
2025-06-08T12:47:21.955267+03:00 UbuntuMate dbus-daemon[2572]: [session uid=1000 pid=2572] Monitoring connection :1.904 closed.
Прикладываю 10 секунд записи без фильтрации в архиве.

[Sly_tom_cat]

Ну что я могу сказать - индикатор судя по логам вполне нормально ответил org.kde.StatusNotifierWatcher на запрос всех свойств, что у него в свойствах есть IconPixmap (и сразу отдал изображение). Кроме того, позже, был еще сигнал о том что иконка изменилась и в сигнале снова был передан массив байт с изображением.

У меня в XFCE, на такие сигналы (о смене свойства IconPixmap) org.kde.StatusNotifierWatcher зачем то еще раз переспрашивает значение этого свойства и получает массив байтами изображения. Но у вас в MATE никакой реакции от org.kde.StatusNotifierWatcher на смену свойства IconPixmap - нет. И вот это настораживает, создается впечатление что тот кто стоит за сервисом org.kde.StatusNotifierWatcher просто не знает такого свойства.

Не могли бы вы посмотреть кто именно (какие библиотеки) реализуют сервис org.kde.StatusNotifierWatcher через D-feed (там в плашке сервиса подписано какие библиотеки его реализуют).
 

[Rootdiv]

Не могли бы вы посмотреть кто именно (какие библиотеки) реализуют сервис org.kde.StatusNotifierWatcher через D-feed (там в плашке сервиса подписано какие библиотеки его реализуют).

Вот информация по индикатору

И общая информация

[Sly_tom_cat]

Код: [Выделить]

/usr/libexec/ayatana-indicator-application/ayatana-indicator-application-service
Ну вот это поделие так и не научилось поддерживать свойство IconPixmap (вроде как то самое ишью, что в теме ранее было, тегнул там разработчиков сейчас еще раз).

PS. там у меня на github еще одна эпопея разворачивается с gnome-shell - там мало того, что они забыли, что меню может вообще-то и изменяться, так еще и сложили все свои яйца в одну дырявую корзину... Да так все сложили, что кривой ответ по DBUS может вообще весь десктоп подвесить!!!  . Я просто не перестаю удивляться тупости некоторых разработчиков...

Но, gnome-shell хоть научились IconPixmap поддерживать.... однако не поддерживают обновление меню - не понос так золотуха...
Пользователь добавил сообщение 09 Июня 2025, 23:51:41:Посмотрел тут в исходниках ни о каком IconPixmap там речи не было и нет..... Ишью тому - сто лет в обед - и никто не шевелится. Тут даже не представляю - какой же рак на горе должен свистеть начать, что бы эта ситуация сдвинулась с мертвой точки....

[Sly_tom_cat]

gnome-shell в итоге победили сломав декларируемую в спеке DBUS фильтрацию атрибутов 

Там история такая - при запросе layout меню или отдельных его компонентов есть возможность указать список атрибутов, которые нужно вернуть. Если этот список пустой, то вернуть надо все что есть, но если в этом списке перечислены названия свойств, то, согласно спеке, возвращать надо только то, что запросили.

Большинство имплементаций просто не заморачиваются фильтрацией и просто игнорируют список свойств из запроса, отдавая всегда все атрибуты. Так было и в библиотеке systry, которую я форкнул от fyne.io (те его тоже форкнули). Ну вот от нечего делать я взял да и допилил эту фичу. Даже понравилось как красиво там получилось это реализовать...

При этом в XFCE и KDE плагины, на старте и при каждом изменении меню, запрашивают layout меню с ограниченным числом атрибутов, получая при этом по сути скелет меню с ID пунктов меню и всей схемой вложенности. После этого плагин делает серию запросов с уточнениями по спискам ID элементов меню и в этих запросах список требуемых свойств пуст (т.е. они просят вернуть все, что только есть, по каждому ID).

Плагин индикаторов для gnome-shell на старте тоже запрашивает скелет и потом уточняет все свойства по ID, полученным в первом запросе. Однако при изменении версии меню (после того как приложение уведомит плагин что меню поменялось) плагин ... запрашивает только скелет layout-а меню. Никаких уточняющих запросов он не делает. И с-но никаких изменений в меню он и не показывает.

Пришлось откатывать фильтрацию. Со сломанной фильтрацией меню стало обновляться.