Потестил трей ради эксперимента, пока вывод сложился такой: appindicator используется тулкитами повсеместно, но сам по себе достаточно коряв и не отслеживает события мыши, меню открывает по левой кнопке, так и по правой, при открытии окна в событиях мыши не сохраняет данных о кнопках. Пока придумал такой выход, в addOnAdd контекстного меню, которое ставится в трей через getParent получаю доступ к его родителю Window, opacity в 0. На Window addOnHide и тоже после каждого закрытия opacity в 0. Когда меню открыто, то на нем начинают срабатывать события мыши и в addOnButtonRelease можно отследить кнопку мыши в случае правой кнопки восстановить непрозрачность окна, в котором меню, в случае левой запросить показ окна проги. Получается, что оно на долю секунды появляется по лкм, но само по себе невидимо. Хотя события и обрабатывает, но скрывается быстро, маловероятно, что можно успеть задеть его, хотя не факт... не факт..

Пока остается Gdk-CRITICAL, но насколько я гуглил встречается она часто, у кого то из-за установки иконки, но в целом зависит от процесса включения\выключения защиты от обработки событий, там внутри вставлена проверка счетчика и она фейлится, но проблема в том, что это кагбэ внутреннее апи.

Второй вариант и скорее всего правильный -  xapp от минтовцев и XAppStatusIcon https://github.com/linuxmint/xapp/blob/master/libxapp/xapp-status-icon.h, там есть и события и все плюшки, но разные системы идут с разными версиями либы и можно нарваться на более старую версию, так что выглядит менее универсальным. Но остается проблема с маками, насколько я понимаю, там нужен биндинг на AppKit, а там objective-c\swift. Пока, пожалуй, напишу свой враппер под обычный статус икон в 3, чтобы его апи не попал в код контроллеров, а потом можно уже подменить на что-то другое, но скорее на xapp.

> дёргаем по списку все стейты плагинов на предмет имеющихся в них колбеков

Как я понимаю, это можно реализовать через систему событий. В настройках плагина список событий, на которые он подписывается, далее отдельный контроллер системы плагинов подписывается на сервис-наблюдатель или же event bus и пробрасывает все события плагинам, что кому нужно в случае подписки fire and forget или же какой-то сервис плагина возвращает ответ на событие, когда он нужен.. что-то такое. Но появляется вопрос уже в самой системе событий. Есть более тонкая реализация шины сообщений через рефлексивное дергание методов подписанных на неё контроллеров по их сигнатурам и определения класса события, но т.к. в ди рантаймовая рефлексия затруднена, то есть смысл сделать просто сервис-наблюдатель с методами подписки\отписки. Обратная сторона - хаос и поступление событий в рандомный момент, проблема с очередностями вызовов, обратной связью от плагина и т.п. С другой стороны, это позволяет поместить часть вызовов плагинов в ядро фреймворка и потом копировать в программу без плагинов, просто выпиливая плагины и убирая лишнюю инициализацию, синхронизируя апи ядра между прогой с плагинами и нет.... а для моих простых пет-проектов это мне и нужно.

Ну я уже понял, что затупил, поместив плагины и завязку на lua в core программы

Но если плагины будут в предметном коде, то они должны перехватывать события из core, это нельзя сделать обычным наблюдателем\обратным вызовом из-за очень глубокой вложенности, только event-bus или что-то такое глобальное.

Чекни как это делали в SDL. Там, насколько я помню, есть модуль под ивенты, который держит состояние и собирает данные. На изменения — формирует список этих изменений (порядок изменений определяется порядком дёрганья проверяльщиков), после чего их можно поллить. Соответственно, каждое событие имеет тип и набор параметров. По типам, во время поллинга, можно дёргать луёвые колбеки.

Как вариант, при составлении списка событий, ты можешь указать им приоритет в зависимости от типа, времени прихода или ещё чего, а перед поллингом отсортировать. Это лёгкий костыль, но тоже работает.

ясно, спасибо. Мне что-то начинает напоминать как их там интеграционные паттерны вроде, их тоже можно взять за основу, наверное

хотя какой-то оверхед скорее всего выйдет бесполезный

Ну, указанная мной техника мне кажется весьма простой и эффективной.

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

возможно, возможно, нужно потестить

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

Я смотрю, что вот этот пакет на шину сообщений смахивает, его можно создать в руте и заинжектить потом куда только можно
https://code.dlang.org/packages/eventmanager Но либа явно мертвая

опять придется педалить велосипеды скорее всего 😒

Любопытно, а кто-нибудь использовал gtkd под макось? Под линуксом получается достаточно выгодная комба за счет с-биндингов на либы, а на маке же вроде как другой стек, если легко использовать либы проблематично, то тогда скорее электрон или флаттер и т.д. т.п.

Но это другие языки

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

Но я особо не стал разбираться, так как я им не пользуюсь

Мда... у меня нет винды под рукой, но раз с первого тыка не запускается, то это печально. Хотя давным давно я тыкал винформ и у меня все запускалось, а потом на целевом компе была какая-то версия нет-фреймворка была другая и прога легла. Так что выходит, что даже виндовый тулкит не смог в "кроссплатформенность" на одной системе. С другой стороны, когда я переходил с винды на линукс я забрал с собой несколько javafx-петов и они запустились более-менее, хотя с небольшими правками. Но опять-таки, каждый тулкит своей архитектурой определяет потолок кейсов, так что в любом случае скорее всего придется юзать другой язык рано или поздно для разных кейсов.