Дубликат/актуально: #284

Я начал работу над ним: https://github.com/bebehei/dunst/tree/dunstcmd

dunstcmd status уже работает в предварительной форме.

Привет! Спасибо за всю работу над этим. Я видел эту проблему, связанную с несколькими другими. Есть ли обновление статуса, позволяющее запрашивать, приостановлен ли данст или нет? Недавно я перешел на dunst, и обычно у меня есть тумблер для включения или выключения уведомлений. Меня убивает то, что, похоже, нет хорошего способа запросить эту информацию в dunst.

Обновлять особо нечего, это есть в дорожной карте, но прогресс — это только то, что вы видите в ветке выше. Я не уверен, что @bebehei все еще планирует работать над этим.

Да, я был на нем. Но пока я на самом деле не знаю, дописываю ли я клиентскую часть на C. Нынешняя архитектура для клиента уродлива. На самом деле я бы предпочел Python для клиента (или попробовал бы Rust).

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

Серверная часть "закончена". Я сбросил С-клиент. @stunkymonkey завершит клиентскую часть. Мы договорились с Rust.

Это круто, недавно я пытался изучить ржавчину, и это еще один повод заняться этим.

Есть ли где-нибудь репозиторий для него? (Или мы помещаем это сюда вместе со всем остальным?)

Есть ли где-нибудь репозиторий для него? (Или мы помещаем это сюда вместе со всем остальным?)

Есть проект, но в настоящее время он скрыт и предназначен только для тестового использования.

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

Итак, первый прототип работает:

• [x] закрытие одного уведомления
• [x] закрытие всех уведомлений
• [x] повторно отображать уведомления
• [x] открыть контекстное меню
• [x] получить статус dunst
• [x] установить статус dunst
• [ ] прослушать статус dunst

обработка ошибок выполняется для разбора аргументов, но не для dbus.

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

Публиковать! публиковать! публиковать! :тада:

Ура! Я думаю, что он готов к публикации первой версии! :тада:

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

Если мы поместим его в этот репозиторий:

• Мы добавим массу дополнительных зависимостей + совершенно новую систему компиляции для ящиков ржавчины, которые могут раздражать многих и усложнять процесс упаковки.
  
  
  
  • С другой стороны, это повлияет только на тех, кто строит из исходников, и на тех, кто занимается мейнтейнерами, так как rust статически связывает большинство вещей.
  
  
• Он будет более заметен и будет использоваться чаще, потому что он будет установлен вместе с
  
  
  
  • Верно для тех, кто собирает вручную, но мы также можем передать подсказку нижестоящим сопровождающим, чтобы они установили его вместе (в debian есть пакеты Recommend -ed, которые устанавливаются по умолчанию, если не отключены)
  
  

Если мы разделим его на другой проект

• Мы будем поощрять развитие альтернативных клиентов (хорошо)
• Он может быть недоступен в дистрибутивах в течение длительного времени, что снижает удобство использования.

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

Я считаю, что это главный недостаток.

Мы будем поощрять развитие альтернативных клиентов (хорошо)

Нам действительно нужны альтернативные клиенты? Интерфейс dbus не будет задокументирован, но если кому-то понадобится доступ к нему, его можно найти в коде. В основном набор функций в конечном итоге будет таким же, потому что он ограничен методами и свойствами dbus.

Для меня второй абзац абсолютно новый. Я никогда не думал об этом таким образом. Но на самом деле это абсолютно убийственный аргумент: я не хочу документировать интерфейс DBus и писать для него новую документацию по API.

Это действительно хороший аргумент. Однако мы должны относиться к изменениям в интерфейсе dbus как к несовместимым с предыдущими версиями/избегать их, где это возможно, чтобы не повлиять на тех, кто хочет его использовать.

Это действительно хороший аргумент. Однако мы должны относиться к изменениям в интерфейсе dbus как к несовместимым с предыдущими версиями/избегать их, где это возможно, чтобы не повлиять на тех, кто хочет его использовать.

Ну да, это легко. Нам просто нужно продолжить с именем нашего интерфейса. Распространенным стилем является добавление к имени интерфейса DBus увеличивающегося числа, начиная с 0.

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

вот это мой фиктивный репо

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

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

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

@bebehei Почему вы вообще отказались от написания клиента на C?

возможно, bash-скрипта может быть достаточно.

dbus-send --print-reply --dest=org.freedesktop.Notifications /org/freedesktop/Notifications org.dunstproject.cmd0.NotificationCloseLast

это может делать то же самое, что делает моя программа

@tcipinakis В основном я отказался от написания клиента на C, потому что это просто накладные расходы, накладные расходы, накладные расходы, накладные расходы, накладные расходы, а затем несколько строк кода, которые на самом деле имеют решающее значение.

Немного статистики: в ветке dunstcmd я создал клиентские файлы, в которых было ~500 LOC C. А у меня была только поддержка по статусу. @Stunkymonkey реализовал почти все в <200 LOC Rust.

Чтобы добиться правильной структуры подкоманд, у меня были огромные накладные расходы. Это начало казаться неправильным, даже когда я впервые запустил клиент. И снова взглянув на код, я с уверенностью могу сказать: C — неподходящий язык для клиента.

Я еще не уверен, что Rust — правильный язык для клиента. Я довольно не уверен, подходит ли bash лучше в качестве клиента. Если бы мне сейчас пришлось выбирать язык помимо Rust, это мог бы быть python.

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

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

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

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

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

взгляните на https://github.com/Stunkymonkey/dunstctl/blob/master/dunstctl
90 мест и почти такой же функционал

Ха, это помогло изменить мое мнение. На самом деле я предпочитаю это намного больше, чем что-либо еще, предложенное до сих пор.

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

В настоящее время я взял его на доработку и упаковал в свою ветку. PR будет, наверное, завтра.

Было бы полезно, если бы мы могли получить количество уведомлений, полученных, когда данст отключен.

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