A népszerű GNOME asztali környezet következő nagy kiadásán, a GNOME 43-on folyik a munka, és egyre közelebb kerülünk az első alfa fejlesztői kiadáshoz, amely számos új funkciót tartalmaz. Ilyen többek között a webes alkalmazások támogatása, egy új eszközbiztonsági információs panel a Beállításokban és a WebExtensions támogatása a Weben. Képgaléria a hír végén.

Mint minden új kiadás, a GNOME 43 is több új funkciót hoz a GTK által írt asztali környezet rajongóinak. A fejlesztőcsapat ezekben a napokban keményen dolgozik az alfa verzió nyilvános tesztelésre való kiadásán a GUADEC 2022 konferencia előtt, amely július 20-25. között kerül megrendezésre a mexikói Guadalajarában, az elmúlt két év első személyes GNOME rendezvényeként.

Még két és fél hónap van hátra a GNOME 43 végleges kiadásáig, de szerettem volna megosztani néhány izgalmas új funkciót, amelyet ősszel érkezhet, valamint néhány eddig megvalósított fejlesztést.

Először is, a GNOME Software 43 támogatást kap a webes alkalmazásokhoz (Web Apps), különös tekintettel a PWA-kra (Progressive Web Apps). Ezzel a GNOME fejlesztői azt szeretnék, hogy még több alkalmazást élvezhess natív szerűen a Linux disztribúción.

A webes alkalmazásokhoz támogatása mellett a GNOME Software 43 a Flatpak alkalmazások jobb támogatását is hozza, mivel a grafikus csomagkezelő és alkalmazásbolt mostantól képes megjeleníteni a Flatpak alkalmazások által kért fájlrendszeri engedélyeket.

A GNOME Software 43 továbbá új érintéses gesztusokat kínál a felületen való visszalépéshez. Érkezik még új "Egyéb alkalmazások szerző szerint" részt az alkalmazás adatlapján, valamint új "Terjesztéshez elérhető" rész az áttekintő oldalon. A letöltött metaadatok és értesítések jobb gyorsítótárazását, valamint az alkalmazások képernyőképén való egérnavigációt is kínál majd.

A GNOME Settings (más néven GNOME Control Center) 43 kap egy új Device Security (Eszközbiztonság) részt az Adatvédelmi beállítások között, amely megjeleníti a hardver biztonsági állapotát, amelyet a Fwupd projekt generál, valamint a hardver konfigurációs módosításait, például a HSI biztonsági szintjét és a Secure Boot állapotát. A felhasználók három előre konfigurált biztonsági szint közül választhatnak majd a hardverükhöz, mint például a minimális, az alap vagy a kiterjesztett védelem.

Chris Davis tervei a GNOME 43-mal kapcsolatban:

Vezérszínek és Libadwaita újraszínező API

A libadwaita érkezése lehetővé teszi számunkra, hogy néhány új dolgot tegyünk a GNOME platformmal, mivel van egy platformkönyvtárunk, amely segít a fejlesztőknek új platformfunkciókat implementálni és megfelelően megvalósítani. A libadwaita például lehetőséget adott arra, hogy megvalósítsunk egy globális sötét stíluspreferenciát gépekkel, amely lehetővé teszi a fejlesztők számára, hogy kiválasszák, hogy támogatják-e, és könnyen beállítsák az alkalmazásuk stílusát, ha engedélyezve van. Alexander Mikhaylenko hosszú időt töltött az Adwaita átdolgozásával, hogy működjön az átfestéssel, és ezt szeretném teljes mértékben kihasználni a következő két funkcióval: a globális akcentusszínekkel és az átfestő API-val.

A Libadwaita egyszerűvé teszi egy nagyon kívánt személyre szabási funkció megvalósítását: a testreszabható ékezetszíneket. A globális akcentusszínek az alkalmazásfejlesztők számára választhatóak lesznek. A backend számára azt szeretném, ha az akcentusszínek asztali és platform-agnosztikusak lennének, mint az új sötét stíluspreferencia. Tervezem, hogy a közeljövőben javaslatot nyújtok be erre vonatkozóan az xdg-desktop-portalhoz. A GNOME-ban valószínűleg az lenne a legjobb, ha csak néhány QA-tesztelt ékezet jelenne meg a felhasználói felületen, de a libadwaita támogatná a tetszőleges színeket, így a KDE, GNOME, elementáris OS és egyéb alkalmazások mind ugyanazokat a színeket használnák, ha támogatják a preferenciát.

