أضف واحدة مدورة حوالي 60 درجة عكس اتجاه عقارب الساعة و 180 درجة حول المحور ص وستحصل على عيون كائن تم إحياؤه
أضف صورة معكوسة تم تدويرها حول المحور ص بحيث تكون هناك صورتان (عينان)
اذهب يا ديسكورس ريكس
نعم، لا يمكنني إخراج هذا من رأسي وبالتأكيد أحتاج إلى الخروج أكثر
شكرًا لك. أبلغ أحد المستخدمين عن هذا. كانت هناك بعض المشكلات الغريبة في SVG (?) التي جعلت الصورة تبدو… غريبة عند تحميلها في منشور، ولكن ليس على شاشة التحميل.
يبدو معطلاً تمامًا هنا، حتى عند النقر عليه (يظهر شريط تحميل مزدوج…).
لكنه يبدو جيدًا عند استخدامه كشاشة بدء التشغيل.
لقد طلبت بغباء من Gemini “إصلاحه”، مما أدى إلى إنشاء SVG الذي نشرته ويبدو جيدًا، ومع ذلك يبدو أن بعض المستخدمين لديهم مشكلة تتعلق بشريط التقدم. أفترض أن هذا هو ما تراه:
لقد فتحتُ تطبيقًا أوليًا مرتبطًا بشكل منفصل، لكن الفكرة الأوسع هي ببساطة خطوة تالية محتملة لهذه الميزة:
لا تزال نهج SVG الواحد الحالي باستخدام var(--primary) و var(--secondary) و var(--tertiary) هو المسار الأنظف والأبسط لمعظم المواقع، خاصةً عندما يحتاج نفس ملف SVG فقط إلى تكييف ألوانه.
الحالة التي كنتُ أستكشفها هي حالة هامشية حيث يتطلب شاشات الترحيب في الوضع الداكن أصلًا مختلفًا حقًا أو معالجة بصرية، بدلًا من مجرد إعادة تلوين نفس ملف SVG. على سبيل المثال، قد يعمل رأس الصفحة الداكن للمستخدم المسجل الدخول بشكل أفضل مع معالجة شفافة واحدة للشعار/الخلفية، بينما قد يحتاج عرض تسجيل الدخول/الشاشة الترحيبية للمستخدم غير المسجل إلى خلفية فحمية مختلفة قليلاً أو ملف SVG مُعدّل لتحقيق تباين أفضل.
إذن، الفكرة ليست استبدال النهج الحالي القائم على المتغيرات، بل توفير مخرج احتياطي للمواقع التي تتطلب فيها أعمال الشاشة الترحيبية الداكنة حقًا أن تختلف عن أعمال الشاشة الترحيبية الفاتحة/الافتراضية.
نرحب بالتعليقات حول ما إذا كان ينبغي أن يكون هذا إعدادًا منفصلًا باسم splash_screen_image_dark، أو ما إذا كان ينبغي أن يظل نهج SVG الواحد + متغيرات الألوان هو المسار الوحيد المدعوم.