مكرر / ذو صلة: # 284

لقد بدأت العمل عليه: https://github.com/bebehei/dunst/tree/dunstcmd

dunstcmd status يعمل بالفعل في نموذج تمهيدي.

مهلا! شكرا لكل العمل على هذا. لقد رأيت هذه المشكلة مرتبطة ببعضها البعض. هل هناك تحديث للحالة على القدرة على الاستعلام عما إذا كان dunst متوقفًا مؤقتًا أم لا؟ لقد تحولت مؤخرًا إلى dunst وعادة ما يكون لدي فقط مفتاح تبديل لتشغيل أو إيقاف تشغيل الإشعارات. إنه أمر يقتلني نوعًا ما لأنه ليس هناك على ما يبدو طريقة جيدة للاستعلام عن هذه المعلومات في dunst.

ليس هناك الكثير لتحديثه ، إنه على خريطة الطريق ولكن التقدم هو فقط ما تراه في الفرع أعلاه. لست متأكدًا مما إذا كان bebehei لا يزال يخطط للعمل على هذا.

نعم ، لقد كنت عليه. لكن في غضون ذلك ، لا أعرف في الواقع ما إذا كنت أنهي جانب العميل في C. الهيكل الحالي للعميل قبيح. أنا في الواقع أفضل Python للعميل (أو أجرب مع Rust).

على جانب الخادم ، تم حل المشكلات والبنية واضحة. لم يتم تنفيذ مجموعة الميزات المقصودة على جانب الخادم بعد ، ولكن هذه لعبة سهلة.

جانب الخادم "انتهى". لقد أسقطت العميل C. stunkymonkey سينهي جانب العميل. لقد استقرنا مع Rust.

هذا رائع ، لقد كنت أحاول تعلم الصدأ مؤخرًا وهذا عذر آخر للوصول إليه.

هل هناك ريبو تم إعداده في مكان ما لذلك؟ (أم أننا نضعها هنا مع كل شيء آخر؟)

هل هناك ريبو تم إعداده في مكان ما لذلك؟ (أم أننا نضعها هنا مع كل شيء آخر؟)

يوجد مشروع ، لكنه مخفي حاليًا وهو مخصص للاستخدام التجريبي فقط.

لا أعرف إذا كان علينا وضعها في الريبو الرئيسي. في الواقع ، يجب أن نكون محايدين للعميل ونضيف الكثير من تبعيات التجميع عن طريق اختيار Rust. ولكن من ناحية أخرى ، إذا لم نشحن العميل ، فلن يستخدمه أحد على الإطلاق.

لذلك فإن النموذج الأولي يعمل:

• [x] إغلاق إخطار واحد
• [x] إغلاق كافة الإخطارات
• [x] إعادة عرض الإخطارات
• [x] فتح قائمة السياق
• [x] الحصول على حالة dunst
• [x] تعيين حالة dunst
• [] الاستماع حالة dunst

تتم معالجة الخطأ لتحليل الوسائط ، ولكن ليس لتحليل dbus.

الآن علينا أن نناقش مكان وضع الكود. نعم ، سيضيف الكثير من التبعيات ، لكنني أعتقد أنه بخلاف ذلك لن يتم استخدامه ، لأن التثبيت يعد خطوة إضافية.

ينشر! ينشر! ينشر! : تادا:

ياي! أعتقد أنه جاهز للنسخة الأولى المنشورة! : تادا:

حول مكان وضعه ، ليس لدي رأي واضح حتى الآن ، سأقوم فقط بوضع قطار أفكاري بناءً على الحجج المذكورة حتى الآن هنا وانتظر بعض التعليقات قبل أن أقوم بتوطيدها.

إذا وضعناه في هذا المستودع:

• سنضيف الكثير من التبعيات الإضافية + نظام تجميع جديد تمامًا لصناديق الصدأ مما قد يزعج الكثيرين ، ويعقد عملية التغليف
  
  
  
  • من ناحية أخرى ، سيؤثر هذا فقط على أولئك الذين يبنون من المصدر والقائمين على الصيانة ، حيث أن الصدأ يربط معظم الأشياء بشكل ثابت
  
  
• سيكون أكثر وضوحًا ويستخدم في كثير من الأحيان لأنه سيتم تثبيته جنبًا إلى جنب
  
  
  
  • صحيح لأولئك الذين يبنون يدويًا ، ولكن يمكننا أيضًا تمرير تلميح إلى المشرفين على المصب لتثبيته جنبًا إلى جنب (في 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

هذا يمكن أن يفعل نفس الشيء الذي يفعله برنامجي

tsipinakis لقد تخليت بشكل أساسي عن كتابة العميل بلغة 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 موقع وتقريبا نفس الوظيفة

هاه ، هذا نجح في تغيير رأيي. أنا في الواقع أفضل ذلك أكثر بكثير من أي شيء آخر مقترح حتى الآن.

إذا كان هناك أي شيء ، فهو مجرد صدفة ، لذا فنحن لا نضيف أي تبعيات إضافية - إذا واجهنا مشكلة ما ، فيمكننا دائمًا إعادة كتابتها لأنها بهذه البساطة.

لقد أخرجته حاليًا قيد المراجعة وقمت بتعبئته في فرعي. العلاقات العامة ستتبع على الأرجح غدًا.

سيكون من المفيد لو تمكنا من الحصول على عدد الإخطارات المستلمة عندما يتم كتم صوت dunst.

تم دمج التنفيذ الأولي لهذا في # 651 ، لذلك سأغلق هذا. يجب أن تكون أي طلبات ميزة أخرى قضايا منفصلة.