تخصيص شاشة البدء لـ Discourse بصور SVG مخصصة

زاحف للغاية!

أضف واحدة مدورة حوالي 60 درجة عكس اتجاه عقارب الساعة و 180 درجة حول المحور ص وستحصل على عيون كائن تم إحياؤه
أضف صورة معكوسة تم تدويرها حول المحور ص بحيث تكون هناك صورتان (عينان)

اذهب يا ديسكورس ريكس
نعم، لا يمكنني إخراج هذا من رأسي وبالتأكيد أحتاج إلى الخروج أكثر

إعجابَين (2)

لقد وضعت مُحمّلاً (loader) للدراجة أحادية العجلة هنا! https://unicyclist.com
رائع!

الرسوم المتحركة الأصلية كانت مني باستخدام CSS فقط، وطلبت من Gemini “تحويلها” (بمعنى ما) إلى SVG.

10 إعجابات

على شاشة التحميل الخاصة بـ https://unicyclist.com، يبدو شريط التحميل ممتدًا إلى ما وراء الخلفية.

إعجاب واحد (1)

شكرًا لك. أبلغ أحد المستخدمين عن هذا. كانت هناك بعض المشكلات الغريبة في SVG (?) التي جعلت الصورة تبدو… غريبة عند تحميلها في منشور، ولكن ليس على شاشة التحميل.

على سبيل المثال، هذا الإصدار الأقدم:

يبدو معطلاً تمامًا هنا، حتى عند النقر عليه (يظهر شريط تحميل مزدوج…).
لكنه يبدو جيدًا عند استخدامه كشاشة بدء التشغيل.

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

ليس لدي أي مشكلة على نظام التشغيل Windows باستخدام Chrome/Firefox أو Android/Chrome.

لا أعرف ما إذا كان هناك أي نوع من العلاقة بين Discourse وهذه الأخطاء.

لذا، للبقاء في الموضوع، بخلاف الرسوم المتحركة غير المعتمدة على CSS، هل هناك أي شيء يجب الانتباه إليه عندما نريد استخدام SVG متحرك لشاشة بدء التشغيل؟

إعجابَين (2)

أنا أستخدم clipPaths في ملفات SVG الخاصة بي لمنع العناصر من التدفق خارج الحدود.
ربما يكون توجيه Gemini بالطريقة التالية فعالاً:

شريط التقدم في ملف SVG هذا يمتد إلى ما وراء الخلفية. يرجى تعديله لضمان بقائه ضمن حدود الخلفية باستخدام `clipPath`.
4 إعجابات

شكرًا جزيلاً على الميزة، لقد حاولت بنفسي أيضًا، لست راضيًا تمامًا بعد ولكني أعمل على إصلاحها :smiley:

10 إعجابات

لا يمكن تخصيص الحجم

إن Gemini 3.5 Flash الجديد أفضل حتى في هذا

13 إعجابًا

لقد فتحتُ تطبيقًا أوليًا مرتبطًا بشكل منفصل، لكن الفكرة الأوسع هي ببساطة خطوة تالية محتملة لهذه الميزة:

لا تزال نهج SVG الواحد الحالي باستخدام var(--primary) و var(--secondary) و var(--tertiary) هو المسار الأنظف والأبسط لمعظم المواقع، خاصةً عندما يحتاج نفس ملف SVG فقط إلى تكييف ألوانه.

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

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

نرحب بالتعليقات حول ما إذا كان ينبغي أن يكون هذا إعدادًا منفصلًا باسم splash_screen_image_dark، أو ما إذا كان ينبغي أن يظل نهج SVG الواحد + متغيرات الألوان هو المسار الوحيد المدعوم.

إعجاب واحد (1)