‘Projektek’ kategória archívum

Megjelent a 0 A.D. Alfa 20 Timoszthenész

László Gyaraki, 2016. április 2. szombat

A Wildfire Games, az önkéntes játékfejlesztők nemzetközi csoportja, örömmel jelenti be a „0 A.D. Alfa 20 Timoszthenész” kiadását, amely a 0 A.D. huszadik alfa verziója. A 0 A.D. egy ingyenes, nyílt forrású, ősi hadviselési játék. Ez az alfa 10 új térképet, a filmes játékbeli kamera alapvető funkcionalitásait, a lerakóhelyeknek szövetségesek számára történő megosztásának képességét, és további újdonságokat szolgáltat! Azonban magyar vonatkozásban a legfontosabb újdonság, hogy az FSF.hu Alapítvány aktivistáinak köszönhetően ezzel a kiadással teljesen magyar nyelven lehet játszani.

Teljesen magyar nyelvű felület

A 0 A.D. ezen kiadása teljes egészében magyar nyelvű felülettel érkezik. Mindössze 14 olyan nyelv van, amelyre a játék 100%-ban le van fordítva, beleértve a magyart is. A fordítási és lektorálási munka az FSF.hu Alapítvány aktivistáinak kemény munkájával készült el. Külön köszönet Gyuris Gellértnek a pályák és térképek, a módosítás-választó, valamint az oktatójáték fordításáért, Meskó Balázsnak a hatalmas mennyiségű fordításért, kiemelve az idézeteket és a történelmi leírásokat, valamint Úr Balázsnak a fordítás koordinálásáért, a fordítóhétvége megszervezéséért, a hiányzó fordítások befejezéséért szinte minden modulban, (különösen a technológiák és térképek leírásának fordításáért), illetve a lektorálásért.

golden_island.jpgAz Alfa 20 új csatározási térképe: „Golden Island”

A fordítók mindent megtettek azért, hogy a magyar nyelvi csomag a lehető legjobb legyen, de ennek ellenére maradhattak benne hibák. Ha a játékosok bármilyen fordítási hibát találnának a játékban, akkor az a hibajelentes(kukac)openscope(pont)org címen küldhetik a fordítóknak.

Egyszerű letöltés és telepítés

A letöltési és telepítési utasítások Windows, Linux és Mac OS X rendszerekhez is elérhetők (angol nyelven). A 0 A.D. ingyenes, és mindig is ingyenes marad. Bár lehet, hogy talál néhány embert, aki a 0 A.D. példányait az interneten vagy fizikai adathordozón árulja, azonban mindig lehetősége van letölteni a 0 A.D. játékot teljesen ingyen, közvetlenül a fejlesztőktől.

How to Download 0 A.D.Telepítési utasítások WindowshozTelepítési utasítások LinuxhozTelepítési utasítások OS X-hez

Ráadásul tovább terjesztheti a játékot, és szabadon módosíthatja mindaddig, amíg betartja a GPL licenc feltételeit. Akár a grafikák és a hangok egy részét is felhasználhatja a saját projektjeihez mindaddig, amíg betartja a Creative Commons Nevezd meg!-Így add tovább! feltételeit. Nincs „freemium” modell, nincsenek játékbeli hirdetések, nincs átverés.

Új játékmenet funkciók ebben a kiadásban

  • Új véletlenszerű térképek: „Ambush”, „Empire”, „Flood”, „Frontier”, „Hell’s Pass”, „Island Stronghold”, „Lions Den” és „Stronghold”.
  • Új csatározási térképek: egy négyszemélyes „Forest Battle” nevű és egy kétszemélyes „Golden Island” nevű csatározási térkép lett hozzáadva.
  • Szövetséges lerakóhelyek használata: egy technológia kifejlesztése után használhatók a szövetségesek raktárai, tanyái, kikötői, városházái (de a maurják elefántjai nem) azoknak a nyersanyagoknak a lerakásához, amelyeket az egységek begyűjtöttek. A szövetségesnek engedélyeznie kell ezt minden egyes lerakóhelynél, így nem használható az összes nyersanyag „ellopásához” a területen.
  • Lőrések: egy technológia kifejlesztésével a tornyoknak lehetőségük van a közvetlen közelükben lévő egységeket támadni.
  • Új technológiák a halászathoz: a technológiák kifejlesztésével növelhető a hajók begyűjtési hatékonysága.
  • Zsákmány nyersanyagok, amelyet a megölt ellenségek vittek: mostantól automatikusan megszerezhetők azok a nyersanyagok, amelyeket a sereg által megölt egységek szállítottak, vagy másképpen fogalmazva: öld meg a favágókat a fa begyűjtéséhez, a földműveseket az élelem megszerzéséhez, stb. Ez a normál zsákmányon felül van, amely az egységek megölésekor szerezhető.

Ambush térkép
Az Alfa 20-hoz hozzáadott „Ambush” véletlenszerű térkép

Grafika és felhasználói felület

  • Továbbfejlesztett játékbeállítások menü: új grafikai minőség beállítások, amelyek lehetővé teszik, hogy egyszerűen megváltoztatható legyen a grafikai minőség a játékon belülről (korábban beállítófájlokat kellett erre használni), valamint pár apró kódtisztítás és hibajavítás.

graphics_options_huGrafikai lehetőségek

  • Az erősebb számítógépeknél a jobb minőségű grafikai hatások alapértelmezetten engedélyezve vannak. Ha a számítógépnek képesnek kellene lennie a jobb minőségű grafikai hatások kezelésére, akkor azok mostantól alapértelmezetten engedélyezve lesznek. Természetesen megváltoztatható kézzel egy alacsonyabb beállításra, ha a teljesítmény növelése szükséges, vagy valamilyen okból nem szeretnénk használni azokat.
  • A tétlen munkások gomb mostantól le van tiltva, ha nincsenek tétlen munkások, így nem szükséges állandóan nyomkodni annak ellenőrzéséhez, hogy vannak-e a tétlen munkások.
  • Köszönet képernyő: itt nézhető meg, hogy kik működtek közre a játék fejlesztésében. A vezetőktől a programozókig, a művészektől az adakozókig, a fordítóktól a zeneszerzőkig mindenkit tartalmaz. Megpróbáltak mindenkit felvenni a listára, azonban sokan járultak hozzá az évek során, így ha Te is közreműködtél, de nem látod a neved a listában, akkor jelezheted.
  • Új fák és variációk: új modellek és textúrák lettek hozzáadva az akácia fa, aleppó-fenyő, tölgy, kiszáradt tölgy és az általános kiszáradt fák esetén.
  • Rengeteg továbbfejlesztés a megfigyelő módnál és a visszajátszásoknál: többek között mostantól nézhető a játszma egy adott játékos szemszögéből, megtekinthető az összegző képernyő a játszma alatt, és most már látható a harci köd a megfigyelő módban. A játszmák mostantól legfeljebb 16 megfigyelőt is támogatnak.
  • Több információ a játékosokról többjátékos játszmánál: látható, hogy ki szakadozik, vagy kinek van hálózati időtúllépése.
  • Új szeleukida laktanya:

Szeleukida laktanya

A motorháztető alatt

  • Filmes kamera a vágójelenetek megjelenítéséhez: befejeződött az alapozó munka, amely lehetővé teszi a kamera vezérlését a jeleneteknél. Azonban még további munkára van szükség ahhoz, hogy ez egyszerűen használható legyen (jelenleg a kamera útvonalát koordináták megadásával lehet beállítani), de ez szilárd alapot nyújt a későbbi fejlesztésekhez.

Ezen kívül számos apró változtatás történt. Az összes érdekes fejlesztés listájának megtekintéséhez érdemes elolvasni a változásnaplót (angol nyelvű).

Támogatás kérése

Érdemes lehet megnézni az angol nyelvű „Get Support” oldalt, hogy megtalálja a módját az aktív és barátságos 0 A.D. közösségtől történő segítségkéréshez. A Wildfire Games hangsúlyozza, hogy van még mit fejleszteni a 0 A.D. játékon. Néhány ismert hiba a következő: belassulás, látható grafikai problémák, be nem töltődő textúrák, hiányzó animációk és ehhez hasonlók. Amikor visszajelzést küld, olyan további dolgokra összpontosítson, amelyek javíthatók.

