‘libreoffice’ címkével ellátott bejegyzések

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.

Októberi beszámoló

Zolnai Tamás, 2012. november 7. szerda

    Mivel ez az első beszámolóm az Alapítvány felé, így talán jobb lesz ha a hónapban elért konkrét eredmények ismertetése előtt egy pár szóban kifejtem, hogy miről is szól ez a projekt, melyen az utóbbi hónapokban dolgoztam, illetve dolgozom még most is.

  A LibreOffice lokalizációjában valamikor a múltban fontos szerepe volt az sdf fájloknak, de ez a fájlformátum az idők folyamán elavult, illetve maga az az óriásfájlos koncepció, mely egyetlen sdf fájlba gyűjtötte ki az összes fordításra kiemelt szöveget, nehezen kezelhetővé vált. Ezt váltották fel a po fájlok, melyeket egy jól meghatározott könyvtárszerkezeten belül szór szét a megfelelő lokalizációs program. Így egyrészről könnyebben kezelhető kisebb egységeket kapunk, másrészről egy ma is sok helyen használt fájlformátummal dolgozhatunk.
    A po fájlokra való áttérés során azonban nem iktatták ki magát az sdf fájlformátumot, belsőleg még mindig használja a rendszer, sőt a lokalizációt végző eszközök többsége ezt használja. Ezért is lesz lassabb a lokalizáció, hiszen a po fájlok használatához konvertálnunk kell azokat sdf-be illetve fordítva. A projekt célja pontosan az, hogy a lokalizáció közvetlenül használja a po fájlokat, és az sdf fájlok teljesen eltűnjenek. Ezzel a konverziók elhagyásával járó teljesítménynövekedés mellett megnyílik annak a lehetősége is, hogy a lokalizáció során jobban kihasználjuk a po koncepció nyújtotta lehetőségeket.
    Az első feladat a megfelelő po osztályok implementálása volt, melyek lehetővé teszik a po fájlok jól ellenőrzött és mindenekelőtt objektumorientált kezelését. A hónap elejére sikerült ezen osztályok segítségével átírni a lokalizáció alapvető eszközeit olyanra, hogy azok már po-t használjanak, és a tesztek folyamán látszottak is ennek áldásos hatásai. A leginkább szembetűnő változás a translations modul használatában állt be. Eddig ezt a modult build-elni kellett, ami valójában csak a po fájlok átkonvertálásából állt. Az áttéréssel ez megszűnt, és a po-k közvetlenül használhatókká váltak.

    Tehát a hónap elején alapjában véve a megoldás magja már készen állt és már csak az utolsó simítások maradtak hátra. Miután ez volt az az időpont, amikor átláthatóvá vált a po fájlok használatának összes aspektusa, ezért első dolgom a po osztályok végleges formára hozása volt. Alapvetően jól működtek ezen osztályok, de kevéssé voltak hibatűrők, és a fájlműveletek sem voltak elég jól elkülönítve. Továbbá több helyen az elnevezések sem illeszkedtek a LibreOffice coding standard-jához.
    Miután a po osztályok elnyerték végleges formájukat, áttértem azon problémákra, melyek a lokalizáció megújítása során bukkantak elő az egyes lokalizációt végző programokban. Ezek közvetlenül nem okoztak számottevő hibát a rendszerben. Egy részük felesleges számolásokat jelentet, másik részük felesleges sorokat az adott po fájlokban. Például az egyik fájlfeldolgozó program (ulfex) nem volt felkészítve arra, hogy a forrásfájlban lehet komment is, így az újonnan létrehozott és felkommentezett forráskódok esetén hibásan működött, még ha az outputja helyes is volt. Egy másik program (xrmex) pedig némi fogalomzavar miatt kétszer írt ki egy információt az outputjára, így az xml és xrm típusú fájlokhoz tartozó po-k redundáns információt tartalmaztak.
    Az előbb említett két program és még további 6 alkotja a lokalizáció magját. Ezen programok rengeteg közös tulajdonsággal rendelkeznek, és több közösen használt függvényük is van. Struktúrája és feladata alapvetően mindegyiknek ugyanaz, csak a feldolgozandó fájl formátuma különbözteti meg őket. Éppen ezért a paraméterezés is teljesen azonos. Ennek ellenére a paraméterek feldolgozása mindegyik forráskódjában külön-külön meg volt írva, valahol copy-paste módszerrel, valahol némi változtatásokkal. Ezen felül több olyan paraméter is szerepelt a programokban, melyek az idők folyamán kikoptak a használatból, így időszerűvé vált az inputkezelés átírása, illetve kiemelése egy közös függvénybe. Annál is inkább, mivel ezt a következőkben ki is szeretnénk használni.
    Az említett 8 bináris közül kettő nem C++ nyelven íródott, így az egységes kezelés érdekében és a C++-ban megírt po osztályok használatához ezeket is át kellett írnom. Az egyik a propex, ami perl nyelven íródott és a properties fájlok feldolgozásáért felelős. Átírásakor egy dologra kellett figyelni, hogy a helyesség megtartása mellett olyan programot írjak, mely felhasználja a közös használatra szánt függvényeket a későbbi fejleszthetőség érdekében. Éppen ezért az inputkezeléshez is az immáron egységes metódust használtam fel.
    A másik amit át kellett írni a súgóhoz tartozó tree fájlok feldolgozásáért felelős treex (azelőtt update_tree.pl). A tree fájlok tartalmazzák a súgófájlok kapcsolatát leíró fastruktúrákat. Ezek a fastruktúrák egyrészről tartalmaznak önálló, az eligazodást segítő címeket/alcímeket (belső csúcsok), másrészről az általa összefogott és hivatkozott súgófájlok címét (levelek). Ezért ez a program amellett, hogy a lokalizációt elvégzi az egyes belső csúcsokon, ellenőrzi a megfelelő súgófájlok létezését, és azok alapján frissíti az egyes levelek feliratát. A propex-szel ellentétben itt sokkal kevesebbet merítettem az eredeti forráskódból. Egyrészről az eredeti megoldás használt olyan fájlt is, ami valójában csak egy hack, és az új megoldással teljesen kiküszöbölhető, másrészről a tree fájlt reguláris kifejezésekkel dolgozta fel, míg C++-ban ennél jobb megoldás a libxml2 könyvtár használata.
    Tehát a kódolásnak a nagy része már megtörtént. A következő hónap feladata egyrészről a megfelelő makefile-ok átírása, másrészről a teljes körű tesztelés. Ezen felül a projekt futása során némileg változott a po fájlok szerkezete, a redundancia elkerülése, illetve az sdf fájl megszüntetése végett, így szükségessé vált a po fájlok új formájukra konvertálása is. 

