Duplikat/relevan: #284

Saya mulai mengerjakannya: https://github.com/bebehei/dunst/tree/dunstcmd

dunstcmd status sudah bekerja dalam bentuk pendahuluan.

Hai! Terima kasih untuk semua pekerjaan ini. Saya telah melihat masalah ini ditautkan dari beberapa orang lain. Apakah ada pembaruan status pada kemampuan untuk dapat menanyakan apakah dunst dijeda atau tidak? Saya baru-baru ini beralih ke dunst dan biasanya hanya memiliki sakelar sakelar untuk mengaktifkan atau menonaktifkan notifikasi. Ini semacam membunuh saya bahwa tampaknya tidak ada cara yang baik untuk menanyakan info itu secara tidak sengaja.

Tidak banyak yang perlu diperbarui, itu ada di peta jalan tetapi kemajuannya hanya apa yang Anda lihat di cabang di atas. Saya tidak yakin apakah @bebehei masih berencana untuk mengerjakan ini.

Ya, saya pernah melakukannya. Tapi sementara itu, saya sebenarnya tidak tahu apakah saya menyelesaikan sisi klien di C. Arsitektur klien saat ini jelek. Saya sebenarnya lebih suka Python untuk klien (atau coba dengan Rust).

Di sisi server, masalah terpecahkan dan arsitekturnya jelas. Kumpulan fitur yang dimaksud belum diimplementasikan di sisi server, tetapi itu adalah permainan yang mudah.

Sisi server "selesai". Saya menjatuhkan klien-C. @stunkymonkey akan menyelesaikan sisi klien. Kami telah menyelesaikannya dengan Rust.

Itu luar biasa, saya baru-baru ini mencoba belajar karat dan ini adalah alasan lain untuk melakukannya.

Apakah ada repo yang disiapkan di suatu tempat untuk itu? (Atau apakah kita meletakkannya di sini bersama dengan yang lainnya?)

Apakah ada repo yang disiapkan di suatu tempat untuk itu? (Atau apakah kita meletakkannya di sini bersama dengan yang lainnya?)

Ada proyek, tetapi saat ini disembunyikan dan hanya untuk penggunaan pengujian.

Idk jika kita harus memasukkannya ke dalam repo utama. Kami sebenarnya harus menjadi klien agnostik dan kami menambahkan banyak dependensi kompilasi dengan memilih Rust. Tetapi di sisi lain, Jika kami tidak mengirimkan klien, tidak ada yang akan menggunakannya.

jadi prototipe pertama berfungsi:

• [x] menutup satu notifikasi
• [x] menutup semua notifikasi
• [x] menampilkan ulang notifikasi
• [x] buka menu konteks
• [x] dapatkan status dunst
• [x] setel status dunst
• [ ] dengarkan status dunst

penanganan kesalahan dilakukan untuk parsing arg, tetapi tidak untuk dbus.

sekarang kita harus membahas di mana untuk meletakkan kode. ya itu akan menambah banyak dependensi, tetapi saya pikir jika tidak, itu tidak akan digunakan, karena instalasi adalah langkah tambahan.

Menerbitkan! menerbitkan! menerbitkan! :tada:

Ya! Saya pikir itu siap untuk versi pertama yang diterbitkan! :tada:

Tentang di mana harus meletakkannya, saya belum memiliki pendapat yang jelas, saya hanya akan meletakkan pemikiran saya berdasarkan argumen yang disebutkan sejauh ini di sini dan menunggu umpan balik sebelum saya memantapkannya.

Jika kita memasukkannya ke dalam repositori ini:

• Kami akan menambahkan satu ton dependensi ekstra + sistem kompilasi baru untuk peti karat yang dapat mengganggu banyak orang, dan memperumit proses pengemasan
  
  
  
  • Di sisi lain, ini hanya akan memengaruhi bangunan dari sumber dan pengelola, karena karat menghubungkan sebagian besar hal secara statis
  
  
• Ini akan lebih terlihat dan digunakan lebih sering karena akan dipasang bersama
  
  
  
  • Benar untuk mereka yang membangun secara manual, tetapi kami juga dapat memberikan petunjuk kepada pengelola hilir untuk menginstalnya bersama (Di debian ada paket Recommend -ed yang diinstal secara default kecuali dinonaktifkan)
  
  

Jika kita membaginya menjadi proyek yang berbeda

• Kami akan mendorong pengembangan klien alternatif (baik)
• Ini mungkin tidak tersedia di distro untuk waktu yang lama, mengurangi kegunaan.

Ini mungkin tidak tersedia di distro untuk waktu yang lama, mengurangi kegunaan.

Saya pikir ini adalah kerugian utama.

Kami akan mendorong pengembangan klien alternatif (baik)

Apakah kita benar-benar membutuhkan klien alternatif? Antarmuka dbus tidak akan didokumentasikan, tetapi jika seseorang membutuhkan akses ke sana dapat dicari melalui kode. Sebagian besar set fitur pada akhirnya akan sama, karena dibatasi oleh metode dan properti dbus.

