בריזה: מדוע זה לא מגיע כברירת מחדל ב- KDE 5?

כפי שכבר ידוע, KDE Next (או KDE 5 כפי שאתה מעדיף) שוחרר כיציב לפני כמה ימים ובין התכונות החדשות שהוא מביא, אחד המדוברים ביותר הוא יצירות האמנות החדשה בשם Breeze.

מי שכבר ניסה את הגרסה החדשה הזו או ראה את הסרטון, אולי הבחין שבמקרה של מעצב החלונות, זה שמגיע כברירת מחדל הוא חמצן ולא בריזה. גם כן מרטין גרסלין מסביר לנו בבלוג שלו מה הסיבה להחלטה זו.

מכיוון שהמאמר באנגלית, אנסה להביא לכם את הרעיון הבסיסי לכך.

מדוע בריזה לא מגיעה כברירת מחדל?

אני מתחיל בהסבר כיצד קישוטי חלונות עובדים ב- KWin 4. KWin הוא מה שמכונה הורות מחודשת של מנהלי חלונות. המשמעות היא שהחלון המנוהל על ידי X11 מוכנס לחלון X11 אחר המספק את מסגרת החלון. ב- KWin אנו משתמשים ב- QWidget למסגרת החלון. לכן אנו מוגבלים גם למה ש- QWidget מספק לנו ... הפיתרון שלנו הוא ליירט את כל אירועי ציור הקישוט ב- QWidget ולהדחיקו, להפעיל צביעה מחודשת של המלחין ובשלב העיבוד להבטיח קישוט של תמונה זמנית שמועתקת אז. למרקם.

עיטור חלונות הנושא של בריזה מבוסס על מנוע הנושא של אורורה. מכיוון שאני המחבר הראשי של אורוראה אני יכול להכות את זה בפוסט בבלוג מבלי להרגיש רע עם זה. אורוראה תוכננה להיות קלה מאוד ליצירת קישוט ולהשתמש בתכונות השקיפות החדשות. להיות פיתרון שיכול לשמש קישוט ברירת מחדל, אבל זה אף פעם לא היה המטרה שלהם. הרעיון היה לאפשר למשתמשים שרוצים התאמה אישית של תכונה זו, בעוד שרוב המשתמשים יכולים להשתמש בערכות נושא מהירות יותר. אורורה מעולם לא הייתה מהירה והיא לא תהיה מהירה.

כעת ב- KWin 5, השימוש ב- QML הוא הבעיה העיקרית המקשה על השימוש ב- Aurorae. QtQuick משתמש ב- Scenegraph ומשתמש ב- QWindows במקום ב- QWidget. זה משקל עבור ה- API מבוסס ה- QWidget שלנו. שינינו את השימוש הפנימי לתמיכה בעיטורים מבוססי QWindows, אך זו הייתה דרך קשה למדי מכיוון שיש הבדלים בהתנהגות החלונות. מכיוון שהוא כבר לא מבוסס על QWidget, מלכודת אירועי הצבע שלנו שבורה והיינו זקוקים לפיתרון חדש בשבילו. והפתרון הזה מכוער עוד יותר מהקודם מכיוון ש- QtQuick עובד כרגע באמצעות OpenGL. בשל מגבלות ביישום OpenGL Qt (ניתן לטפל בו ב- Qt 5.4) שאיננו יכולים לשתף עם ההקשר של OpenGL המשמש את QtQuick ... זו לא רק תקורה ענקית בעת העתקת התוכן מה- GPU ל- RAM ובחזרה אל את ה- GPU, אתה גם מבזבז הרבה זיכרון. במקרה של חלון מרבי זה לא רק שורת הכותרת, אלא כל החלון. ויש תקורה זו לכל חלון.

זה לבדו יכול להפוך את Aurorae לבלתי שמיש לחלוטין. כרגע אני משתמש בנושא Breeze ו- KWin זקוק ליותר מ- 200 מגה-בייט של זיכרון RAM - לא ממש מקובל. אך המצב גרוע עוד יותר. עם QWindows איננו יכולים לדעת אילו אזורים עודכנו. אז כאשר, למשל, כפתור מתעדכן עלינו לצבוע מחדש את כל החלון, כולל העותק המלא של תוכן הקישוט. במיוחד במצבי אנימציה זו בעיה גדולה.

אז מה הדרך קדימה? התחלתי ליישם קישוט חדש עבור ה- API על ידי הסרת ההגבלה של העיטור המבוסס על בריאות מ- QWidget ובמקביל התחלתי ליישם את קישוט ה- Breeze באמצעות ה- API החדש הזה. מקווה שנוכל להציג זאת ב- KWin 5.1.

וכך הדברים, רבותיי. אני מקווה שאתה מבין פחות או יותר מה הבעיה. אני אשאל את מרטין אם זה לא יותר פרקטי ומהיר יותר להפוך את נושא הבריזה המקורי כמו חמצן, אם כי כרגע אני לא מודאג, חמצן למרות שזה לא הדבר הכי חמוד בעולם, יש לו הרבה אפשרויות ..