كما نعلم بالفعل ، تم إصدار KDE Next (أو KDE 5 كما تفضل) على أنه مستقر منذ بضعة أيام ومن بين الميزات الجديدة التي يقدمها ، أحد أكثر الميزات التي تحدث عنها هو العمل الفني الجديد المسمى Breeze.
أولئك الذين جربوا هذا الإصدار الجديد بالفعل أو شاهدوا الفيديو ، ربما لاحظوا أنه في حالة مصمم النوافذ ، فإن الشخص الذي يأتي افتراضيًا هو Oxygen وليس Breeze. كذلك مارتن غراسلين يشرح لنا على مدونته ما هو سبب هذا القرار.
نظرًا لأن المقالة باللغة الإنجليزية ، سأحاول أن أقدم لك الفكرة الأساسية لهذا.
لماذا لا يأتي بريز بشكل افتراضي؟
أبدأ بشرح كيفية عمل زخارف النوافذ في KWin 4. KWin هو ما يسمى بإعادة الأبوة والأمومة لمديري النوافذ. هذا يعني أن النافذة التي يديرها X11 يتم وضعها في نافذة X11 أخرى توفر إطار النافذة. في KWin ، نستخدم QWidget لإطار النافذة. لذلك نحن مقيدون أيضًا بما توفره لنا QWidget ... الحل الذي نقدمه هو اعتراض جميع أحداث طلاء الزخرفة في QWidget وقمعها ، وتشغيل إعادة رسم الملحن وفي خطوة العرض نضمن زخرفة صورة مؤقتة بعد ذلك يتم نسخها في نسيج.
تستند زخرفة نافذة Breeze على شكل محرك Aurorae. نظرًا لأنني المؤلف الرئيسي لـ Aurorae ، يمكنني عرضه في منشور المدونة هذا دون الشعور بالسوء حيال ذلك 🙂 تم تصميم Aurorae ليكون من السهل جدًا إنشاء زخرفة والاستفادة من ميزات الشفافية الجديدة. أن يكون حلاً يمكن استخدامه كديكور افتراضي ، لكنه لم يكن هدفهم أبدًا. كانت الفكرة هي السماح للمستخدمين الذين يرغبون في تخصيص هذه الميزة ، بينما يمكن لمعظم المستخدمين استخدام سمات أصلية أسرع. لم تكن الشفق القطبي سريعة أبدًا ولن تكون سريعة.
الآن في KWin 5 ، يعد استخدام QML هو المشكلة الرئيسية التي تجعل استخدام Aurorae صعبًا. يستخدم QtQuick Scenegraph ويستخدم QWindows بدلاً من QWidget. هذه مشكلة بالنسبة لواجهة برمجة تطبيقات QWidget الخاصة بنا. لقد قمنا بتعديل الاستخدام الداخلي لدعم الزخارف المستندة إلى QWindows ، ولكن هذا كان طريقًا صعبًا للغاية حيث توجد اختلافات في سلوك النوافذ. نظرًا لأنه لم يعد يعتمد على QWidget ، فقد تم كسر ملائمة حدث الطلاء لدينا واحتجنا إلى حل جديد لها. وهذا الحل أقبح من الحل السابق لأن QtQuick يعمل حاليًا من خلال OpenGL. نظرًا للقيود الموجودة في تطبيق OpenGL Qt (يمكن تناولها في Qt 5.4) والتي لا يمكننا مشاركتها مع سياق OpenGL الذي تستخدمه QtQuick ... هذا ليس فقط عبئًا كبيرًا عند نسخ المحتوى من وحدة معالجة الرسومات إلى ذاكرة الوصول العشوائي والعودة مرة أخرى بالنسبة إلى وحدة معالجة الرسومات ، فأنت أيضًا تفقد الكثير من الذاكرة. في حالة وجود نافذة مكبرة ، فهي ليست فقط شريط العنوان ، ولكن النافذة بأكملها. ويوجد ذلك فوق كل نافذة.
هذا وحده يمكن أن يجعل الشفق القطبي غير قابل للاستخدام تمامًا. أستخدم حاليًا سمة Breeze ويحتاج KWin إلى أكثر من 200 ميجابايت من ذاكرة الوصول العشوائي - وهذا غير مقبول حقًا. لكن الوضع أسوأ. مع QWindows لا يمكننا معرفة المناطق التي تم تحديثها. لذلك ، عند تحديث زر على سبيل المثال ، يتعين علينا إعادة طلاء النافذة بأكملها ، بما في ذلك النسخة الكاملة من محتوى الزخرفة. هذه مشكلة كبيرة خاصة في مواقف الرسوم المتحركة.
فما هو الطريق إلى الأمام؟ لقد بدأت في تنفيذ زخرفة جديدة لواجهة برمجة التطبيقات عن طريق إزالة قيود الزخرفة القائمة على الرفاهية من QWidget وفي نفس الوقت بدأت في تنفيذ زخرفة Breeze باستخدام واجهة برمجة التطبيقات الجديدة هذه. نأمل أن نتمكن من تقديم هذا في KWin 5.1.
وهذه هي الطريقة التي تسير بها الأمور ، أيها السادة. أتمنى أن تفهم أكثر أو أقل ما هي المشكلة. سأقوم بسؤال مارتن عما إذا كان صنع موضوع Breeze الأصلي مثل Oxygen أكثر عملية وأسرع ، على الرغم من أنني لست قلقًا في الوقت الحالي ، Oxygen على الرغم من أنه ليس أفضل شيء في العالم ، إلا أنه يحتوي على الكثير من الخيارات ..
قرأت كل شيء ، لكنني لم أفهم شيئًا ، فأنا بطيء اليوم. على أي حال ، ما زلت لا أستطيع اختبار KDE 5 على OpenSUSE 13.1. إنه يحطمني بسبب بعض التبعيات "القديمة" التي أملكها.
ربما سأمنحك فرصة أخرى مع نظام تشغيل آخر في نظام افتراضي.
تحياتي وشكرا على المدخلات.
إنه ليس بالأمر السهل ، فهو يحاول أساسًا توضيح أن طريقة تنفيذ التطبيقات معقدة ، خاصة بالنسبة للمكونات الإضافية ، وأن الشفق في جوهره بطيء ، أكثر بكثير من الأكسجين.
لا أعرف ، بهذا المعنى ، في جزء من مصمم النافذة وكل ما يبدو لي أنه
إنه ليس بالأمر السهل ، فهو يحاول أساسًا توضيح أن طريقة تنفيذ التطبيقات معقدة ، خاصة بالنسبة للمكونات الإضافية ، وأن الشفق في جوهره بطيء ، أكثر بكثير من الأكسجين.
لا أعرف ، بهذا المعنى ، في جزء من مصمم النوافذ وكل ما يبدو لي أن كيدي هي خطوة وراء جنوم ، واحذر ، أنا من محبي كيدي في أحسن الأحوال ، فقط أنه ليس من الصعب علي الاعتراف بشيء عندما يكون ذلك صحيحًا.
دون معرفة أي شيء عن ذلك ، ما فهمته أساسًا هو أن الشفق (المحرك الذي يستخدمه Breeze) يسبب مشاكل الآن لأن Kwin5 لم يعد يستخدم qwidget كما في kwin4 ولا تتصرف النوافذ بنفس الطريقة. بدلاً من ذلك ، يستخدم QML و QTquick اللذان يعملان مباشرة مع opengl ، وبالتالي يبدو أن بعض القيود الموجودة في qt 5.3 تمنع المحرك القديم وموضوعاته من عدم الأداء الجيد في Kwin الجديد.
هل سيكون من المجدي إنشاء (أو تكييف) بريز مع أسلوب أو طريقة العمل التي يمتلكها الأكسجين؟
أي شخص لديه أي فكرة عما سيحدث لـ qtcurve؟
يعمل Qtcurve-qt5 بشكل مثالي لبعض الوقت. سيتبع الإصدار الجديد من كيدي كما هو الحال دائمًا.
لقد كان غريبًا بالنسبة لي أنه في Kaos ، الذي دائمًا ما يكون في طليعة الحاضر ، يختبر Kf5 لذا فهو معروف في بلازما Kaos linux بعد ذلك أو يأتي الأكسجين kde 5 افتراضيًا. واو ، لم تكن تعلم أنك منشئ Aurorae ...
أنا منشئ الشفق؟ O_o ؛
كنت أقوم بإنشاء بديل لـ breeze أيضًا في الشفق يسمى next fresh والذي سيكون لاحقًا نسيمًا منعشًا ولكن لا يمكنني تكييف SVGs مع السمة ، لذا فإن تطويرها غير نشط ، elav إذا أتيحت لك الفرصة ، أود أن تعرضها له مبتكر موضوع النسيم لمعرفة ما إذا كان بإمكانهم نقل فكرة زخرفة الشفق إلى زخارف كيدي الأصلية كبديل للزخرفة النسيمية
https://drive.google.com/file/d/0B6VUkpZzqL7hbk1QbWN6eVcycU0/edit?usp=sharing
أعتقد أن KDE 5 سيكون متاحًا على Fedora و Debian و Slackware و Arch عندما يكون لدي عائلة وأطفال ، ويكون عمري حوالي 30 عامًا.
باختصار ، لمواصلة الاستفادة من الشباب الصغير الذي تركته.