Sean Anastasi (), az ingyenes szoftverek rajongója, aki egy időben saját operációs rendszert fejlesztett ki és részt vett a Chromium és a Qubes OS ppc64le architektúrára történő portolásában, terv , amelyen belül az Xfce felhasználói környezet komponenseinek kliensoldali ablakdekoráció (CSD, kliensoldali dekoráció) nélkül működő forkjait kívánja fejleszteni, amelyekben az ablak címét és kereteit nem az ablakkezelő rajzolja meg, hanem maga az alkalmazás.
Emlékeztetünk arra, hogy az Xfce 4.16 következő kiadására készülve, amelynek megjelenése októberben vagy novemberben a felület átkerült a GtkHeaderBar widgetre és a CSD használatára, ami a GNOME-hoz hasonlóan lehetővé tette menük, gombok és egyéb felületelemek elhelyezését az ablak fejlécében, valamint az elrejtést. keretek közül a párbeszédablakban. Az új interfész-megjelenítő motor be van építve a libxfce4ui könyvtárba, aminek eredményeként szinte minden párbeszédpanelen automatikus CSD-alkalmazást kellett végrehajtani, anélkül, hogy a meglévő projektek kódját módosítani kellett volna.
A CSD-re való átálláskor , akik úgy vélik, hogy a CSD támogatásának opcionálisnak kell lennie, és a felhasználónak továbbra is képesnek kell lennie a klasszikus ablakcímek használatára. A CSD használatának hátrányai közé tartozik a túl masszív ablakcímterület, az alkalmazáselemek áthelyezésének hiánya az ablak címébe, az Xfwm4 témák működésképtelensége, valamint az Xfce/GNOME alkalmazások és programok ablakainak tervezési eltérése. nem használ CSD-t. Megjegyzendő, hogy az egyik oka annak, hogy egyes felhasználók elutasítják a GNOME felületet, a CSD használata.
Mivel 5 hónap alatt nem történt kísérlet a CSD letiltásához, Sean Anastasi kezembe vettem ezt a kérdést, és létrehoztam a könyvtár villáját , amelyben megtisztítottam a CSD-hez való kötést és visszaadtam a régi dekorációs módot a szerver oldalon (ablakkezelő). Az új libxfce4ui API-t használó alkalmazásokkal való kompatibilitás biztosítása és az ABI megőrzése érdekében speciális összerendeléseket készítettek, amelyek az XfceTitledDialog osztály specifikus CSD-metódusait a GtkDialog osztály hívásaivá fordítják. Ennek eredményeként a libxfce4ui könyvtár cseréjével az Xfce-alkalmazások CSD-től megszabadíthatók anélkül, hogy maguknak az alkalmazásoknak a kódját megváltoztatnák.
Ezenkívül egy villát alakítottak ki , amely magában foglalja a klasszikus viselkedés visszaállításához szükséges változtatásokat. Gentoo felhasználók számára készült a libxfce4ui-nocsd telepítéséhez. Xubuntu/Ubuntu felhasználók számára készült kész csomagokkal. Sean Anastasi azzal magyarázta a fork létrehozásának okait, hogy sok éve használja az Xfce-t, és szereti ennek a környezetnek a felületét. Miután döntött az interfész megváltoztatásáról, amellyel nem értett egyet, és nem próbált lehetőséget adni a régi viselkedéshez való visszatérésre, úgy döntött, hogy maga oldja meg a problémát, és megosztja a megoldást más hasonló gondolkodású emberekkel.
Az Xfce Classic használata során az egyik probléma az ismétlődő címek megjelenése, mivel a címben és az alkalmazás ablakában ismétlődő információk jelennek meg. Ez a funkció összhangban van az Xfce 4.12 és 4.14 viselkedésével, és nem kapcsolódik a CSD-hez. Egyes alkalmazásokban az ilyen duplikáció normálisnak tűnik (például az xfce4-screenshooterben), de másokban nyilvánvalóan nem megfelelő. A probléma megoldására lehetőség van egy környezeti változó hozzáadására, amely vezérli az XfceHeading megjelenítését.
A CSD-támogatók pozíciója az ablakcímek elpazarolt helyének használatában rejlik a menük, panelgombok és egyéb jelentős interfészelemek elhelyezésére. A CSD ellenzői úgy vélik, hogy ez a megközelítés problémákat vet fel az ablakok kialakításának egységesítése során, különösen a különböző felhasználói környezetekhez írt ablakok esetében, amelyek eltérő ajánlásokat fogalmaznak meg a címterület elrendezésére vonatkozóan. Sokkal egyszerűbb az összes alkalmazás ablakának tervezését egyetlen stílusba hozni, ha egy ablak szolgáltatási területeit klasszikusan rendereli a szerver oldalon. A CSD használata esetén minden egyes grafikus környezethez külön-külön kell hozzáigazítani az alkalmazás felületét, és meglehetősen nehéz biztosítani, hogy az alkalmazás ne tűnjön idegennek a különböző felhasználói környezetekben.
Forrás: opennet.ru