Ssr: احترام مواصفات الدليل الأساسي XDG

يبدو أن العديد من التطبيقات لديها هذه المشكلة ...

هذا ما قاله شخص ما على موقع جيثب # telegram

ستحترم IIRC ، Qt هؤلاء عند استخدام الواجهة الخلفية لإعدادات qt (على الأقل فعلت ذلك على هاتفي المحمول منذ بضع سنوات عندما استخدمت Qt آخر مرة).

اخترت عدم القيام بذلك لتجنب الأسئلة المستمرة حول مكان تخزين SSR لبياناته. يتعين علي دائمًا توجيه الأشخاص إلى ملف التكوين والسجلات ، ومن الأسهل كثيرًا قول "انظر في المجلد ~ / .ssr". AFAIK ما يفعله SSR كان إلى حد كبير هو القاعدة لسنوات. بالنظر إلى المجلد الرئيسي الخاص بي ومجلد التكوين ، يبدو أنه مقسم بنسبة 50/50.

على أي حال ، فإن الارتباك الذي قد أخلقه عن طريق نقل الموقع في هذه المرحلة لا يستحق كل هذا العناء IMHO. ومع ذلك ، لدي بعض الخطط لتغيير تنسيق ملف التكوين في وقت ما في المستقبل (التنسيق الحالي مقيد للغاية) ، لذلك عندما أفعل ذلك يمكنني تغيير الموقع أيضًا.

AFAIK ما يفعله SSR كان إلى حد كبير هو القاعدة لسنوات. بالنظر إلى المجلد الرئيسي الخاص بي ومجلد التكوين ، يبدو أنه مقسم بنسبة 50/50.

نعم ، لأن المعيار الجديد غير موجود لفترة طويلة. حتى كيدي لم يستخدمه مع سلسلة 4.x. الآن مع Framework5 / Qt5 أصبح كل شيء في المكان الصحيح. وكذلك معظم تطبيقات Qt5 ، وألعاب Unity3D ، وعناصر تطبيقات Google ، وأشياء gnome و gtk3 ..
يجب أن تفكر حقًا في التبديل بإصدار Qt5 (؟) في المستقبل لاحقًا

Qt5 لا يزال عربات التي تجرها الدواب قليلاً ، لذلك احتفظ بـ Qt4 كإعداد افتراضي في الوقت الحالي. على أي حال ، لن أستخدم نظام إعدادات Qt بعد الآن ، أخطط للتبديل إلى JSON. سأحاول نقل الموقع عندما أقوم بتغيير تنسيق الملف.

MaartenBaert هل من أخبار حول هذا؟

ليس لدي الكثير من الوقت للعمل على SSR بعد الآن ، لذا لم يحدث هذا بعد. أنا لا أعتبر هذا أولوية.

MaartenBaert أخذت الحرية لإنشاء تصحيح لهذه المشكلة في # 499. يرجى إعلامي إذا كان يحتاج إلى أي إصلاح قبل الدمج هناك.

لا يمكنني فعل ذلك ، سيؤدي إلى كسر التوافق مع الإصدارات السابقة. كما أوضحت ، لا أعتبر هذا مهمًا بدرجة كافية لنقل ملفات إعدادات المستخدم وإنشاء مصادر الارتباك. غالبًا ما أطلب من الأشخاص إرسال ملف التكوين الخاص بهم إليّ عندما يبلغون عن خطأ ، ولا أريد أن أوضح لهم أن الملف يمكن أن يكون في موقعين مختلفين اعتمادًا على الإصدار. لذلك لن أقوم بهذا حتى أكمل الانتقال إلى تنسيق JSON الجديد الذي سيؤدي إلى كسر التوافق مع الإصدارات السابقة على أي حال.

يوجد رمز ترحيل في التصحيح يتم تشغيله تلقائيًا عند التشغيل الأول للتعامل مع التوافق مع الإصدارات السابقة.

أعلم أن تنسيق JSON يحتوي على رمز مشابه ، باستثناء أنه يقوم أيضًا بتحويل التنسيق. لا أريد التعامل مع كسر الأشياء مرتين ، هذه هي المشكلة. سيكون الأمر قبيحًا بدرجة كافية لأنني سأحتاج إلى الحفاظ على دعم تنسيق ملف الإعدادات القديم من أجل إجراء التحويل. لا أريد أيضًا البحث عن هذه الملفات في مكانين مختلفين. يرجى إدراك أن مواصفات XDG هذه مجرد اتفاقية ، وليس لها أي تأثير على الإطلاق على كيفية إدراك المستخدمين للبرنامج. لن يهتموا بذلك ، ولا يزال هناك الكثير من البرامج الأخرى المشهورة جدًا في الدليل الرئيسي (مثل Firefox) ، لذلك لا أريد إنشاء عمل إضافي لنفسي بدون سبب.