Az átszínező API-t használó fejlesztők programozottan megváltoztathatják a színeket az alkalmazásaikban, és a függő színek automatikusan frissülnek. Könnyen létrehozhatnak majd olyan előbeállításokat, amelyekkel például egy szöveges nézet színsémája alapján át lehet színezni az ablakot. Technikailag ez a libadwaita 1.0-ban már lehetséges CSS-szel, de az API egyszerűbbé teszi ezt. Ahelyett, hogy minden egyes színt figyelembe kellene venniük, csak néhányat kell majd beállítaniuk, a többit pedig a libadwaita megfelelően kezeli. Az itt használt heurisztika arra is használható lesz, hogy az akcentusszínek megfelelő kontrasztot kapjanak az alkalmazás hátterével szemben.

Adaptív Nautilus és továbbfejlesztett fájlválasztó

A GTK fájlválasztónak van néhány problémája. Például nem támogatja az olyan GNOME funkciókat, mint a csillaggal jelölt fájlok, és a terjesztés készítőknek (például: PureOS, Mobian) javítaniuk kell, hogy mobil formátumok esetén is működjön. Annak érdekében, hogy lépést tartson a platformkonvenciókkal, ideális esetben a fájlválasztónak a GNOME magjának részévé kellene válnia, nem pedig a GTK részévé. A megoldásokról még lehet vitatkozni, de úgy gondolom, hogy okos dolog lenne a fájlválasztót és a fájlböngészőnket szinkronban tartani azáltal, hogy a fájlválasztót a fájlböngésző részévé tesszük.

Mindezt szem előtt tartva tervezem, hogy a Nautilust adaptívvá teszem a mobil formátumokhoz, és hozzáadok egy új fájlválasztó módot. A GTK helyett a Nautilusban élő fájlválasztó lehetővé teszi számunkra, hogy a GNOME platform funkcióit a GNOME tempójában támogassuk a GTK tempója helyett, kövessük a GNOME tervezési mintáit, és olyan funkciókat valósítsunk meg, mint a rácsos nézet miniatűrökkel anélkül, hogy a nulláról kezdenénk

Loupe (képnézegető)

Egy ideje már dolgozom a Loupe-on, egy új képnézegető programon, amely Rust nyelven íródott a GTK4 és a libadwaita segítségével. Azt tervezem, hogy a Loupe adaptív, touchpad és érintőképernyő barát és könnyen használható legyen. Azt is szeretném, hogy integrálódjon a Nautilusba, hogy a Loupe kövesse a mappák rendezési beállításait a Nautilusban.

Baobab újraírása Rust-ban, és új design megvalósítása

A Baobab (más néven Disk Usage Analyzer) Vala nyelven íródott. A Vala nem fér hozzá a könyvtárak nagy ökoszisztémájához, és az eszközrendszer is hagyott némi kívánnivalót maga után. A Rust viszont virágzó könyvtári ökoszisztémával és csodálatos eszközrendszerrel rendelkezik. A Rustnak nagyszerű GTK kötései is vannak, amelyek folyamatosan fejlődnek. Azzal, hogy a Baobabot Rustra írom át, teljes mértékben ki tudom majd használni az ökoszisztémát, miközben javítom a fő funkciójának teljesítményét: a lemezhasználat elemzését. Már elkezdtem a munkát ebbe az irányba, bár a GitLabon még nem érhető el.

Az újraírás mellett tervezem egy újratervezés megvalósítását is, Allan Day mockupjai alapján. Az új dizájn modernizálja a felhasználói felületet, új mintákat használ, és kijavít néhány komolyabb UI-gondot, amit az emberek a jelenlegi dizájnnal kapcsolatban kifogásolnak.

Szomszédos fájlok megnyitása a FileChooser portálról