LibreOffice-t fejlesztő egyetemistának ad ösztöndíjat az FSF.hu Alapítvány

timar, 2012. november 6. kedd

A LibreOffice az FSF.hu Alapítvány kiemelt projektje, az első pillanattól kezdve támogatja. Például alapítványi aktivisták végzik a honosítást, az alapítvány által birtokolt és üzemeltetett szerveren fut a translations.documentfoundation.org, részben finanszírozza a nyelvi eszközök (Hunspell, Lightproof) és egyéb hasznos dolgok (Numbertext, LibreLogo, Linux Libertine G betűcsalád) fejlesztését.

Ezen felül októbertől kezdve az FSF.hu Alapítvány ösztöndíjat ad Zolnai Tamásnak, aki az ELTE nappali tagozatos hallgatója, és nyár óta LibreOffice-fejlesztő. Az FSF.hu Alapítvány ezzel szeretné elősegíteni, hogy az ösztöndíjas zavartalanul végezhesse a LibreOffice-szal kapcsolatos kutatási/fejlesztési munkáját, melynek gyümölcsét közvetve vagy közvetlenül minden felhasználó élvezni fogja. Zolnai Tamás havonta ezen az oldalon fog beszámolni az elvégzett munkáról.

Még egy kis LibreOffice konferencia

Kelemen Gábor, 2012. október 27. szombat

Ami a legutóbbi bejegyzésről lemaradt, némi vizuális bizonyíték (köszi vmiklos!):

A magyar "csapat"

Frissítés:
Balról jobbra: Erdei Csaba, Zolnai Tamás, Mátó Péter, Kelemen Gábor, Blahota István, Németh László, Tímár András, Vajna Miklós.

LibreOffice konferencia 2. nap

Kelemen Gábor, 2012. október 25. csütörtök

Mi is történt múlt csütörtökön a LibreOffice konferencián?

Az első előadás, amelyre beértünk, Vajna Miklósé volt, és a LibreOffice kibővítéséről szólt új funkciókkal. Ugyan nem fogok elkezdeni kiterjesztéseket fejleszteni, de ez a jobban sikerült előadások közül való volt, szép munka :).