إذا كنت تريد حقًا مجلد .ssr في ~ / .config ، فيمكنك فقط ربطه بالرمز هناك ، فلن يهتم SSR.

إنه لا يكسر الأشياء حقًا عندما يكون لديك مسار مباشر للهجرة. يمكنني إلقاء نظرة على فرع JSON ونقل التصحيح هناك. على الرغم من أنني أجد أنه من الغريب أن تقوم بتبديل الإعدادات إلى تنسيق JSON ، إلا أن ملفات INI جيدة تمامًا لتخزين الإعدادات ولا يقدم JSON سوى مزايا أخرى كتنسيق تبادل. مع ذلك ، فإن إضافة مسار ترحيل إلى JSON مباشرة بعد رمز الترحيل الذي تمت إضافته بواسطة هذا التصحيح سيوفر عليك الاضطرار إلى الاحتفاظ بالمسارات القديمة أو التنسيق القديم.

تعتبر مواصفات XDG من الاصطلاحات المستخدمة على نطاق واسع وبسببها في الواقع ، لها تأثير على كيفية إدراك المستخدمين للبرنامج. راجع تقارير الأخطاء لـ: Thunderbird و Cargo و Firefox و IntelliJ IDEA و Telegram و Visual Studio Code و node-gyp و PlayOnLinux ... يمكنني

لا يحب العديد من المستخدمين رؤية مجلداتهم الرئيسية ملوثة بمجلد لكل تطبيق ، ولكل واحد من هؤلاء الذين لا يتبعون المواصفات ، هناك حاجة لحالة خاصة في أي برنامج نصي للنسخ الاحتياطي للتكوين.

من خلال إصلاح هذا الخطأ ، لن تضيف أي عمل لنفسك لأن هذا هو ما تم تصميم المواصفات لحلها. تنتقل ملفات التهيئة إلى $XDG_CONFIG_HOME/ssr ، وهي ~/.config/ssr افتراضيًا. ملفات البيانات الأخرى مثل السجلات ، انتقل إلى $XDG_DATA_HOME/ssr ، ~/.local/share/ssr افتراضيًا؛ وهذا متسق. يتوقع المستخدمون أن تحترم تطبيقات Linux هذه الاتفاقيات ، لذلك هذا ما يبحثون عنه. التصحيح جاهز ، وحتى إذا انتهيت من تبديل تنسيقات الملفات ، فلن يتم كسر أي كود طالما أنك تستدعي الدالات الصحيحة GetApplicationConfigDir و GetApplicationDataDir (مع الاستدعاءات الحالية إلى GetApplicationDataDir تمت إزالته

أنت لا تعرف أنني أقضي الآن وقتًا طويلاً في دعم SSR أكثر من تطويره. إنه أمر محبط ولكن هذا هو الحال. لذا فإن أي شيء يجعل استكشاف الأخطاء وإصلاحها أكثر صعوبة يكلفني _lot_ من الوقت. والتحرك حول ملفات التكوين هو أحد هذه الأشياء. يمكنك الاستمرار في تكراره ولكن ما زلت لا أعتقد أن فائدة وجود ملفات SSR في المكان الصحيح ستفوق الوقت الإضافي الذي سيكلفني فيه أن أشرح للمستخدمين المرتبكين أين يمكنهم العثور على ملفاتهم ، ولماذا التعليمات التي يقومون بها يتم العثور عليها في المنتديات العشوائية / المدونات / مشكلات github / ... لم تعد صالحة. ثم هناك تكلفة الصيانة المستقبلية لرمز الانتقال. لا يوجد رمز خالي من الصيانة ، خاصةً التعليمات البرمجية التي تتفاعل مع أشياء خارجية متغيرة مثل ملفات التكوين.

إذا كنت لا تعتقد أن هذا سيؤدي إلى إرباك المستخدمين ، دعني أخبرك بهذا: أتلقى بشكل متكرر رسائل بريد إلكتروني من أشخاص يسألونني عن سبب تقسيم ملفاتهم أو عدم تقسيمها إلى أجزاء. على الرغم من أن مربع الاختيار "ملف منفصل لكل مقطع" محدد بشكل واضح ويوجد أسفل اسم الملف مباشرةً. يجب أن يكون هذا هو المكان الأكثر وضوحًا للبحث عنه عند التعامل مع شيء يتعلق بحفظ الملفات ، ومع ذلك يبدو أن الكثير من الناس يفوتونه تمامًا ويبدأون في إرسال بريد إلكتروني للسؤال عن سبب حدوث ذلك. وأنا أعلم أن نصف هؤلاء الأشخاص قد نقروا على مربع الاختيار هذا مرة واحدة على الأقل لأنهم غيروه من المربع الافتراضي. الناس _ حقًا_ يجيدون الشعور بالارتباك على ما يبدو ، كما أنهم جيدون حقًا في مراسلتي عبر البريد الإلكتروني عندما يحدث ذلك ، لكنهم ليسوا جيدين في اكتشاف ذلك لأنفسهم ؛).

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

