زاحف للغاية!
أضف واحدة مدورة حوالي 60 درجة عكس اتجاه عقارب الساعة و 180 درجة حول المحور ص وستحصل على عيون كائن تم إحياؤه
أضف صورة معكوسة تم تدويرها حول المحور ص بحيث تكون هناك صورتان (عينان)
اذهب يا ديسكورس ريكس
نعم، لا يمكنني إخراج هذا من رأسي وبالتأكيد أحتاج إلى الخروج أكثر
لقد وضعت مُحمّلاً (loader) للدراجة أحادية العجلة هنا! https://unicyclist.com
رائع!
الرسوم المتحركة الأصلية كانت مني باستخدام CSS فقط، وطلبت من Gemini “تحويلها” (بمعنى ما) إلى SVG.
على شاشة التحميل الخاصة بـ https://unicyclist.com، يبدو شريط التحميل ممتدًا إلى ما وراء الخلفية.
شكرًا لك. أبلغ أحد المستخدمين عن هذا. كانت هناك بعض المشكلات الغريبة في SVG (?) التي جعلت الصورة تبدو… غريبة عند تحميلها في منشور، ولكن ليس على شاشة التحميل.
على سبيل المثال، هذا الإصدار الأقدم:
يبدو معطلاً تمامًا هنا، حتى عند النقر عليه (يظهر شريط تحميل مزدوج…).
لكنه يبدو جيدًا عند استخدامه كشاشة بدء التشغيل.
لقد طلبت بغباء من Gemini “إصلاحه”، مما أدى إلى إنشاء SVG الذي نشرته ويبدو جيدًا، ومع ذلك يبدو أن بعض المستخدمين لديهم مشكلة تتعلق بشريط التقدم. أفترض أن هذا هو ما تراه:
ليس لدي أي مشكلة على نظام التشغيل Windows باستخدام Chrome/Firefox أو Android/Chrome.
لا أعرف ما إذا كان هناك أي نوع من العلاقة بين Discourse وهذه الأخطاء.
لذا، للبقاء في الموضوع، بخلاف الرسوم المتحركة غير المعتمدة على CSS، هل هناك أي شيء يجب الانتباه إليه عندما نريد استخدام SVG متحرك لشاشة بدء التشغيل؟
أنا أستخدم clipPaths في ملفات SVG الخاصة بي لمنع العناصر من التدفق خارج الحدود.
ربما يكون توجيه Gemini بالطريقة التالية فعالاً:
شريط التقدم في ملف SVG هذا يمتد إلى ما وراء الخلفية. يرجى تعديله لضمان بقائه ضمن حدود الخلفية باستخدام `clipPath`.
لقد فتحتُ تطبيقًا أوليًا مرتبطًا بشكل منفصل، لكن الفكرة الأوسع هي ببساطة خطوة تالية محتملة لهذه الميزة:
لا تزال نهج SVG الواحد الحالي باستخدام var(--primary) و var(--secondary) و var(--tertiary) هو المسار الأنظف والأبسط لمعظم المواقع، خاصةً عندما يحتاج نفس ملف SVG فقط إلى تكييف ألوانه.
الحالة التي كنتُ أستكشفها هي حالة هامشية حيث يتطلب شاشات الترحيب في الوضع الداكن أصلًا مختلفًا حقًا أو معالجة بصرية، بدلًا من مجرد إعادة تلوين نفس ملف SVG. على سبيل المثال، قد يعمل رأس الصفحة الداكن للمستخدم المسجل الدخول بشكل أفضل مع معالجة شفافة واحدة للشعار/الخلفية، بينما قد يحتاج عرض تسجيل الدخول/الشاشة الترحيبية للمستخدم غير المسجل إلى خلفية فحمية مختلفة قليلاً أو ملف SVG مُعدّل لتحقيق تباين أفضل.
إذن، الفكرة ليست استبدال النهج الحالي القائم على المتغيرات، بل توفير مخرج احتياطي للمواقع التي تتطلب فيها أعمال الشاشة الترحيبية الداكنة حقًا أن تختلف عن أعمال الشاشة الترحيبية الفاتحة/الافتراضية.
نرحب بالتعليقات حول ما إذا كان ينبغي أن يكون هذا إعدادًا منفصلًا باسم splash_screen_image_dark، أو ما إذا كان ينبغي أن يظل نهج SVG الواحد + متغيرات الألوان هو المسار الوحيد المدعوم.
حاولت في البداية استخدام SVG متحرك لشاشة البداية. وعلى الرغم من أن هذا يعمل على سطح المكتب، إلا أنني اكتشفت أنه على الأجهزة المحمولة، يؤدي تحريك المسارات المعقدة أو العناصر الداخلية لـ SVG مباشرة إلى تأخر في الأداء وتوقف الرسوم المتحركة حتى.
لضمان تجربة سلسة، نقلت منطق الرسوم المتحركة إلى حاوية HTML قياسية (div) تحيط بـ SVG. ومن خلال تطبيق رسوم CSS المتحركة (transform, scale, opacity) على غلاف div بدلاً من SVG، يمكن للمتصفحات المحمولة استخدام التسريع بالأجهزة بكفاءة أكبر دون تأخر.
أتساءل عما إذا كان يمكن توسيع نطاق الدالة لتشكيل WebP المتحرك، أم أنها مرتبطة ارتباطًا وثيقًا بتحويلات CSS؟
أقصد أن ملفات GIF تكون ثقيلة، لكن WebP أصبح معيارًا شائعًا وغير خاسر للبيانات في أيامنا هذه. يمكنني الحصول على 5 ثوانٍ من الرسوم المتحركة بمقاس 200x200 بكسل بمعدل 15 إطارًا في الثانية بحجم 50/100 كيلوبايت. ويمكن تقليل الحجم أكثر إلى 2/3 ثوانٍ عند تكرار الحلقة.
هل يمكن دعم أنماط الوضع الداكن/الفاتح؟
كلما قمت بتعديل ملف SVG، تُصدر الواجهة رسالة خطأ أثناء الرفع، رغم أن الملف موجود ويعمل بشكل طبيعي على أي حال.
أردّ على نفسي لأنني كنت أخطئ. يكفي ببساطة الإشارة إلى متغيرات CSS الخاصة بنظام ألوان Discourse داخل SVG، فسيتم عرض الحركة المطلوبة للوضع الفاتح والداكن تلقائيًا.
أرى أنه تم ذكر الحجم. هل هناك خطط لدعم نسخة أكبر قليلاً من حركة الترحيب (splash animation)؟
أقوم بقص جميع المساحات الفارغة المحيطة بالحركة، لذا آمل أن يُعطي ذلك انطباعاً بأن الصورة أكبر.