A következő előadás a sámánokról és kanárikról szólt, illetve ezek szükségességéről. A sámánok azok a projekttagok, akik egy-egy területről “mindent” tudnak, és bármire hatásuk van. A kanárik pedig azok az újoncok, akik végigjárják az egyes területeket, és mindenütt kipróbálják, hogy mennyire egyszerű segíteni. Ha nem egyszerű, akkor baj van, ezt jelzik a kanárik. Néhányan jelentkeztek erre a szerepre, érdekes ötletnek tartom.

Ezután a gravitáció megfordításáról hallhattunk. A LibreOffice bevezetését egy hegynek felfelé való harchoz hasonlította az előadó, amely pálya nem “nekünk” lejt. Át kellene alakítani a körülményeket, mert amíg például nem az LO natív fájlformátumában kell dokumentumokat kezelni, addig nincs sok értelme küzdeni: csak alulmaradhatunk, ha folyton mások után kell rohannunk. Ezen kívül nem elég remek irodai programcsomagot gyártani, ez önmagában nem lesz elég: ha van például a konkurenciánál egy jól integrált levelező, akkor nekünk is kell olyan. Ez valamennyire rímelt az előző napi repülő autós előadásra, azonban nem láttam, hogy ezeket a nagyon jól hangzó fejlesztéseket ki fogja megvalósítani.

Következő előadáson a téma az OOXML támogatás javítása volt, ez az Open Source Business Alliance projektje, és egy müncheni előadó ismertette.

Az ezt követő előadás izgalmasabb volt, mert az FSFE egyik tagja azt fejtegette, hogy mi akadályozza a LibreOffice-ra váltást a finn közigazgatásban. Röviden: a Microsoft. Vicces volt, hogy a Helsinki váltástól egy olyan tanulmánnyal próbálták meg elriasztani az érintett döntéshozókat, amely gyakorlatilag nem nyilvános. És a többi vád sem túl vidám, de ettől nem kell kétségbeesni: a FUD-ra szerinte a TFC a válasz: Trust, Facts, Confidence. A Trust azt jelenti, hogy bizalmat kell építeni, például a LibreOffice terjesztésével. A Facts azt jelenti, hogy tényekkel (esettanulmányok, tudományos publikációk, tudományos költségmodellel) kell támogatni a véleményünket. A Confidence pedig bizalomépítést jelent személyes kapcsolatokkal. Azaz a politikusoknak el kell mondani, hogy ha szabad szoftvert vezetnek be, akkor azért nem leszünk rájuk választóként morcosak, és nem fog a projekt kútba esni.

Ezt néhány rövidebb előadás követte, amelyeket már annyira nem követtem, ugyanis a müncheni városháza egyik informatikusával beszélgettünk arról, hogy ők mit és hogyan csinálnak, szerintem tanulságos volt.

Este közösségi vacsora, majd másnap már haza is jöttünk, ugyanis néhány kolléga akut családelvonástól kezdett szenvedni :). Számomra csak elméleti szinten volt hasznos a konferencia, mert a honosítással kapcsolatban nem volt különösebb aktivitás. Sikernek tekintem, hogy sikerült beszélnem Dwayne Bailey-vel, és az ő honosítási tapasztalatai között volt néhány hasznos ötlet, amit a közösségben kipróbálhatok.

LibreOffice konferencia 1. nap

Kelemen Gábor, 2012. október 18. csütörtök

Első nap a konferencián. Kicsit elkéstünk, de nem maradtunk le semmiről. A Google-ös keynote általánosságokról szólt csak, így nem volt baj az elejének elblicceléséből.

Az első előadás, amelyre bementem, a repülő autókról szólt, illetve azok hiányáról. Részletesebben kifejtve: 15 éve a mobiltelefonok hatalmas, buta készülékek voltak, amelyekhez képest a maiak fénysebesség felett közlekedő űrtechnikát képviselnek. A szövegszerkesztő pedig új ikonokat kapott. Hogyan lehetnek ezen változtatni? A jó példát a Google Drive képviseli, amely kitör a szerkesztő-fájlkezelő-levelező háromszögből, és egyszerűbbé teszi a tárolást és megosztást. Ez viszont nem szabad szoftver, itt lehetne jobbnak lenni tőle – a szükséges technológiák rendelkezésre állnak. Remek ötlet, remélem hogy lesz lehetőség a megvalósítására.