حدث التبديل إلى JSON لأن ملفات INI لا تحتوي على دعم لائق للقوائم ، وهو ما أحتاجه للجداول. لا أجد أنه من المقبول استخدام المفاتيح ذات الأرقام المتزايدة مثل كيدي ، هذا مجرد شيء قبيح. أردت أيضًا الابتعاد عن Qt لهذا لأن ملفات الإعدادات هي شيء من الخلفية وليس من المفترض أن تختلط الواجهة الخلفية بشكل كبير مع Qt. لذلك تحولت إلى JSON. ثم قررت أنه إذا كنت سأقوم بالتبديل ، فيجب أن أقوم بإجراء التنسيق على الفور بحيث يسمح بإدخال عدة مقاطع فيديو وصوت في المستقبل ، بالإضافة إلى بعض الأشياء الأخرى مثل CLI. أردت أيضًا نقل الكود الذي يتعامل مع ملفات الإعدادات من واجهة المستخدم الرسومية بحيث يمكن الوصول إليها لدعم CLI دون الاعتماد على واجهة المستخدم الرسومية على الإطلاق. أجبرني هذا بعد ذلك على إجراء تغييرات كبيرة على كيفية معالجة إعدادات التسجيل وكذلك نقل كل منطق التسجيل من PageRecord إلى فئات جديدة. لقد علقت في مكان ما هناك - كانت التغييرات جذرية للغاية وفقدت مسار ما كان يحدث في المكان ، ولم يكن لدي الوقت لإصلاحه. لذلك تخليت عنها. الآن كنت أقصد سحب القطع القابلة للاستخدام منه ، مثل دعم JSON ، ودمجها في الفرع الرئيسي واحدًا تلو الآخر ، لأن هذا هو المسار الواقعي الوحيد.

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

MaartenBaert حسنًا ، بقدر ما يذهب دعم المستخدم ، يمكنني فقط أن أقترح عليك أن يكون لديك نموذج كلما تم الاتصال بك عن طريق البريد الإلكتروني للحصول على الدعم الذي يوجه المستخدم إلى GitHub لفتح مشكلة تم وضع علامة "دعم" عليها ، أو حتى تجنبها GitHub وأشر إلى منتدى Linux ، واجعلهم يعرفون ألا يزعجوك شخصيًا. أنت المطور الرئيسي لمشروع مشهور إلى حد ما ، يجب أن تشغل نفسك بالكود أكثر من المجتمع :).

بالنسبة إلى مخاوفك بشأن المعلومات القديمة ، لا أعتقد أن هناك تداخلًا كافيًا في الأشخاص بحيث أ) يتلاعب بملفات تكوين SSR ب) لا يعرف عن مواصفات XDG dir و ج) سيتصلون بك للحصول على حل لمشكلتهم مشاكل ، ليكون عبئًا أكبر من مجرد متابعة هذه المحادثة ، حتى إذا أضفتها جميعًا معًا ... وفي النهاية إذا كان SSR يتحول إلى ملفات JSON ... سيكون لديك "خاسر" مشكلة بطريقة أو بأخرى.