Bagi saya, paragraf kedua benar-benar baru bagi saya. Saya tidak pernah memikirkannya seperti ini. Tapi itu sebenarnya argumen pembunuh mutlak: Saya tidak ingin mendokumentasikan Antarmuka DBus dan menulis dokumen API baru untuk itu.

Itu memang argumen yang bagus. Namun kita harus memperlakukan perubahan pada antarmuka dbus sebagai tidak kompatibel/menghindari jika memungkinkan untuk menghindari mempengaruhi mereka yang ingin menggunakannya.

Itu memang argumen yang bagus. Namun kita harus memperlakukan perubahan pada antarmuka dbus sebagai tidak kompatibel/menghindari jika memungkinkan untuk menghindari mempengaruhi mereka yang ingin menggunakannya.

Nah ya, ini mudah. Kami hanya perlu melanjutkan dengan nama antarmuka kami. Ini adalah gaya umum untuk menambahkan nama Antarmuka DBus dengan nomor yang bertambah, dimulai dengan 0.

Jadi, kami hanya menambah angka pada perubahan yang tidak kompatibel ke belakang. Dan klien alternatif akan dengan sengaja menghentikan sampai perubahan yang melanggar dipertimbangkan.

ini dia repo dummy saya

Setelah meluangkan waktu untuk memikirkannya, saya juga mendukung penggabungannya dalam repo ini, dengan semua yang dikatakan di atas mempertimbangkan argumen utama yang membuat saya memperkuatnya adalah bahwa sebagian besar jika tidak semua pengguna akan menginginkan beberapa jenis pintasan untuk mengontrol dunst dan mengingat bahwa kita sedang mencela pintasan keyboard ini akan menjadi satu-satunya cara untuk melakukannya.

masih menjadi pertanyaan besar jika menyelesaikan dengan karat adalah ide yang tepat. Program kecil yang saya tulis berfungsi dengan baik, tetapi menambahkan banyak dependensi.

Itu satu-satunya kekhawatiran saya yang tersisa, ini terlihat seperti klien yang sangat tipis dan sederhana untuk menjamin bahasa baru dan alat pembuatan.

@bebehei Mengapa Anda menyerah menulis klien di C di tempat pertama?

mungkin skrip bash sudah cukup.

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

ini dapat melakukan hal yang sama dengan yang dilakukan program saya

@tsipinakis Saya terutama menyerah menulis klien di C, karena itu hanya overhead, overhead, overhead, overhead, overhead dan kemudian beberapa baris kode, yang sebenarnya penting.

Beberapa statistik: Di cabang dunstcmd, saya membuat file klien, yang memiliki ~500 LOC C . Dan saya hanya mendukung status. @Stunkymonkey mengimplementasikan hampir semuanya di <200 LOC of Rust.

Untuk mencapai struktur sub-perintah yang tepat, saya memiliki overhead yang sangat besar. Itu mulai terasa salah bahkan ketika saya awalnya memulai klien. Dan melihat kodenya lagi, saya yakin untuk mengatakan: C adalah bahasa yang salah untuk klien.

Saya belum yakin untuk mengatakan Rust adalah bahasa yang tepat untuk klien. Saya cukup tidak yakin, apakah bash lebih cocok sebagai klien. Jika saya harus memilih bahasa sekarang selain Rust, itu mungkin python.

Oke, melihat kodenya sendiri sekarang saya harus setuju bahwa itu banyak overhead untuk fungsionalitas kecil. C jelas terlalu banyak di sini.

Saya ragu untuk menggunakan bash karena IMO membatasi kemampuan kami untuk memperluas ini lebih jauh jika diperlukan. Kompleksitas skrip bash cenderung meningkat secara eksponensial saat fitur ditambahkan.

Seperti Anda, saya juga tidak yakin dengan bahasa yang harus dipilih sekarang, python sepertinya cocok, satu-satunya downside adalah dependensi runtime tambahan (ke python-dbus dan kemungkinan besar beberapa lagi).

saya masih lebih suka posix-Shell.
python diinstal di mana-mana dalam versi yang berbeda, yang dapat menyebabkan masalah.

Saya tidak yakin apakah kami akan meningkatkannya dengan banyak fitur di masa mendatang. Jumlah pintasan keyboard juga tidak bertambah seiring waktu.
Saat ini saya sedang menulis skrip shell untuk menunjukkan, bahwa tidak banyak yang dibutuhkan.

lihat di https://github.com/Stunkymonkey/dunstctl/blob/master/dunstctl
90 loc dan fungsi yang hampir sama

Huh, itu berhasil mengubah pikiranku. Saya sebenarnya lebih suka itu lebih dari apa pun yang diusulkan sampai sekarang.

Jika ada, itu hanya shell jadi kami tidak menambahkan dependensi tambahan - jika kami menemukan masalah, kami selalu dapat menulis ulang karena sesederhana itu.

Saat ini saya telah mengambilnya dalam revisi dan mengemasnya ke dalam cabang saya. PR akan menyusul mungkin besok.

Akan sangat berguna jika kita bisa mendapatkan jumlah notifikasi yang diterima saat dunst dimatikan.

Implementasi awal ini adalah penggabungan di #651, jadi saya akan menutup ini. Permintaan fitur lainnya harus menjadi masalah terpisah.