Legyen hozzájáruló!

A fejlesztők folyamatosan keresnek önkéntes hozzájárulókat a programozáshoz, grafikához, hangokhoz, dokumentációkészítéshez, stb. A programozóknak különösen örülnek, és azonnal kezdhetnek is. Felkeltette az érdeklődését? Jelentkezzen be az IRC-n a #0ad-dev csatornára a QuakeNet hálózaton, és találkozzon a fejlesztőkkel. Regisztráljon a fórumon, és legyen aktív részese annak!

Miért „Timoszthenész”?

A kiadásokat a fejlesztési állapotuk szerint nevezik el („Alfa” vagy „Béta”), ezután az egymást követő kiadási szám következik (1, 2, 3, …), majd egy olyan szó, amely kapcsolódik az ókori világhoz, ábécé sorrendben („Argonaut” az A-nál, „Bellerophón” a B-nél, …). „Timoszthenész” úgy kapcsolódik a 0 A.D. játékhoz, hogy ez egy ókori görög térképész neve, és ez a kiadás rengeteg új térképet tartalmaz. A következő alfához örömmel várják a rajongók javaslatait az olyan szavakra, amelyek kapcsolódnak az ókori világhoz, és U betűvel kezdődnek. Maradjon eredeti, és illeszkedjen a 0 A.D. által bemutatott időkeretbe (körül-belül időszámításunk előtt 500 – 1 között)!

Elérhetők a 10. Open Source Budapest Meetup videói

Kelemen Gábor, 2016. február 10. szerda

A tegnapi meetupon készült videók:

Lakó István: A kereszténység és a szabad szoftverek közös értékei

Nagy Tamás: Közreműködés nyílt forrású szoftverek GitHub munkamenetében – fejlesszünk syslog-ng-t!

Micko Gabriel: WebRTC – videokonferencia lehetőségei 2016-ban és a jövőben

Köszönöm az előadóknak és a résztvevőknek is, találkozunk két hónap múlva!

Meetupot szervezünk – helyszínt keresünk

Kelemen Gábor, 2014. február 27. csütörtök

Az FSF.hu alapítvány és a magyar Mozilla közösség nagy fába vágta fejszéjét: Meetupot szervezünk szabad szoftver és kultúra témában. Hamarosan meghirdetjük az első előadóinkat, azonban egy jelentős akadályt még le kell küzdenünk: alkalmas helyszínt kellene találnunk. Az alkalmas helyszín definíciója:
– Jól megközelíthető, belváros(közel)i elhelyezkedés
– Le lehet ültetni 30 (vagy több) résztvevőt
– Akiknek tudunk előadásokat vetíteni kb egy órán át, a projektoruk és faluk használatával
– Március 11-én este 6-tól beengednek minket (7-től a résztvevőket) és maradhatunk kb. 9-ig.
– Mindezért nem kérnek fizetséget.

Tudsz ilyen helyről, netán ott is dolgozol? Írj a kelemeng@ubuntu.com címre szombatig! Előre is köszönjük a segítséget!

Május – Base tábla import

Zolnai Tamás, 2013. június 5. szerda

    Májusban a LibreOffice adatbázis-kezelőjének egy új funkciójának a fejlesztésébe kezdtem. Ez a funkció a strukturált szöveges (*.csv kiterjesztés) állományokból és az LO táblázatkezelője által támogatott más formátumokból való közvetlen táblaimportálás. Egy közvetlen importálási lehetőség szintén az érettségizők dolgát könnyítené meg – ahogy a csúcsérték/limit megadására használt beviteli mező is – mely az elsődleges szempont, de ez a funkció általában is sok felhasználót érint. Mi sem mutatja ezt jobban, mint az Apache OpenOffice Bugzilla-ján található megfelelő bug jelentés, amely a szavazatok számát tekintve az első 19 között szerepel. (Limitált számú szavazat áll rendelkezésére minden Bugzilla felhasználónak, és ezekkel a szavazatokkal lehet szavazni azokra a bugokra/funkciókra, melyek kiemelten fontosak az adott felhasználó számára.)

