Ezen a héten történt a KDE táján...

Aaron J. Seigo bemutatja a Plasma legfrissebb munkálatait:
(hang szükséges a videók hangalámondásainak megértéséhez)

Plasma alkalmazások videó letöltése (1. és 2. rész) (32.1 MB, AVI)

Tehát a Plasma ezen a héten a szokásos bug és API javításokon kívül így változott:

libplasma:

• szkriptelt alkalmazások, de jelenleg csak JavaScript nyelven
• a beállítási- és csomagkeretrendszerek már együtt vannak
• új általános állapotváltozás-jelző widget az alkalmazásokhoz
• új szerkezeti kód (layout), ami működik!
• munka a három lépcsős nagyításon (teljes asztal, asztali csoportok és áttekintő)
• az alkalmazásháttér renderelési technika átdolgozása.

dataengines:
• az időjárás már támogatja a NOAA-t (Nemzeti Óceán- és Légkörügyi Hivatal) és az 5 napos előrejelzést, ahol elérhető
• englishbreakfastnetwork (ok, ez új nekem ;)
• bluetooth rendszer már kezd alakot ölteni
• solid alapú rendszerek képességeinek növelése

alkalmazások:
• hagyományos asztal (tehát a lemezen egy mappa és hardver eszközök tartalmát mutatja) a visszafele kompatibilitás miatt
• digitális óra
• Twitter
• 3D Föld
• MacOS dashboard widgetek (és remélhetőleg hamarosan Opera minialkalmazások is)

Jelenleg kiváltképpen az új szerkezeti kód miatt vagyok felfűtve, mivel ez nagyban megkönnyíti az alkalmazások írását és a szkriptelést.

Szeretnék néhány dolgot röviden elmondani, hogy miért csak JavaScriptünk van jelenleg. Valahol el kellett kezdenünk, és a QtScript nagyon jónak tűnt. Könnyű vele az objektumokhoz futásidőben kötéseket létrehozni és nagyon gyors. Ahogy Richard J. Moore mondja: „A tigris alkalmazás egy példa a szkriptelt alkalmazásokra. A szkript kód felelős az SVG képek betöltéséért, a képernyőre varázslásáért és még a beállítási ablak megjelenítéséért is. Mindent egybevéve, úgy néz ki, hogy ez a szkript rendszer már elég az egyszerű alkalmazásokhoz, de összetettebbek is hamarosan elkészülhetnek.”

Folyamatosan finomítjuk az API-t, amit a szkript feldolgozó használ. Ha a munka egyszer elkészül, újra elővesszük a többnyelvűségi problémát, ami túlmutat az egyszerű nyelvi választáson és az erőforrás felhasználás javítására fog koncentrálni, megkönnyítve ezzel a rendszerek és más összetett dolgok (pl. dokumentáció) kapcsolatát. Úgy gondolom, hogy itt még bejöhet a Python és a Ruby támogatás, de jelenleg boldog vagyok a JavaScripttel is, és először azt tesszük rendbe teljesen más nyelvek implementálása előtt.

Rivo Laks bemutatja az ő Summer of Code projektjét, ami nemrég került be a kdelibs kódjába, egy általános gyorsítótárat, ami javítja a pixmap használatát az egész KDE-ben:

Az ikon cache arra hivatott, hogy gyorsítsa az ikonok betöltődését úgy, hogy az összes használt ikont egy közös fájlba teszi. Ez máris megoldja azt a problémát, hogy meg kell találni az adott ikont rengeteg könyvtár között, és még az operációs rendszer is gyorsabb lehet, ha előre olvassa a gyorsítótárazott fájlt a memóriába. Amint minden ikon a cache-be került és az pedig a memóriába, az ikontöltéshez már egyáltalán nem szükséges lemezhasználat.

Bár eléggé szélsőséges eset a KFind, ami induláskor kb. 600 ikont tölt be (a legtöbb a MIME típusok megjelenítéséért felelős), 1 másodperc alatt indul el, ha a gyorsítótárból tölti be őket. Ha a cache le van tiltva, az indulási idő ~ 4 másodpercet vesz igénybe. Az átlagos alkalmazásoknál, amik csak néhány tíz vagy néha száz ikont töltenek be, a sebességnövekedés természetesen nem olyan látványos, de mégis segít.

A gyorsabb ikon betöltés nem csak az egyetlen előnye az ikon cache-nek. Mivel az egész Oxygen téma SVG formátumban van, közvetlenül ezeket a fájlokat használhatjuk a pixmapek futásidejű megjelenítésére. De mivel már a gyorsítótárban vannak, minden pixmapnek csak egyszer kell legenerálódniuk. Az SVG renderelés még mindig elég erőforrásigényes ahhoz, hogy minden egyes alkalomkor generálódjon, amikor szükség van rá, de mivel az eredmény már cache-elve van, jóval gyorsabb lesz. A felhasználók pedig már nem lesznek megadott ikonméretekhez kötve, hanem bármelyik méretet használhatják.

Valószínű a legérdekesebb rész az ikonösszetétel. Ez lehetővé teszi, hogy futásidőben hozzuk létre a szükséges ikonokat, néhány létező darabot felhasználva.