فيما يتعلق بالموضوع الآخر الذي ظهر ، وهو الفصل بين الاهتمامات ... أعتقد أنك في تلك المرحلة تتحدث عن إعادة كتابة. كما تعلم ، فإن Qt4 متشابك بشدة مع معظم جوانب التطبيق. سيتعين عليك إعادة كتابة مجموعة كبيرة من الأشياء لتحديد واجهات واضحة واستبدال أنواع Qt بأنواع الأمراض المنقولة جنسياً لمجرد لصقها مرة أخرى على واجهة المستخدم الرسومية ... وهكذا ... يمكن توجيه الجهود بشكل أفضل إلى توسيع libobs من OBS Studio وكتابة واجهة أمامية أبسط وأكثر إبداءً للرأي لها وهي SSR's _forte_.

على أي حال ، إذا كنت لا ترغب في أن تتبع SSR اتفاقيات XDG ، فلا تتردد في إغلاق العلاقات العامة الخاصة بي ، وأفترض ، هذه المشكلة. لطيفة التحدث إليكم :) أتمنى لك فكرة جيدة.

ملاحظة

منتجات موزيلا ليست أمثلة جيدة. لست مندهشًا من إدراك أن هذه المجموعة التي تهدف إلى الربح (وليس مدفوعة بالوصول المجاني) ، والتي لديها موارد كافية لتبنيها في XDG من الآن إلى الساعة التالية ، لم تفعل أي شيء في هذا الشأن ، خلال أكثر من 10 سنوات .

أعتقد أن Mozilla تفضل أن تظل منتجاتها أقل من /home/username/.product لأسباب تسويقية ، لذلك ربما يلتقط المستخدمون لقطات شاشة لمديري الملفات (أو وحدات التحكم) ، التي تعرض منتجات Mozilla ، بطريق الخطأ ، وقد يعتقد البعض أن Mozilla لا تزال كذلك شائع.

موزيلا جيدة فقط للوثائق ، IMHO.

أعرف أن الكثير من المناقشات هنا قد انحرفت عن الموضوع ، لكنني أشعر بالفضول تجاهMaartenBaert - هل فكرت في yaml vs json لتنسيق التكوين؟ كما ذكرنا ، فإن الميزة الحقيقية لـ json هي تنسيق التبادل (الأجزاء المقطوعة غير صالحة بشكل واضح) ، و yaml أكثر قابلية للقراءة والتحرير من قبل الإنسان.

المقروئية ذاتية للغاية. بالنسبة لي ، يعد JSON أكثر سهولة ، لأنني معتاد على كتابة كود C ++ و Python. الصيغة متطابقة تقريبًا. إذا اضطررت إلى كتابة بيانات YAML ، فلا بد لي من البحث عن القواعد. يتناسب JSON أيضًا بشكل أفضل مع أنظمة الكتابة التي اعتدت عليها.

جميع أنواع json تقريبًا صالحة أيضًا yaml ، وبقدر ما أعرف ، فإن جميع أنواع json هي أيضًا أنواع yaml صالحة. أنا شخصياً أجد التعليقات مفيدة للغاية في ملفات التكوين ، ولا تدعم json التعليقات (انعكاس آخر للتصميم الموجه نحو التبادل وليس التصميم الموجه نحو الإنسان).

ولكن لا مانع لي، وأنا فعلا انتهى هنا عن طريق الصدفة ولست ssr المستخدم على أي حال.

أنا مستخدم ssr لعدة سنوات ولم أحتج مطلقًا إلى تحرير ملف التكوين يدويًا. لذلك إذا كان هذا هو الحال في أي واجهة مستخدم رسومية محدثة أو تطبيق مستقبلي ، فأنا كمستخدم لا أهتم إذا كان التكوين هو json أو yaml. أوافق على أن yaml هو تنسيق ملف تهيئة أفضل. ومع ذلك ، فقد تعلمت مؤخرًا عن HOCON ، ويبدو أنه يحتوي على بعض الميزات cpp يسمى

لقد قمت الآن بتنفيذ حل وسط: إذا كان الدليل ~/.ssr غير موجود ، ولكن الدليل ~/.config/simplescreenrecorder موجود ، فسيتم استخدامه بدلاً من ذلك. في جميع الحالات الأخرى ، سيتراجع SSR إلى ~/.ssr ، ليتم إنشاؤه إذا لزم الأمر. لذلك يمكنك الآن نقل دليل SSR يدويًا والحفاظ على نظافة المجلد الرئيسي (أكثر) إذا كنت تفضل ذلك.

هذه خطوة جيدة للأمام ، شكرًا!

لسوء الحظ ، لا يزال لا يؤثر على عمليات التثبيت الحديثة ، لذلك فهو غير مفيد جدًا بشكل افتراضي.