Bug jelentés az Apache OpenOffice Bugzilla-ján:
https://issues.apache.org/ooo/show_bug.cgi?id=51904
Megfelelő LibreOffice bug jelentés:
https://bugs.freedesktop.org/show_bug.cgi?id=51872

   Valójában a táblaimportálás nem egy teljesen új funkció. Két különböző módja is van a probléma megoldásának. Egyrészről a táblázatkezelőt megnyitva és abba importálva bármilyen általa támogatott fájlt (ide tartozik a *.csv kiterjesztés is) és onnan kijelölve a táblázat felhasználni kívánt részét, másolás+beillesztéssel létrehozható egy új tábla az éppen megnyitott adatbázisban.

   Másik hasonló megoldási út az adatbázis-kezelő „Kapcsolódás létező adatbázishoz” opciójának használata az „Adatbázistündér” ablakban. Ezzel a opcióval rá lehet kapcsolódni tényleges adatbázisokra, de akár a táblázatkezelő által használt fájlokra és szöveges állományok egy csoportjára is, úgy értelmezve őket, mint egy adatbázis. A kapcsolódás után kapunk egy új adatbázisfájlt, mely táblaként tartalmazza az összes munkalapot az adott Calc fájlból, illetve az összes *.csv/*.txt fájl tartalmát az adott mappából. Ez a kapcsolat azonban „csak olvasható” hozzáférést biztosít a fájlokhoz, módosítási lehetőséget nem. Éppen ezért ebből az adatbázisból szintén másolás+beillesztéssel át kell másolni a táblákat abba az adatbázisba, amelybe ténylegesen importálni szeretnénk.

   Mindkettő megoldásnak megvannak az előnyei és a hátrányai a másikhoz képest, de ami közös bennük, hogy mindkettő esetben meg kell nyitni egy másik ablakot (1 → Calc, 2 → Base) és másolás+beillesztéssel átmásolni az adott táblát. Ehelyett az új, ténylegesen az importálást célzó funkció közvetlenül elérhető lesz abban az adatbázisablakban, amelyikbe importálni szeretnénk és a vágólap műveleteket sem szükséges alkalmazni.

   Mivel a „Kapcsolódás létező adatbázishoz” funkció már létezik, és minden támogatott adatbázis (ide tartoznak a táblakezelő által támogatott formátumok is) tábláihoz hozzáférést nyújt, ezért a tervezett import varázslóban is ugyanazon felületen lehet majd kapcsolódni egy adott adatbázishoz. A különbség annyi, hogy a kapcsolódás után ki lehet választani az importálni kívánt táblákat és a táblák beszúrása az aktuális adatbázisba a „Tábla másolása” nevű párbeszédablak felhasználásával történik majd.

   Ahogy említettem a hónapban a funkció megvalósításába csak belekezdtem. Valójában egy részletes terv elkészítéséig jutottam, mely megvalósítva úgy fog kinézni, ahogy fent leírtam. Három jól elkülöníthető része van ennek a tervnek, illetve magának a megvalósításnak.

   Az első rész az „Adatbázistündér” adatbázis-kapcsolódáshoz tartozó részének kiemelése a jelenlegi osztályából egy újba, ezzel lehetővé téve annak felhasználását a tervezett „Importtündér” megvalósításában. A két varázsló csak két oldalban fog különbözni. Egyrészről az első oldalon az „Importtündér” esetén csak egy lista lesz azon adatbázis típusának kiválasztásához, amelyből importálni szeretnénk, míg az „Adatbázistündérnél” ugyanezen a kezdőoldalon három funkció érhető el, köztük a „Kapcsolódás létező adatbázishoz” egy ugyanolyan listával. Másrészről az utolsó oldalon, ami az „Adatbázistündérnél” a „Mentés és végrehajtás” nevet kapta, ott az „Importtündérnél” az importálni kívánt táblák kiválasztására alkalmas felület lesz elérhető. Az itt leírtak a tervezett felülettel kapcsolatosak, tehát a megvalósítás nézet részét tartalmazzák (lásd modell-nézet-vezérlő).

   A megvalósítás második része a nézet mögött meghúzódó adatbázis-kapcsolat felhasználása az adott adatbázis (illetve munkafüzet) tábláinak a lekérdezésére. Ez a kapcsolat a már említett „Kapcsolódás létező adatbázishoz” opciónak köszönhetően adott és ennek felhasználására a létező API-nak köszönhetően elég jó eszközök állnak rendelkezésre. Így a lekérdezett táblaneveket egyszerűen lekérdezhetjük és megjeleníthetjük az „Importtündér” utolsó „Tábla kiválasztása” oldalán, majd hasonló módon felhasználhatjuk őket a tényleges importálásnál. (Ez a rész a modell)

   A harmadik lépés a kiválasztott táblák átalakítása olyan struktúrává, amilyen formába a vágólapra másolás során kerülnek. Ezt az alakot felhasználva be lehet járni ugyanazt az utat, amit a másolás+beillesztés esetén jár be a program, így elérve a „Tábla másolása” ablak felhasználását. Ennek az ablaknak és a hozzá kapcsolódó opcióknak nagy előnye, hogy az adott adatbázisban használatos adattípusoknak megfelelően lehet beállítani a mezők típusát, ami különböző típusú adatbázisok közötti tábla mozgatás esetén lehet lényeges. A munkafüzetek és szöveges állományok importjánál ez még inkább fontos tényező, hiszen szöveges állomány esetén még kevésbé egyértelmű az adattípus. A tábla átalakítása vágólapra helyezhető formátumba szintén könnyen elérhető adott osztályok felhasználásával, továbbá a vágólap tényleges felhasználásának mellőzésével is el lehet érni azt, hogy lefusson a beszúráskor lefutó kódrészlet. (Ez pedig a vezérlő)

   Tehát a terv így néz ki általában. A tényleges tervtől csak annyiban tér el, hogy nem tartalmazza a megvalósító osztályok és a mintául használt kódrészletek megjelölését. Ahogy említettem elég nagy része a funkciónak már adott, a legtöbb munka a felhasználói felület kialakításával lesz. A háttérben dolgozó mechanizmusokat a már létező osztályok egyszerű felhasználásával meg lehet valósítani. Ez a megvalósítás a következő hetekben várható.

   Végül elérkeztem az ösztöndíjas napjaim végéhez és egyben az utolsó beszámolom befejezéséhez, úgyhogy köszönöm a figyelmet, remélem elég érthető és érdekes írásokat sikerült közzétennem. Köszönöm az Alapítványnak a lehetőséget és a támogatást. Kelemen Gábornak is köszönet jár a beszámolók alapvető nyelvtani hibáinak korrigálásáért és a szakzsargon kifejezéseinek érthetőbbé tételéért. Ami engem illett, továbbra is folytatom LibreOffice-os fejlesztői tevékenységemet. A jelen beszámolómban leírt terv megvalósítása után a GSoC keretében fogok – ezúttal a Writer-hez – hozzáadni egy új funkciót (karakterszegély). A későbbi terveim még nem rajzolódtak ki előttem teljes valójukban, de bizonyára azok között is ott lesz a LibreOffice.

Április – Lokalizáció hatékonyságának növelése

Zolnai Tamás, 2013. május 3. péntek

   Az előző hónapban elkezdett kódtisztítást folytattam ebben a hónapban is. Több olyan megoldást töröltem, mely a régi rendszer maradványaként volt jelen a kódban. Ezzel egyrészről a kód olvashatóságát és annak egyértelműségét sikerült javítani, másrészről több helyen a feldolgozásból is sikerült törölni néhány felesleges műveletet, így javítva annak hatékonyságán. Ezen felül sikerült egy speciális adatstruktúrát implementálni, melynek köszönhetően a lokalizációs programok hatékonyabban képesek keresni a felhasznált sztringek között.

   Az első változtatásom, ahogy azt már előző beszámolómban is előrevetítettem, a forrásfájlok és a PO fájlok közötti sztringátalakításokkal kapcsolatos. A megoldás alapvető koncepciója, hogy a lokalizációs programokat megvalósító osztályok és a PO osztályok közötti kommunikációban a sztringek normál alakban szerepelnek, semmi olyan átalakítást nem tartalmazva, mely forrásfájlhoz köthető (Pl.: xml átalakítások, escape-elés). Így minden osztálynak csak a hozzá tartozó formátummal kell foglalkoznia és az ahhoz tartozó átalakításokat megvalósítania. Ennek az elkülönítésnek a jótékony hatása leginkább az *.src\*.hrc fájlokat feldolgozó transex3 program esetén figyelhető meg. Eddig a transex3 átalakításai három szinten jelentek meg: közvetlenül a transex3 forráskódjában (export.cxx), a lokalizációs programok által közösen használt kódban (merge.cxx) és a PO osztályok kódjában (po.cxx). Így valóban egy nehezen követhető megoldást sikerült leegyszerűsíteni.

Eredmény:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=d885a85a48a4706934e170b7a6671e5e029089a0

   Ahogy említettem a kódban volt néhány mára már elavult koncepció. Az első ilyen, hogy a lokalizálni kívánt sztringekhez a rendszer eltárolt egy platform attribútumot. Ez egyedül a transex3 programhoz kapcsolódik, mivel az *.src\*.hrc fájlokban volt lehetőség makrók segítségével definiálni platform specifikus sztringeket. Bizonyára azóta más szinten oldották meg a platformok problémáját, mivel a lokalizáció mára már figyelmen kívül hagyja ezeket (a PO fájlok sem tárolják). Egy adatstruktúra azonban még őrizte ennek a megoldásnak az emlékét. A lefordított sztringek forráskódba való beemelése során, a PO fájlokból beolvasott sztringek adatai egy olyan map-ben voltak letárolva, melyben a kulcs ez a platform tulajdonság. Mivel azonban ma már nem használatos ez a tulajdonság ezért, minden esetben egy konstans sztring alapján történt a beszúrás és a keresés (bizonyára egy ideiglenes megoldás). Szóval minden esetben egyetlen adatról volt szó, de annak letárolására egy egész map-et használt a rendszer.

Eredmény:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=be30e0e139ecc068665c8e46020b60356b05cfd6

   A felesleges adatstruktúra mellett ez a platform attribútum a feldolgozásban is felesleges sztringműveleteket jelentett, hiszen az adott makró definícióból ki kellett nyerni a tényleges platform azonosítót. Egy másik hasonló tulajdonság, mely növelte a feldolgozás műveleteit, a szélesség attribútum. Ez a tulajdonság szintén a transex3 programhoz és az általa feldolgozott *.src\*.hrc fájlokhoz köthető. Ezek a fájlok különböző felhasználói felületi elemeket definiálnak fix méretezéssel. Ezen méretek közül a szélesség mértékét valamiért külön felhasználták a lokalizáció során, de ma már ez sem használatos, így a feldolgozásnál külön nem kell foglalkozni vele.

Eredmény:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=9e2d2822063729f450adb734f58106bb64695ce6

   Egy másik régi koncepció volt, hogy a forrásfájlokba, melyekből ma kizárólag az angol stringeket emeljük ki, régen más nyelvű stringek is bekerültek, és az akkor még SDF outputba ezeket is kiemelték a lokalizációs programok. Ahhoz, hogy több nyelvű forrásfájlt ilyen módon fel lehessen dolgozni, le kellett tárolni a különböző nyelvek azonosítóit és azokat felhasználva lehetett eltárolni, illetve kiírni az adott string egyes nyelvi megfelelőit. A több nyelvű koncepció megszűnésével azonban nem szűnt meg a nyelvazonosítókat tároló vektor (ez szintén egyetlen elemet (en-US) tárolt minden esetben) és megmaradtak az ezen vektor bejárását célzó ciklusok is, melyek ciklusmagja minden esetben csak egyszer futott le. Így a kód nem igazán tükrözte a tényleges tevékenységet.

Eredmény:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=4146406205ce6f939944685e1931dcd45f3de708
és
http://cgit.freedesktop.org/libreoffice/core/commit/?id=f167f037351d953e324eb97d6055064efa2d7f59

   Miután sikerült a forráskódból kitakarítani az ily módon megmaradt felesleges kódok nagy részét, áttértem a hatékonyság javításának egy konstruktívabb formájára. Az egyes lokalizálandó sztringek azonosítására négy sztring attribútum szolgál (fájlnév, csoportazonosító, közvetlenazonosító, típus). Mivel ezek közül egyik sem hagyható el, ezért az ezekből összegyúrt sztringazonosító általában elég hosszúvá válik. Éppen ezért az ilyen azonosító alapján való keresés kevéssé hatékony, mint például egy számból álló azonosító esetén. Ezért az adatok közötti keresés hatékonyságának érdekében egy speciálisabb adatstruktúrát hoztam létre, illetve az eddig használt egyszerű hash map-et (unordered_map) módosítottam egy kicsit.

  Az új adatstruktúra hatékonyságának megértéséhez elengedhetetlen megismerni egy kicsit jobban a lokalizáció folyamatát. Két dolgot kell látni. Egyrészről azt, hogy a PO fájlokban a sztringek sorrendje általában megegyezik azok felhasználásának a sorrendjével. Ugyanis ahogy már említettem a lokalizációnak két igen jól elkülöníthető része van: a sztringkiemelés POT fájlokba és a lefordított sztringek beírása a forrásfájlokba. Mindkét lépésben ugyanaz a feldolgozás fut le, és így az érintett sztringek sorrendje mindkét esetben megegyezik. Azonban a PO fájlok frissítésének van egy átfutási ideje és így a folyton változó forráskód ezt a sorrendiséget részben megsérti. Éppen ezért egy olyan adatstruktúrát kellett készíteni, mely ezt a részben teljesülő sorrendiséget használja ki.

   A másik dolog, hogy a PO-kból beolvasott sztringeket legtöbb esetben pontosan egyszer kell felhasználni. Ebből látszik, hogy ideális esetben, mikor a PO fájlok és a forrás fájlok között konzisztencia van, az említett hash map-et valójában a FIFO elv szerint használjuk, annak ellenére hogy ez nem látszik a használatán és a hatékonyságán. Mivel azonban gyakori az inkonzisztencia ezért nem használhatunk egy az egyben egy sor adattípust, hiszen abban nem lehet keresni szükség esetén. Ugyanakkor az eddig használt hash map hatékony keresési lehetőségeket nyújt, legalábbis a sztringkulcsos keresések körében (a probléma a kulcs típusa). Így egyenesen adódott a sor és a hash map egyesítésének ötlete.

   A megoldás lényege, hogy a hash map-en belül definiáltam egy beszúrási sorrendet úgy, hogy az egyes elemek mellé letároltam egy mutatót, mely a beszúrási sorrendben rákövetkező elemre mutat (A hash map-ben az elemek sorrendje teljesen a hash-eléstől függ így arra nem lehet támaszkodni). A lekérdezések során pedig, minden esetben az előzőleg lekérdezett elem rákövetkezőjével kezdjük a keresést. Minél nagyobb a konzisztencia a PO fájlok és a forrásfájlok között, annál kevesebb tényleges keresésre van szükség (ideális esetben 0). Az így módosított hash map interfésze változatlan, csak a működése illeszkedik jobban a FIFO elvre.

   Ez csak egy vázlatos leírása a megoldásnak. További aspektusait nem lenne érdemes itt kifejteni, de azt még érdemes megemlíteni, hogy a LibreOffice által támogatott összes nyelvre való futtatás során, a keresések száma átlagosan úgy egy tizedére illetve egy századára csökken, programtól függően. Ugyanakkor a tesztelés során még az egy századra való csökkenés esetén sem volt látható szignifikáns változás a futási időben. Úgy tűnik a sztringkeresés futási ideje elhanyagolható a feldolgozásé mellett.

Eredmény:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=c7ef2522272579a12eecddded0cbed6d222d3742

Az utolsó hónapban a Base-zel fogok még dolgozni, úgyhogy a lokalizációs modullal való ismeretségem mintegy lezárásaként írtam minden osztályhoz egy rövid leírást az utókor számára.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=29400c568a84339066ef238e836cfeb19f732873

Március – Lokalizáció megtisztítása

Zolnai Tamás, 2013. április 5. péntek

   Ez a hónap főleg háttérmunkálatokkal telt. Egyrészről az előzőleg bevezetett új adatbázis funkcióhoz (limit) kapcsolódóan jelent meg a rendszer által nyújtott osztályok néhány hiányossága, melyek kielégítő kiküszöböléséhez még olyan alapvető adatstruktúrához is hozzá kellett nyúlnom, mint a rendszerben használt string osztályok. Másrészről a lokalizáció átalakítása során sok helyen fennmaradtak olyan sajátosságok, melyek a már megszűnt SDF fájlformátumhoz kapcsolódnak és az új PO-s rendszerben teljesen feleslegesek.

   A limit megadására használható kombinált listával kapcsolatban két megemlítendő probléma jelent meg, mely problémák a LibreOffice-ban implementált funkciók alsóbb szintjeire vezettek el. Az első a kombinált listát megvalósító osztályhoz köthető (ComboBox). Ennek az osztálynak a tényleges megvalósítását nem kell ismerni a felhasználáshoz, csakis azt, hogy a hozzá tartozó interfész függvényei milyen inputra, milyen outputot adnak vissza. A CalcSize() függvénye karakterszám alapján kiszámolja a kombinált lista méretét. Az így kapott értékek mértékegységét (talán mm), illetve tényleges értékét szintén szükségtelen ismerni, hiszen ezt az értéket egyből tovább is lehet adni a megfelelő függvénynek, mely ez alapján megrajzolja a kombinált listát. Mindez a jól kialakított interfésznek, illetve az objektumorientált paradigmának köszönhető.

   A CalcSize() függvény azonban nem a jó szélesség értéket adta vissza, így a tényleges implementációt kellett felülvizsgálni. Szerencsére az implementációnak is több szintje van, így a mértékegység ismerete továbbra sem vált szükségessé. Ugyanis a függvény egyrészről kiszámolja az adott karakterszámnak megfelelő szélességet (egy karakter szélességét szintén egy függvény adja meg) és ezt korrigálja további értékekkel. Ilyen érték az aktuális stílusnak megfelelő szegély, illetve a legördülő lista lenyitásához használható nyíl mérete. Az előbbi korrekció volt az, ami hiányzott.

Eredmény:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a31375528ad3d9fc49f5ab3982e96c9e46fa7af

   A másik probléma még mélyebb szintre vezetett. Nemcsak a felhasznált felhasználói felület elemeinek megfelelő osztályok implementációjába, hanem alapvető adatstruktúrák használatába is bele kellett mélyednem. A lekérdezésben elméletileg bármekkora limit érték megadható, mivel a visszatérési sorok száma is bármennyi lehet. Így a megadható érték korlátját csak az annak tárolására használt egészet megvalósító adattípus korlátjai jelentik (Int64). A probléma ott adódott, hogy a felhasznált osztály (NumericBox) az érték tárolásához használt egész típus maximumához közeli értékeket nem tudta lekezelni (Csak hogy milyen nagyságrendről van szó, ilyen szám például a 92 233 720 368 547 750).

    A probléma oka, hogy a NumericBox osztály belsőleg használ egy string → valós konverziót a túlcsordulás elkerülésére, mely string → egész konverzió esetén előfordulhat. A valós konverzió során azonban, túl nagy értékek esetén a konverzió kerekítéseket használ, és így az egész érték megváltozik. Ez pedig ahhoz vezet, hogy a beviteli mezőben más érték jelenik meg, mint amit a felhasználó begépelt. Ez azért nem okozott általában problémát, mivel a hasonló kombinált listák általában nagyságrendekkel alacsonyabb értékek begépelését engedik meg, ahol nem jelennek meg ezek a kerekítések.

    A megoldáshoz módosítani kellett a string osztályok részét képező string → egész konverziót, úgy hogy lekezelje a túlcsordulást. Majd az így módosított függvényt segítségével kellett lekezelni a viszonylag nagy egész értékeket. Ezzel a szélsőséges esetek helyes lekezelése mellett a hatékonyságot is sikerült némileg javítani, mivel a NumericBox a valós szám használatának köszönhetően rengeteg valós ↔ egész típuskonverziót is tartalmazott.

Túlcsordulás lekezelése:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=bd60d41176da540b01d7583cfe00637431967f39
Valós konverzió kiküszöbölése:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=84bac1799e528272ca808240508ca3f66272ee13

    A hónap további részében a lokalizáció területén végeztem néhány átalakítást. Elsőnek a lokalizáló programokban mintegy fantomként létező SDF formátum eltüntetése volt a cél. Ez a jelenlét főleg a kiemelés részfeladatára volt jellemző, ahol még ideiglenes SDF sorokat is generáltak a programok. Ez az ideiglenes SDF generálás azonban már olyan vékony köztes réteget képezett a lokalizáló programok és a PO fájlformátum között, hogy annak kiküszöbölése már egyszerűen megoldható volt. Ezzel sikerült a forrásfájlokban található összes SDF-re utaló elnevezést is eltüntetni.

Eredmény:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=15a13bafccb96e6ab0cc5a23af6dd46715fa22c5

    Az SDF generálástól való megszabadulás során felszínre kerültek további olyan adatok és funkciók, melyek az SDF formátumhoz köthetők. Talán amit érdemes megemlíteni a lokalizációt végző programok parancssori paraméterei. Az SDF tárolási módjához kapcsolódott két olyan paraméter („project” és „projectroot”), melyek néhány string művelet megkönnyítését szolgálták. Ezek a műveletek azonban már az előző átalakítások során eltűntek, így ezt a két paramétert is lehet törölni.

Eredmény:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=56a52889e65a17e324fc10cf341690385f5a9dd9

    Az átalakítások során sikerült jobban megismerni a lokalizációt végző osztályokat. Ezen információk rendszerezésére való törekvésem eredményeként, illetve az átláthatóság javításának érdekében némileg átalakítottam a lokalizációt tartalmazó modult (l10ntool). Ezek az átalakítások tartalmi változást nem jelentenek, alapvetően csak a forráskód átrendezését. Ez magában foglalja a több helyen használt azonos függvények kiemelését egy közös fájlba és a nem használt függvények törlését (ezek nem az SDF kiküszöbölésével váltak feleslegessé, hanem még régről maradtak meg).

Eredmény:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=8e26b4783f1f47ff5d489e7df5869240eefd1071
és
http://cgit.freedesktop.org/libreoffice/core/commit/?id=9d64e7f2b723a7bc711c2acc8da99944b30761ef

  Az átláthatóság növelésének fő célja a mélyebb tartalmi változtatások kieszközölésének elősegítése, mely a következőkben a célom, hiszen a hatékonyságot ilyen módon lehet leginkább javítani. Az egyik ilyen tartalmi átalakítás a fájlformátumokhoz köthető string átalakításokhoz köthető. Ezek az átalakítások két részre bonthatók. Egyik részt jelentik a PO fájlformátum és a forráskódban található formátum közötti konverziók. Másik részét pedig az olyan átalakítások képezik, melyek a fordítók munkáját segítik elő, a PO fájlformátum megengedte kereteken belül. Ilyen például az XML karakterek átalakítása olvasható formába (<,> ,& ,",').

Jelenleg ezen dolgozom. Első ilyen tartalmú javításom a súgó fájlok lokalizációjához kapcsolódik:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=ce51bf1a6ef36bbd1eea751add342cae6f1004d2

Február – Lekérdezés tulajdonságai

Zolnai Tamás, 2013. március 5. kedd

     A múlt hónapban írtam arról, hogy a limit megadására szolgáló eszköztári elem megvalósítása során milyen programozói eszközök és lehetőségek álltak rendelkezésemre, és hogy az adott megoldásnak milyen korlátai és lehetőségei vannak. Miután a módosításokat tartalmazó patch-et beküldetem elbírálásra, felmerültek további lehetőségek és igények a megvalósítással kapcsolatban.
   Néhány kisebb meggondolandó dolog mellett a leginkább kiemelhető igény a nem arab számjegyek használatára volt. Felmerült, hogy lehetővé lehetne-e tenni az olyan számjegyek használatát, melyek például a hindi, a kínai vagy a héber nyelvben találhatóak. A LibreOffice kódbázisában éppenséggel vannak erre szolgáló eszközök, és így sikerült is valamilyen szinten megvalósítani ezt a feladatot. Egy kicsit jobban utána nézve ennek a területnek azonban kiderült, hogy ha sikerül is teljes mértékben megteremteni az ilyen számjegyek használatának lehetőségét, akkor ez a beviteli mező lesz az egyetlen, amely ilyen tulajdonságokkal bír. Éppen ezért ezt az ötletet végül elvetettem. Ugyanakkor a megvalósításhoz kiválasztott osztályok megléte előrevetíti annak lehetőségét, hogy a jövőben ez a lehetőség globálisan elérhetővé váljon a LibreOffice-on belül.
   Egy másik jóval égetőbb igény a későbbi fejleszthetőség szempontjából jobb megvalósítás elérése volt. Felhívták figyelmemet egy olyan osztályra (NumericBox), mely olyan kombinált listát valósít meg, mely számokat vár a felhasználótól és ellenőrzi is, hogy vajon a begépelt szöveg az számként értelmezhető-e vagy sem. Ezen osztály használata egyrészről a későbbiekben elősegíti az olyan általános funkciók bevezetését, mint például a nem arab számok használata a beviteli mezőkben. Másrészről ez az osztály olyan funkciókat is tartalmaz, melyek növelik a felhasználói élményt. Ilyen funkció például a számok három számjegyenkénti elkülönítése a beállított szeparátorral (2,000,000) vagy a felhasználó által elgépelt szöveg automatikus javítása. (123h → 123).
    Tehát néhány változtatás után végül bekerült az új funkció a központi kódbázisba. Általános elvárás azonban minden eszköztári elemmel kapcsolatban, hogy azok elérhetőek legyenek a menürendszerből is. A tervező nézethez tartozó eszköztár összes többi eleme hasonló módon a „Szerkesztés” vagy a „Nézet” menüpontok alatt érhetőek el. Azonban ezek az elemek csak kapcsolóként működnek és így azok két állapotát (aktív/inaktív) a menüsorban közvetlenül jelezni lehet, pipával vagy grafikus effekttel rendszertől függően. Az általam megvalósított elem azonban egy beviteli mező, éppen ezért azt egy ablakban kellett elhelyezni. Mivel azonban a tervező nézetben nincs olyan ablak, mely tartalmilag megfelelne erre a célra, ezért egy új párbeszédablakot készítettem. Ez az ablak a Szerkesztés menüben érhető el, a “Query Properties” (magyar megfelelője valahogy így hangzik majd: „Lekérdezés tulajdonságai”) menüpontot választva jelenik meg. Az itt elért ablak a limit érték beállítása mellett lehetővé teszi a „Különböző értékek” kapcsoló állapotának változtatását is.
  A párbeszédablak megvalósításának három szintje van, melyeket már az eszköztári beviteli mező esetén is említettem. Ebből kettőnek a használat változatlan módon jelenik meg. Ez a kettő a központi vezérlő, mely a belső állapotokat tárolja, illetve az olyan felhasználói események kezelése, mint begépelés, lista megnyitása, szöveg kijelölés stb. A harmadik szintet a felhasználói felületet leíró XML fájlt jelenti. Ezen a téren már megfigyelhető néhány különbség. Az eszköztárak és a menüsorok leírására olyan XML fájlokat használ a rendszer, melyben valójában csak az adott elem azonosítója és az elemek sorrendje van definiálva. Ilyen esetekben ez elég is, hiszen elég kötött az egyes elemek elrendezése. Egy párbeszédablak, illetve bármely más ablak esetén azonban a leíró fájlban definiálni kell az elemek elhelyezkedését, méretét, méretezhetőségét, stb.
     A LibreOffice-ban nemrég került bevezetésére az XML fájlok használata (.ui kiterjesztés) az ablakok leírására. Azelőtt más típusú fájlok (.src\.hrc) segítségével lehetett definiálni a megjelenést. Ugyan én nem nagyon mélyedtem bele a régi típusú tervezés lehetőségeibe, de annyit tudok, hogy azelőtt koordináták alapján, manuálisan lehetett megadni az egyes elemek elhelyezkedését és a méret is statikusan volt megadva. Az új koncepcióban a koordináták teljesen eltűntek és leginkább a weboldalak írásához hasonló módon lehet tervezni, melyben dinamikus méretezési lehetőségek is helyet kapnak. Egyik legnagyobb előnye, hogy a Glade nevű programmal lehetővé válik, hogy a fájlok manuális módosítása helyett grafikus felületen lehessen megtervezni a kinézetet, azonnal látva a változtatások eredményét.
   Elég egyszerű ablakról lévén szó, sikerült megoldanom nagyobb stílustervezői tapasztalat nélkül, köszönhetően azon útmutatóknak, melyek találhatóak ebben a témában. Ezután már csak egyetlen dolog maradt hátra: a párbeszédablakhoz elkészíteni a súgót, melyet többek között szükségessé tesz az ablakhoz tartozó súgó gomb megléte is. Egyúttal a limit tervező nézetben való használatának útmutatóját is elkészítettem és ezzel vált teljessé az új funkció megvalósítása. Éppen ezért a következő hónapban áttérek tevékenységi köröm másik területére, a lokalizációra, mely ugyan láthatóan jól bírta az átállást, de hatékonyság területén még van mit javítani rajta.

A „Lekérdezés tulajdonságai” ablak megvalósításának kódja itt elérhető: https://gerrit.libreoffice.org/#/c/2508/

Januári beszámoló – Limit megvalósítás

Zolnai Tamás, 2013. február 5. kedd

     Ebben a hónapban az előzetes tervek alapján sikerült többé-kevésbé megvalósítani a limit érték beállítására használható eszköztári elemet. Az implementálás során felszínre kerültek a rendszer egyes előnyei és hátrányai, melyek nagyban meghatározták a megvalósítás konkrét lehetőségeit. Mindenesetre elmondható, hogy a tervezettől így sem kellett nagy mértékben eltérni.
     Az első dolog az előző beszámolóban említett központi vezérlő osztály használatához kapcsolódik. Ez az osztály központilag tartalmazza az egyes, ezen osztály alá rendelt objektumok, többek között eszköztári elemek állapotait. Az állapotok lekérdezésének és beállításának a módja, konkrétan az azt megvalósító metódusok előre adottak. Ez egyrészről jó, mivel rávezeti a programozót a megoldásra, másrészről azonban speciálisabb problémák esetén leszűkíti a lehetőségeket. Esetünkben szerencsére elég egyszerű funkció bevezetéséről van szó, így ezek a korlátok csak érintőlegesen jelentkeztek. Nagy előnye azonban ennek a megoldásnak, hogy az általa támasztott szabályok betartásával a lekérdezés elmentése és betöltése nem igényel további kódolást, hiszen az említett lekérdező/beállító metódusok segítségével a rendszer automatikusan végzi azt el.
    A következő megemlítendő dolog a limit megadására alkalmas kombinált listát kezelő osztály, amit az egyértelműség kedvéért nevezzünk helyi vezérlőnek. A LibreOffice-ban elég általános, ha nem az egyetlen, az a megoldási mód, amit én is alkalmaztam. Ennek egyik jellemzője, hogy maga a létrehozott osztály teljesen különálló egységet alkot, tehát nem szükséges manuálisan összekapcsolni más osztályokkal, melyek kapcsolatba szeretnének lépni vele. Egyszerűen egy azonosítóval kell ellátni az osztályt, regisztrálni a megfelelő helyen és az így lefoglalt azonosító alapján lehet kommunikálni vele. Tehát a kommunikáló felek nem egymás metódusait hívják meg és az alapján adják át az információt, hanem tényleges címmel ellátott üzeneteket váltanak egymással, melyet a rendszer kézbesít.
       Ilyen csatorna köti össze a két vezérlő osztályt is és éppen itt derült ki a programozás során, hogy ez a csatorna csak részben két irányú. Ugyanis a helyi vezérlő bármikor küldhet információt a központinak, de az ellenkező irányban csak az állapotok inicializálása során történik átvitel. Esetünkben az ellenkező irányú üzenetküldésre olyan esetekben van szükség, amikor feltehető, hogy a központi vezérlő nem ismeri a legfrissebb limit értéket, pedig a következő művelethez erre szüksége van. Ekkor kell lekérdeznie azt a helyi vezérlőtől. Ezt végül a közösen használt eszköztáron, mint közvetlen csatornán keresztül oldottuk meg.
   Tehát egészében véve elmondhatjuk, hogy a rendszert jól megalapozták fejleszthetőség szempontjából, ami a LibreOffice esetében létfontosságú. Azonban az adatbázis-kezelő komponens, amelyet sikerült egy kicsit jobban felmérni, tartalmaz néhány kevésbé dinamikus területet. Előző beszámolómban előre vetítettem az adatbázis-kezelő SQL elemzőjének módosítását, mivel például a „TOP” kulcsszót nem ismeri fel. Egy kicsit jobban belemélyedve az elemző használatába kiderült, hogy az általa visszaadott elemzőfa (amit előzőleg egyszerűbb struktúrának neveztem) csúcspontjai statikusan épülnek fel, ami annyit tesz, hogy az adott csúcsok bármely SQL parancs esetén mindig ugyanazt az elemet (pl. a „SELECT” kulcsszót) jelölik, tehát az elemzőfa szerkezete valójában mindig ugyanolyan, annyi különbséggel, hogy az adott csúcs milyen adatot tartalmaz, illetve hogy egyáltalán tartalmaz-e adatot. Ez még nem jelent problémát, de ez a megoldás lehetővé tette, hogy egy elemet a csúcs sorszámával lehessen azonosítani és ez a gyakorlatban is így terjedt el. Ez azonban már nagyban megnehezíti a bővíthetőséget, hiszen egy újabb kulcsszó bevezetése egy újabb csúcsot jelent a fában, ami pedig – attól függően, hogy a sorban pontosan hova kerül – felborítja az összes eddigi sorszám szerinti hivatkozást.
       Azonban ez két dolog miatt sem jelent olyan nagy problémát. Egyrészről egyes módosítások elvégezhetőek az elemző közvetlen megváltoztatása nélkül is. Másrészről az elemzőt használó forráskód elég jól körülhatárolható, éppen ezért a jövőben egy vállalkozókedvű programozó viszonylag rövid idő alatt képes dinamikusabb formába átírni az elemzőfa használatát. Mindenesetre amíg ez nem történik meg addig a „TOP” kulcsszó bevezetését későbbre halasztjuk, hiszen ennek használatára egyébként sincs számottevő igény. Egyetlen esetről tudok, amikor szükség lehet rá, ha MS Access adatbázisfájlt szeretnénk kezelni LibreOffice-ban.
     A LibreOffice adatbázis-kezelőjének egyik legnagyobb előnye, hogy mindenféle adatbázis-motorhoz képes csatlakozni. Ez a fajta multifunkcionalitás azonban leszűkíti az adatbázis-kezelő lehetőségeit és funkcióját. Alapvetően egyfajta univerzális felhasználói felületként szolgál és így a tényleges végrehajtás, illetve az azzal járó ellenőrzések nagy mértékben a háttérben futó adatbázis-motorra tolódnak át. Éppen ezért a programozás során az egységes információlekérdezés, illetve az egységes metódusok használatának lehetőségei szűkösebbek és így a fejleszthetőség ismét csorbát szenved.
     Esetünkben például a „LIMIT” kulcsszó használatakor, ugyan az elemző felismeri azt, de az aktuális adatbázis-motor még dobhat rá hibát. Éppen ezért felmerült az igény, hogy differenciáljuk az új eszköztári elem használatát, és csak olyan esetben legyen elérhető, amikor az ténylegesen funkciónál is. Azonban az említett információlekérdezési hiányosságok miatt első körben ezt nem sikerült megoldani kielégítő módon, így az új funkció minden esetben elérhető.
  Összefoglalva részben sikerült leprogramozni a limit megadására alkalmas beviteli mezőt. Azok a felhasználók, akik az alap adatbázis-kezelőt vagy olyan adatbázis-motort használnak, mely ismeri a „LIMIT” kulcsszót, azok minden további nélkül használhatják ezt a funkciót. Az általános megoldás megalkotása mellett felmerült az igény arra is, hogy ne csak az eszköztáron keresztül lehessen elérni ezt a funkciót, hanem a menüben is kapjon helyet, melynek megvalósítása egy új menüből megnyitható felugró ablak formájában már folyamatban van.
     Ezúttal linkelem a megvalósítás kódját is, hogy lehessen látni a tényleges eredményt. Ugyan még nem fogadták el a beküldött módosításokat, de némi bővítés után ez is meg fog történni. Tehát a link: https://gerrit.libreoffice.org/#/c/1994/

Decemberi beszámoló – Limit

Zolnai Tamás, 2013. január 5. szombat

     Ez a hónap is hozott magával néhány megoldandó problémát a lokalizációval kapcsolatban, melyek a po fájlokra való átállás következtében jöttek létre. Az sdf fájlos megoldás magában hordozott egyfajta robusztusságot, melyet – annak megszűnésével – közvetlenül a lokalizációt végző programokba kellett, illetve kell átültetni.
   Egyik legszembetűnőbb példa erre a felhasználói felületen megjelenő szöveges listák – mint például a menükkel – kapcsolatos probléma. Ha ezeket módosították a fejlesztés során, akkor legtöbb esetben rosszul jelentek meg a lokalizált felhasználói felületen.   Valahol rövidebb listák jelentek meg, de előfordult az is, hogy az egyes feliratok összekeveredtek és így teljesen érthetetlené vált az egyes menüpontok funkciója. Ezek a hibák a következő po fájl frissítéssel megszűntek így valójában ez a fejlesztők számára okozott leginkább gondot.
   Az sdf fájlok megszűnésével a lokalizáció által felhasznált adatok redundanciája csökkent, és éppen ezért az erre épülő megoldások helyett más megoldásra volt szükség. A probléma a transex3 program működésében volt. Ugyan találtam benne egy megoldási kísérletet, mely talán valamikor működött is, de az én szempontomból ez inkább volt félrevezető, mintsem célravezető. Végül egy kicsit jobban belemélyedve a kódba sikerült megtalálnom egy jónak tűnő megoldást, ugyan ezzel egyidejűleg egy lappangó hibára is fény derült. Egy programrészlet kétszer futott le a szükséges egy helyett, mely a legújabb változtatások hatására a végeredményben is változást eredményezett. Ezt kiküszöbölve még a hatékonyságon is sikerült javítani.
  A hónap másik felében az Alapítvány megbízásából belekezdtem a LibreOffice adatbázis-kezelőjének fejlesztésébe. Kaptam néhány konkrét fejlesztési ötletet, melyek legfőképp az érettségizők számára teszik egyszerűbbé a LibreOffice használatát az érettségi feladatok megoldásában. Az alapvető cél az, hogy ezek a feladatok megoldhatóak legyenek közvetlenül az adatbázis-kezelőn keresztül, illetve lekérdezések esetén teljes mértékben a tervezőnézetre lehessen hagyatkozni.
  Az adatbázis-kezelő felépítésének megismerését, illetve általában az új szolgáltatás bevezetésével járó feladatok megtapasztalását egy egyszerű funkció bevezetésével tartom célszerűnek, ami a következőképp néz ki. Gyakori feladat a lekérdezés eredményeként visszatérő sorok számának felső korlátjának megadása, melyet az SQL-ben a „LIMIT” illetve a „TOP” parancs tesz lehetővé. A LibreOffice adatbázis-kezelője ezt a funkciót csak SQL-nézetben nyújtja. Azt szeretnénk elérni, hogy a tervezőnézetben is elérhető legyen ez a funkció, melyet egy az eszköztáron található kombinált lista segítségével lehet elérni.
  A megvalósításnak több szintje van. A legfelső szint a felhasználói felület. A „Tervező” eszköztárat szeretnénk kibővíteni az említett kombinált listával. Ehhez módosítanunk kell az eszköztár leírását tartalmazó XML fájlt, létre kell hoznunk egy osztályt, mely kezeli ezt a felületi elemet, és végül össze kell kapcsolnunk ezt a kettőt. Így megjelenik a felhasználói felületen a korlát megadására alkalmas mező, de hatása még nincs a bevitt értékeknek.
   A következő szint a lekérdezéshez tartozó összes eszköztár állapotát figyelő és tároló osztály szintje. Ez az osztály (vezérlő) figyeli, hogy mely eszköztári elemek aktívak, illetve érhetők el, továbbá elvégzi az azokhoz tartozó adminisztratív teendőket. Ezen az osztályon keresztül lehet elmenteni a tervezőnézet egyes állapotait, továbbá SQL-nézetből való visszaváltás esetén ezen keresztül lehet inicializálni az eszköztárakat az SQL-parancsnak megfelelően. Tehát ezen osztály bővítésével a megadott érték ténylegesen tárolásra kerül és elérhetővé válik további feldolgozásra.
  A következő teendő a váltások során történő konverziók végrehajtása. Egyrészről a tervezőnézetben létrehozott lekérdezés alapján létre kell hozni az annak megfelelő SQL-parancsot az SQL-nézetbe való váltás során. Ehhez is megvan a megfelelő metódus mely a vezérlő osztálytól lekérdezve annak állapotjellemzőit felépíti az adott SELECT kifejezést. Így a korlátot tartalmazó mezőnek az értékét is lekérdezhetjük és beilleszthetjük az SQL-parancsba a „LIMIT” vagy a „TOP” kulcsszó társaságában.
   A másik irányú váltás is hasonlóan történik, csak itt az SQL-kifejezés alapján kell beállítanunk az eszköztár elemeit. Ehhez azonban kell egy saját SQL-elemző, mely értelmezi az adott kifejezést. Ez az elemző létrehoz egy egyszerűbb struktúrát, melyen keresztül könnyen lekérdezhetjük a kifejezés egyes jellemzőit, melyek alapján beállíthatjuk a vezérlő osztály állapotait. A korlátot megadó mező értékének beállításához tehát meg kell vizsgálnunk, hogy a kifejezésben szerepel-e a megfelelő kulcsszó és hogy milyen szám követi.
   Szinte már meg is van a megoldás, azonban maga ez az elemző a „TOP” kulcsszót például nem ismeri fel ezért is ad szintaktikus hibát, ha le szeretnénk futtatni. De a mi szemszögünkből talán nem is szükséges, hogy a „TOP” kulcsszót is le tudja kezelni, számunkra elég a „LIMIT” parancs is. Azonban ezen a téren is vannak hiányosságok, melyek az elemzés felsőbb szintjén helyezkedhetnek el. Egy teljesen egyszerű lekérdezés esetén, melyben csak egy tábla adott oszlopát kérdezzük le, a „LIMIT” kulcsszó hozzáfűzése „Az adattartalmat nem sikerült betölteni!” típusú hibához vezet. Rendezés esetén azonban rendben lefut. Tehát a feladatunk az elemző átírása, olyanra, hogy az felismerjen minden helyes „LIMIT” kulcsszót tartalmazó SQL-kifejezést. A „TOP” esetét hasonlóan meg lehet oldani.
   A megoldás utolsó momentuma a dokumentáció megírása. Egyrészről a felhasználók számára elérhető súgó megírása, másrészről a fejlesztők számára az új kódok és a régi de kevésbé dokumentált kódok tömör kommentelése.
   Tehát ez a terv vázlata, mely a forráskód böngészése során alakult ki és aminek megvalósíthatósága a következő hetekben derül majd ki.

Novemberi beszámoló

Zolnai Tamás, 2012. december 4. kedd

    Elérkezett a november vége, és ezzel együtt a hónapok óta végzett munkám ezen szakasza is a végéhez közeleg. Ebben a hónapban került be ugyanis a központi ágba a lokalizációs projektem eredménye, és most derült ki igazán, mennyire felel meg a vele szemben támasztott elvárásoknak. Azonban még mielőtt belemerülnék a felmerülő problémák ecsetelésébe, hadd írjam le milyen további tevékenységek előzték meg a végleges megoldást.
    A hónap elején a po fájlokon alapuló lokalizáció még nem volt teljes. A grafikus felület döntő része már a megfelelő nyelven jelent meg, azonban a súgó teljes egészében kívül maradt a honosítás hatókörén. A megfelelő program (helpex) már készen állt arra, hogy feldolgozza a súgó xml fájljait, de a hatékonyság érdekében változtatnom kellett rajta. Valójában részben az eredeti megoldáshoz tértem vissza, mivel a legújabb változtatások mintegy melléktermékeként rengeteg felesleges fájlolvasási művelet került bele a feldolgozó algoritmusba.
    Miután sikerült az egész rendszerbe bevezetni a po fájlok használatát, elérkezett az ideje a tesztelésnek. A po fájlok használatának két jól elkülöníthető része van. Egyrészről azokba gyűjtjük ki a lefordítani kívánt szövegeket, másrészről többnyelvű fordítás esetén ezekből nyerjük ki a fordításokat. Ezen két feladatnak megfelelően két fajta teszteléssel éltem.
    Az eredeti szöveg kinyerése eddig közvetett módon történt egy sdf fájl közbeiktatásával. A végeredmény mégis po fájlok gyűjteménye volt, amit az új megoldástól is várunk. Ebben az esetben elég egyszerű dolgunk lenne, hiszen csak a végeredményt kellene összehasonlítani. Azonban a saját po fájl formátumot megvalósító osztályok megírásakor kisebb változtatásokat vezettünk be a régi formátumhoz képest. A régi po fájlok megalkotási módja információveszteséggel járt, így kétséges volt, hogy önmagukban elegendőek a forráskódban található szövegek azonosítására. Továbbá több helyen duplán tárolódtak bizonyos adatok, melyeket mellőztünk az új megoldásban.
    A tesztelés tehát nem csak egyszerű összehasonlításból állt, hanem tartalmazott egyfajta konverziót is a két formátum között. A nagy mennyiségű tesztadatra való tekintettel ezt egy külön programmal valósítottam meg, mellyel sikerült kiszűrni a hibákat. Valójában itt csak néhány elírásra leltem a po fájlok fejlécében. Ez a teszt azonban a későbbiekben még további hasznos segítséget nyújt.
    A tesztelés másik területe a fordítások forrásfájlokba való beírása. Itt sokkal nagyobb volt az egyezés a két végeredmény között, így felhasználhattam a git által nyújtott lehetőségeket. Egy patchbe gyűjtöttem bele az új lokalizáció hozta változásokat. Azonban itt sem volt ilyen egyszerű a dolog. Egyrészről a qtz kód – amiről egyelőre annyit, hogy egy pszeudonyelv, mely a fordítókat segíti – megváltozott, így a hozzá tartozó sorok is változtak. Másrészről a régi és az új lokalizációhoz alapul vett forrásfájlok sem egyeztek meg teljesen, mivel a régi a központi ágban futott, míg az új a fejlesztőiben. Mindenesetre egy újabb program segítségével sikerült megtalálni a tényleges különbségeket. Itt olyan hibákat találtam, hogy az új megoldás nem dolgozta fel a readme-t, mivel annak po fájlja egy könyvtárral feljebb került, nem készült el az összes qtz-hez tartozó forrásfájl, illetve valahol a fájlok feldolgozásának sorrendje nem volt megfelelő. Ezen problémák megoldása nem igazán programozói tudást igényelt, sokkal inkább makefile-ok írásában való jártasságot.
    Ezek a tesztek ugyan nem fedtek fel igazán nagy problémákat, mégis hasznosak voltak, hiszen így bizonyossá vált a megírt algoritmusok helyessége. A további tesztesetek azonban alapvető feltevésbeli hibákat is felszínre hoztak.
   Ahogy már említettem a po fájlok megváltoztak, ez azonban szükségessé tette a régi po fájlok átalakítását új formájukra. Erre is elkészült már a program (renewpo). Készítésekor azonban nem elég megalapozott feltevésekre hagyatkoztam, így működésében alapvető hibák derültek ki a tesztelés során. A renewpo a po->sdf konverziót megvalósító po2lo programot felhasználva a régi típusú po fájlok információit egyetlen nagy sdf fájlba gyűjti össze, majd ez alapján készíti el az új po-kat. Felmerülhet a kérdés, hogy miért nem közvetlenül hajtjuk végre a konverziót. Ennek oka, hogy a régi po->sdf és az sdf->új po konverziók tesztelt és így megbízható forráskódra épülnek, másrészről a régi po-k, ahogy már említettem, nem tartalmaznak minden információt. A po2lo program működésének félreértése vezetett olyan problémához, hogy több po fájlból hiányoztak egyes bejegyzések, illetve a fejlécben található forrásmegjelölés is hibásan lett feltüntetve.
    Végül is eredményesen zárult a tesztelés, így a projekt elkészült időre. A központi ágban azonban további tesztek vártak az új lokalizációra. A LibreOffice saját tesztelő rendszere, a Tinderbox minden nyelvre és több platformra is lefuttatta az új rendszert és napokig adta ki magából a legkülönbözőbb hibaüzeneteket. A legtöbb hiba nem a program helyességével volt kapcsolatos, hanem sokkal inkább platformfüggő megoldások használatával. Ilyen hiba volt például, hogy a renewpo olyan programkönyvtárt használ, mely a Windows alatt nem létezik, továbbá felhasználtam olyan C++ nyújtotta lehetőségeket, melyeket néhány régebbi fordító nem tesz lehetővé, illetve olyan külső programkönyvtárat használtam, mely alap esetben nem felelt meg a LibreOffice által támasztott elvárásoknak.
    Ekkor látszott meg igazán mennyire jól működik a LibreOffice csapata. A hét elején én magam nem nagyon tudtam hibajavítással foglalkozni, de néhány fejlesztő megoldotta a főleg platformfüggetlenséggel kapcsolatos problémákat. A hét közepére magam is csatlakoztam és éppen jó időben, mivel pont egy programhelyességbeli hiba tűnt fel, melyet egy külső programozó jóval nehezebben oldott volna meg.
    Elmulasztottam jobban kifejteni mi is az a qtz nyelv, de ezt most pótolom, annál is inkább mert további teendőim is ezzel kapcsolatosak. Ezt a nyelvet az olvasó által bizonyára ismert Timár András vezette be a LibreOffice-ba, a fordítók munkájának megkönnyítése érdekében. A qtz valójában egy kódot jelent, mellyel meg lehet találni a fordítandó szövegek helyét a programon belül. El lehet készíteni egy qtz nyelvű build-et, ami annyit tesz, hogy a grafikus felület feliratai mellett megjelenik azok kódja, így a fordító jobban be tudja azonosítani a felirat célját és értelmét.
    Ez a qtz nyelv azonban sajátos helyet foglal el a nyelvek között. A kódok hasonlóan kerülnek be a forrásfájlokba, mint a valódi nyelvek fordításai, de a qtz önálló po fájlokkal nem rendelkezik. Maga a qtz kód az adott szöveg bizonyos adatai alapján generálódik le, így bármely nyelv po fájljait alapul véve ugyanazt a kódot kapjuk. Éppen ezt használjuk fel, és a qtz-t egy másik nyelv po fájljaiból nyerjük ki, attól függően, hogy melyik áll rendelkezésre. Ez a sajátos helyzet okozza a problémát, amit még csak részlegesen oldottunk meg. A grafikus felületen igen, de a súgóban és a telepítőben még nem.
    Tehát elkészültek az új po fájlok és a rendszer tudja is kezelni őket. Azonban a po fájlokba kerülő fordítások még hibát okozhatnak a build-elés során. A LibreOffice fordítása döntő részben a Pootle webes felületen keresztül történik, ami rengeteg hibát felfed, de sokszor jó fordításokat is hibásnak jelöl. Éppen ezért a jobb hibajelzés érdekében magam is megírtam egy új tesztet a Pootle által használt Translate Toolkit szoftvercsomagba, melyet el is küldtem patch formájában a fejlesztők számára. A teszt a súgóhoz tartozó fordításokban keresi meg azokat, melyekben valamely xml tag-nek nincs meg a nyitó/záró párja. Ilyen hiba esetén a fordítás nem kerül be a forrásfájlba, mivel az build-elési hibát okozna.
    Összefoglalva: végre sikerült megszabadulni az sdf fájloktól és áttértünk teljes mértékben a po fájlokra. Ugyan még van néhány kisebb fejleszteni való az új rendszeren, mégis úgy tűnik, életképes megoldást hoztunk létre. Így lassan új, ismeretlen területek felé veszem az irányt. Úgy hallom a Base környéke még szinte érintetlen terület.