<rossz példa>
Például a legtöbb MIME ikonkép egy közös hátteret használ, majd erre jön rá az adott típus képe.
Az egyik probléma ezzel az, hogy amikor az egyik alkalmazásban feltűnik az ikon a saját fájlformátumához, nem biztos, hogy illik a másik témához. Az ikonösszetétellel elég csak a MIME specifikus részt megadnia, és az automatán a jelenlegi téma által kínált háttér fölé lesz helyezve.
</rossz példa>

<jobb példa>
Tehát különböző jelek rajzolhatóak másik ikonokra futásidőben. Jelenleg van egy könyvtárikon egy lakattal a hozzá nem férhető könyvtárakhoz, egy másik könyvtárikon egy kis képpel rajta a képeket tartalmazó mappákhoz stb. Az ikonösszetétellel viszont elég csak a könyvtár ikonját elkészíteni, majd a különböző többi ikon rákerülhet az előbbire, és utána gyorsítótárazódna.
</jobb példa>

Az ikonösszetétel valószínű a KDE 4.1-es verziójáig nem lesz benne a rendszerben, de az ikon cache többi része (ami eredetileg a 4.1-be ment volna) viszont már az SVN trunk mappájában van. A cache generáló rendszer, ami értesíti a gyorsítótárat, hogy új ikonokat telepítettek, néhány napon belül elkészül. Néhány belső dolog már most is kész van, például a cache fájlok memóriába való mmappelése.

Az ikon cache egy érdekes mellékterméke a pixmap cache. Már a kdelibsben van, és minden alkalmazás számára elérhető. A pixmapek lemez gyorsítótárazást kínálja. A fő célpontjai azok az alkalmazások, amik SVG-ket használnak, hogy a képeiket megjelenítsék (de nem az ikonjaikat), például sok játék és a kde-edu programok. KMines nemrég vált az első programmá, ami a pixmap cache előnyeit használja ki.

Ahelyett, hogy az alkalmazás minden egyes indításakor újra generálja az SVG-t, a már egyszer létrehozott pixmapet a lemezes gyorsítótárba tudja tenni, és azt használni következő indításkor, így csökkentve az indulási időt. További infók a pixmap cache-ről a nemrég frissített TechBase-ben.

Henrique Pinto beszél az Ark (KDE archiváló program) fejlesztéséről:

Az elmúlt néhány héten az Ark újrarendezésén dolgoztam. Az évek alatt a kódbázis elég rendetlen lett, és ez néhány olyan hibát okozott, amit nagyon nehezen lehet javítani, így egy nagyobb takarítás ráfért a programra. A fő célok ezek voltak:

• különböző archívum típusok hozzáadásának megkönnyítése
• a kódbázis könnyebben karbantarthatóvá alakítása
• felhasználói felület fejlesztése

A különböző archívumok kezelése már plugin alapokon zajlik. A legtöbb ilyennek csak egy egyszerű, aszinkron felületet kell biztosítani, az Ark fogja a kódot külön szálon futtatni. A plugin API megírása még nincs teljesen kész, mivel még mindig nem tiszta előttem néhány részlet.

A kód, ami a tömörített fájlokat, pluginokat és a hozzájuk kapcsolódó dolgokat kezelte már nem a KPart-ban található, hanem egy új könyvtárban, a libkerfuffle-ben. Nincs semmi különleges ok, hogy ezt a nevet adtam neki. Eléggé rossz vagyok az elnevezési dolgokban, így csak egy véletlen szót választottam a szótár „K” betűs részéből. Remélem, elég különleges a név ahhoz, hogy valaki egy jobbat javasoljon :). A könyvtárat jelenleg csak a KPart és a pluginok használják, de van egy olyan elképzelésem, hogy írok egy kis alkalmazást, aminek ez része lesz, hogy az kezelje az integrációt a fájlkezelőkkel.

A felhasználói felület is megváltozott, ahogyan a képernyőmentésen is látszik. Nem igazán tetszik nekem, de segítségre lesz szükségem, hogy jobbat készítsek, mivel teljesen kifogytam az ötletekből.

Jelenleg még nagyon sok munka van hátra. Most csak az ISO, TAR és ZIP fájlokhoz vannak pluginok, és attól félek, hogy már nem tudok többet írni az új képességek befagyasztása (feature freeze) előtt, leginkább azért, mert az API még nincs kész teljesen, és még néhány nagyon alapvető dolog, mint a bejegyzések eltávolítása nincs is implementálva. A fájlkezelő beépülés is elkészületlen marad. Bármilyen segítség nagyon jól jönne most.

Troy Unrau valószínű módosítja a kiadási ütemtervet: „Bár nem egy SVN commit, fontos megjegyezni, hogy a kiadási ütemterv egy hónappal hátrébb csúszott, hogy a szükséges API változtatásokat még be tudjuk építeni a KDE 4-be, az előzőleg tervezett július 25-i időpont előtt, ami most már augusztus 25.”

Ez azért szükséges, mivel a KDE 4.0 béta kiadása több mint a szaknyelv alpha – béta változása; egy béta kiadás már végleges API-t és új funkciók befagyasztását jelenti, míg egy újabb alpha nem.

További információk és rengeteg statisztika megtekinthető az e heti KDE Commit Digest weblapján.