Az xdg-desktop-portal fájlválasztó nem teszi lehetővé a szomszédos fájlok megnyitását, amikor kiválaszt egy fájlt. Az olyan alkalmazásoknak, mint a képböngészők, webböngészők és programfutók, mindnek szüksége van egy homokozólyukra, ha súrlódásmentesen akarnak működni. Ha webböngészőt használ flatpaként, akkor belefuthatott ebbe a problémába: egy html fájl megnyitása nem tölti be a kapcsolódó HTML fájlokat vagy médiafájlokat. Ha helyben dolgozol egy weboldalon, akkor azt egy webszerverrel kell kiszolgálnod, hogy előnézetet tudj készíteni róla - például python -m http.serverrel.

Egy olyan portálon szeretnék dolgozni, amely lehetővé teszi a fejlesztők számára, hogy egy fájl megnyitásakor hozzáférést kérjenek a szomszédos fájlokhoz. Ezzel a portállal a Loupe-ot flatpak-ként tudnám szállítani anélkül, hogy sandbox lyukakra lenne szükség, és az olyan alkalmazások, mint a Lutris vagy a Bottles is életképesebbek lennének flatpak-ként.

Használhatósági javítások

A GTK4 minden eddiginél egyszerűbbé teszi a hozzáférhetőséget. Az alapvető alkalmazások akadálymentesítését illetően azonban még mindig vannak javítanivalók. Szeretném átnézni az alapvető alkalmazáskészletünket, tesztelni őket a rendelkezésre álló akadálymentesítési eszközökkel, valamint dokumentálni és javítani a felmerülő problémákat.

Munkám szponzorálása

Remélem, hogy idén mindezeken (és még sok máson, amit még nem osztottam meg) tudok dolgozni. Jelenleg azonban munkát keresek. Jelenleg teljes munkaidőben kellene munkát keresnem, vagy teljes munkaidőben valami mással foglalkoznom, ahelyett, hogy ezeken a kezdeményezéseken dolgoznék - nincs meg a szellemi sávszélességem mindkettőre. Ha azt akarjátok, hogy ez a munka elkészüljön, nagyon jól jönne a támogatásotok. Három helyen tudsz támogatni:

• Patreon
• GitHub Sponsors
• Paypal.me (egyszeri támogatások)

Végül úgy tűnik, hogy a GNOME 43 elhozza a WebExtensions kezdeti támogatását a GNOME Web (Epiphany) webböngészőhöz, ami végre lehetővé teszi, hogy a GNOME alapértelmezett webböngészőjének képességeit más népszerű webböngészők, például a Mozilla Firefox vagy a Google Chrome harmadik féltől származó bővítményekkel bővítse. További részletek itt találhatók.

Természetesen még több klassz új funkciót élvezhetsz majd idén ősszel a GNOME 43 asztali környezetben, úgyhogy tartsd szemmel ezt a helyet, mert amint újabb információk látnak napvilágot, a 2022. szeptember 21-i végleges kiadásig folyamatosan tájékoztatlak.

• Nightly ISO lemezkép

Tervezett megjelenések

A GNOME 43 első alfa kiadása egy hetet csúszik és csak július 9-én jelenik majd meg. A GNOME 43 jelenleg több okból is rossz állapotban van:

• Megérkezett freedesktop-sdk 22.08 frissítés a libpthread eltávolítása miatt tönkretette a glibc-t. A freedesktop-sdk javított verziója már elérhető, de addig is sok alkalmazás CI-pipeline-ja hibásan működik.
• A geocode-glib megemelte az API verzióját, amikor a libsoup 3 engedélyezve volt. Olyan alkalmazások, amelyek korábban futás közben összeomlottak volna - beleértve a Maps és Photos alkalmazásokat - most nem lehet felépíteni. A legtöbb dolog, ami a geoclue-glib-től függ, elromlott. A Vala kötések frissítése is szükségesek, de még nem elérhetőek.

Nem tudunk kiadni egy olyan binárist, amely az első problémát orvosolja, mert a második probléma miatt nem tudjuk elkészíteni a binárist. Visszatarthatnánk a geocode-glib-et, de nem igazán akarjuk, mert a libsoup 3 számára egy külön API verzió nagyon hasznos: a build hibák jobbak, mint a futásidejű összeomlások, végül is. Szóval egy plusz hetet szánunk arra, hogy megpróbáljuk ezt rendezni.

• GNOME 43 Alpha - 2022. július 9.,
• GNOME 43 Béta - 2022. augusztus 6.,
• GNOME 43 RC - 2022. szeptember 3.,
• GNOME 43 végleges - 2022. szeptember 21.

(forrás)