A következő a japán közösség két tagjának előadása volt, akik a helyi tapasztalatokról számoltak be. Ami meglepő, hogy náluk sincs kolbászból a szabad szoftver, és az egyetlen irigylésre méltó dolog az általuk kiadott, fényes papírra nyomtatott, hagyományos boltokban terjesztett szabad szoftveres újságok és könyvek. Egyébként ugyanolyan kevesen vannak, a különböző projektek nem egységes fordításokat készítenek, és alapvetően alacsony az érdeklődés.

Ezután a szaúd-arábiai helyzetről hallhattunk. Ott idén indult egy nemzeti szabad szoftveres központ, ahol a szabad szoftverek használható állapotúra pofozásával foglalkoznak. Jelenleg meglehetősen komoly problémák vannak az RTL nyelvek támogatásával a LibreOffice-ban (ciki :(), viszont ők elkezdték ezeket megoldani, és ezáltal szereznek kompetenciát, aztán lehet beszélni a bevezetés témájáról.
A következő előadás ugyancsak az RTL támogatásról szólt, ám az izraeli srác mögött nem állt komoly háttér, így csak panaszkodni tudott arról, hogy nem működik ez se meg az se – de az előző előadás végén azért megköszönt egy hibajavítást a szaúdiaknak :).

Az utolsó előadáson Németh László mutatta be a LibreLogot, ami teknőcgrafikát ad a LO-hoz, így az iskolákban LO használatával lehetne bevezetni a programozást. A cél a Librelogo bepakolása lenne az alapértelmezett telepítőkészletbe, de elég kevesen voltak az előadáson, így ez valószínűleg nem segíti az ügyet. Ezen kívül ez egy kevésbé sikerült előadás lett, alaposabb felkészülés kellett volna :(.

Ezután még volt egy BoF, ahol a fordítók beszélték meg a tapasztalataikat és a soron következő feladatokat. A lényeg, hogy mostanában sokat változik az LO, így nem lenne hasznos korán kinyitni a fordításokat a következő kiadásokhoz. Ezen kívül a Pootle új verziója, amely decemberben jön, számos új funkciót fog hozni, amelyeket már igencsak szeretnénk látni működés közben.

Este beszélgetés és sörözés az umbriai szabad szoftveres kompetenciaközpont vezetőjével, akinek igen hasznos meglátásai voltak a szabad szoftverek és az LO bevezetésével kapcsolatban (ők hamarosan indítanak egy ilyen nagyprojektet). Úgy érzem, ennek még lesz folytatása.

Ma: újabb előadások, újabb kapcsolatok, alig várom :).

LibreOffice konferencia 0. nap

Kelemen Gábor, 2012. október 17. szerda

Újra úton… ezúttal a berlini LibreOffice konferencián veszek részt, az FSF.hu jelentős különítményével. Velem együtt 6-an indultunk el, Németh László, Blahota István, Zolnai Tamás (ő a NPSH-nál volt szakmai gyakorlaton LO hibajavító, és még mindig érdeklődik a LO fejlesztés iránt) a kuratórium 2/3-a: Erdei Csaba és Mátó Péter. Rajtunk kívül a Suse színeiben jelen van még Tímár András és Vajna Miklós is.
A 0. nap kedden az utazással telt (kisbusz, jó szórakozás! -nem), majd este vacsora a sarki görög étteremben.
Ma pedig megkezdjük a tényleges munkát, szeretnénk összeismerkedni olyan emberekkel, akik már bevezettek LO-t különböző intézményekben. Már van is néhány jelöltünk 🙂

Szövegszerkesztés oktatóvideók a Szabad út projekt oldalán

toros, 2012. május 9. szerda

Elkészültek az FSF.hu Alapítvány Szabad Út projektjének keretében a LibreOffice Writer szövegszerkesztő használatát oktató videók. A korábban már bemutatott, a LibreOffice Calc táblázatkezelő, a LibreOffice Impress bemutatókészítő, valamint a LibreOffice Base adatbázis-kezelőt bemutató anyagokkal együtt így teljessé vált az irodai alkalmazások négy fő területével (táblázatkezelés, bemutatókészítés, adatbázis-kezelés és szövegszerkesztés) foglalkozó oktatási segédanyag. Az anyagok mindenki számára ingyenesen elérhetők, és szabadon felhasználhatók akár az otthoni önálló tanulásban, akár az iskolai tanórákon.

A videók a Szabad út projekt oktatóvideókat gyűjtő aloldaláról érhetők el.