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

LibreOffice konferencia 2013 – 3. nap

Kelemen Gábor, 2013. október 3. csütörtök

Volt még a konferenciának egy utolsó napja is.

Az előző napokon nem említettem, de ez a nap azért volt érdekes, mert az alapítvány aktivistái, azaz Németh László és én is ekkorra voltunk beosztva az előadásunkkal.

Elsőnek egy, az API-változtatásokról szóló, erősen technikai jellegű előadásra ültem be, tulajdonképpen csak azért, mert korábban generáltam egy olyan patchet, ami egy ilyet tett szükségessé, és pont kapóra jött hogy kikérhetem az előadó véleményét. Szerencsére nem volt kifogása, éljen a LibreOffice-fejlesztők rugalmassága :).

Utána meghallgattam egy érdekes előadást a szaúd-arábiai szabad szoftveres fejlesztőközpontról, amelynek relevanciája, hogy rátettek 7 frissen végzett programozót a LibreOffice-ra, akik a jobbról-balra írás támogatását kezdték el kikalapálni, valamint elkezdtek felkészülni a LibreOffice bevezetésére. Nem sietik el, de mondjuk mutattak néhány vicces, általuk megoldott bugot is, szóval érthető az óvatosság és az alapos előkészítés.

Ezután jött Laci és a LibreLogos előadása. Ő azt találta ki, hogy a Wikipédiába LibreLogoval generált SVG-ket (és SMIL-eket, ami az animált SVG) tölt fel, mellékeli a felhasznált pár soros LibreLogo forrást, és így kelti fel a programozással ismerkedő gyerekek és tanárok figyelmét.

A következő előadás a brazil LibreOffice magazinnal foglalkozott, amelyet nyilván LibreOffice-szal készítenek, és elég népszerű arrafelé, de mint hogy brazilul van, számunkra csak mint jelenség érdekes, tartalomként nem.

És ez után jöttem én, beszélni a munkahelyi projektekről. Kicsit meséltem a kompetencia központról, aztán rátértem, hogy milyen fejlesztéseink is lesznek LibreOffice-közeli témákban. Ez egy hálás téma, az EU Joinup portálja utána “azonnal” (persze az újságíró már három nappal korábban megszagolta a szenzációt, és folyamatosan egyeztettünk a szövegről :)) ki is hozott egy rövid cikket róla. Lényeg, hogy lesz felügyeleti eszköz, és lesz magyarított WollMux, konkrét kódokkal és részletekkel hamarosan tudunk majd szolgálni.

A további előadások már nem voltak olyan izgalmasak (oké, Miklós git alapozója bizonyára jó volt :)), a “nép” is előző este óta folyamatosan gyérült, és a délután zömét már csak a korábbi események dokumentálásával töltöttük. Illetve megünnepeltük a projekt 3. születésnapját, ami pár nappal korábban volt, szolid alkohol- és kiadósabb sütifogyasztással :).

Este elmentünk várost nézni, és igazat kell adjak Hajninak abban, hogy Milánó mint város annyira nem nagy durranás – a dóm persze ott van a szeren, de Milánóban sétálni olyan, mint egy átlagosnál jobban karbantartott pesti kerületben. Viszont találtunk egy “autentikus” kis családi pizzázót, ahol a keddi kínai étteremnél nagyságrenddel jobb pizzát adtak.

Csoportkép a magyar résztvevőkről (köszi Miklós!):

LibreOffice konferencia 2013 – 2. nap

Kelemen Gábor, 2013. szeptember 27. péntek

Második nap, és nem tévedtünk el. Igazából az első előadás, amivel az általam tegnap preferált szekció kezdődött, a főszervezőé volt és 20 perc késéssel indult.

Én a nap nagy részében a migrációs sávon voltam, mert ez egy rém fontos téma. Első előadásként általánosságban definiálták, hogy mi az a migráció, hogyan kell megtervezni, mire kell számítani, hogyan kell kommunikálni, hogyan kell bevonni a felhasználókat, milyen hibákba nem érdemes beleesni. Ezek a dolgok azok, amik sikerre vitték az umbriai migrációt, amiről két előadással később volt szó. Megtudtuk továbbá, hogy a változással szembeni ellenállás természetes emberi reakció, és kezelhető, de ennek elmaradása esetén a felhasználók nagyon gyorsan meg fogják magyarázni, hogy miért nem lehet migrálni. Várható még idén egy migrációs protokoll definiálása, amely a korábban kiadott migrációs white paperen alapul, és a fentieket fogja formálisan is leírni, felkészüléssel, időbeosztással.

A második előadás egy holland migrációval foglalkozó nonprofit szervezet tapasztalatait foglalta össze. Ők pár ezer gépet tartanak kézben néhány alkalmazottal, és szerintük is fontos a felhasználóknak elmagyarázni, hogy mi miért történik (nem, nem azért hogy neki rosszabb legyen, a főnöknek meg új BMW). Először el kell mondani, mit fogunk csinálni (véleményt kérni, oktatni, telepíteni), aztán megcsináljuk amit bejelentettünk. Ezzel elnyerhető a felhasználók bizalma, ami nélkülözhetetlen. Meg kell kérdezni a véleményüket, megismerni az általuk használt munkafolyamatokat, aggodalmaikat, tippjeiket, javaslataikat.

Harmadik előadás az umbriai sikertörténet volt, vagy ahogy ők előadták, szerelmi történet. Ebben az esetben 5 területen dolgoztak: csapat, feladat, kommunikáció, képzés, eszköz.

A csapaton végzett munka lényege a résztvevők közösséggé formálása volt, ez a LibreUmbria projekt egyik eredménye.

A feladattal kapcsolatos munka lényege a projekt megtervezése volt.

A kommunikációval kapcsolatos munka lényege a felhasználók meggyőzése volt, a projekt miértjeinek megismertetése személyes és elektronikus formában egyaránt.

A képzéssel kapcsolatos munka a technikai támogatás, (helyi) oktatók, kulcsfelhasználók és felhasználók képzése volt. A módszerek lényege hogy a technikai támogatás és oktatók személyes oktatást kaptak, a kulcsfelhasználók és a felhasználók távoktatást és kaszkád oktatást is kaptak – a technikai támogatástól és a helyi oktatóktól, ami számukra a személyes oktatás volt. A távoktatást nem tervezték előre, de a jobb skálázódás miatt szükséges volt.

Az eszköz kategóriában a felhasznált eszközöket ismertették, illetve hogy miért választották a LibreOffice-t. Az egyik érdekes kiegészítés (firmacondike) volt a digitális aláírás megkönnyítése, amit az olasz törvények megkövetelnek, ezt ők egy kattintásba sűrítették.

Következő előadás a felhasználói dokumentációk írásáról szólt, és kisebb részben a fordításukról is. Ez utóbbi egy fájdalmas pont, de találkoztam olyan emberrel, aki ugyanettől szenved és elkezdett valamit fejleszteni a fölösleges XML-szemét kihajigálása érdekében.

 

A napot egy érdekes előadás zárta a LibreOffice certifikációról (tanúsítás). Ez egy régóta tervezett és talán jövőre elkezdődő projekt, amelynek lényege, hogy a tanúsított szakembereket nyilvántartja és vizsgáztatja a TDF, így az ügyfelek tudhatják, hogy egy-egy cég hány ténylegesen hozzáértő szakemberrel rendelkezik.

Este hackaton volt, és az előző napival ellentétben itt nem volt tárgynyereménnyel motiválás, mint előző nap, de egy általam generált hibának azért sikerült a végére járnom.

LibreOffice konferencia 2013 – 1. nap

Kelemen Gábor, 2013. szeptember 26. csütörtök

Idén is rendeznek LibreOffice konferenciát, a tavalyi után most is részt veszünk egy kisebb csapattal, az FSF.hu támogatásával. A régebbi aktivisták közül Németh László és én, az új generációt pedig Zolnai Tamás és Pintér Krisztián GSoC-diákok képviselik.

Kedden érkeztünk Milánóba, és városnézés helyett elkezdtünk a másnapi előadásokra készülni. Ez leginkább Tamást és Krisztiánt érintette, a GSoC diákoknak ugyanis szerdán kellett 5 percben bemutatniuk, hogy mit alkottak.

Szerdán az első napirendi pont az eltévedés volt, aztán sikerült beesni egy, a hackelés olasz helyzetéről szóló előadás közepére. A nap első felében csak egy szekció volt, délután terebélyesedett háromszekcióssá a program. Ez az első előadás nem volt túl érdekes, mert túl általánosra sikerült. Aztán arról hallhattunk, hogy milyen migrációs projektek vannak, szintén Olaszországban. Ugyan kívülről nem sok minden látszik, de nem csak Umbria tartományban, de számos más helyen is folyamatban vannak migrációk, és az olasz közösség meglepően hatékonyan kezeli több más város/tartomány közigazgatásának migrációját – mindenképpen jó hír.

A következő előadás a LibreOffice projekt szokásosnak mondható éves beszámolója volt – egyre több közreműködő van, céges és egyéni szinten egyaránt, akik kezdik elhomályosítani az örökölt Sun/Oracle közreműködéseket a kódsorok számát tekintve, elvileg ez volt a lényeg.

Ebéd előtt a LibreOffice körüli cégek gazdasági körülményeiről hallhattunk, ami azért volt érdekes, mert megismerhettük, hogy ezek hogyan képzelik el a saját szerepüket: a helyi kisebb cégek intézményi szinten biztosítanak első szintű támogatást, ha a problémát nem tudják megoldani, akkor egy nagyobb, második szintű támogatásra képes cég szolgáltatásait veszik igénybe (pl oktatás, kisebb hibajavítások), ha pedig ennél is komolyabb a probléma, akkor ezek egy harmadik szintű támogatásra képes cégtől kérnek segítséget, például komolyabb hibák javításához, az interoperabilitás javításához, komolyabb új funkciók kifejlesztéséhez. Az utóbbi két kategória cégei pedig képesek támogatni a TDF-et, amelynek célja a LO-alapú gazdaság fejlesztése (de nem magának a kódbázisnak a fejlesztése).

Ebéd és a kevésbé reprezentatív egyetemi helyszínre való átvonulás után a CloudOn cég képviselője ismertette, hogy mit szeretnének ők az ODF formátummal. Nos, ők alapvetően a felhőben gondolkodnak, és jobb szeretnék, ha a felhasználók dokumentumait nyílt fájlformátumban tárolnák a szervereiken, illetve szeretnék ha az ő alkalmazásuk lenne a legnépszerűbb (de most se áll rosszul), és ennek érdekében fejlesztik a szolgáltatásukat, ODF-alapon.

A következő pont Vajna Miklós (Collabora) előadása volt arról, hogy hogyan is állnak a LibreOffice Writer szűrői az egyes formátumok támogatásával. Elég nehéz lemérni az ilyesmit, mert bonyolultak a szabványok, de megpróbálta. Az XML-alapúak esetén csak a definiált XML-címkéket nézte, azok tulajdonságait egyelőre nem (az egy másik mélység lenne, plusz az import-export sem ugyanaz). Az eredmény, hogy az ODF szabvány majdnem teljesen támogatott (nem meglepő), a DOCX elég jól, de csak kb 80%-ban. Az RTF szabvány meglepő módon rengeteg elemet definiál, amelyeknek kb a harmada támogatott csak. Az egyik legjobban a WW8 szűrők állnak, mivel ezek a legrégebbiek, és ezek a leginkább kompatibilisek a megfelelő MS Office formátumokkal. Persze ennek meg az a hátránya, hogy mint szabvány nem fejlődik, így a LibreOffice legújabb fejlesztései nem lesznek megvalósítva az exportáláskor.

Ezután a GSoC panel következett, ahol Krisztián a LibreOffice Start Center felújításáról beszélt. Szerintem igen jó munkát végzett, és sikerült is jól előadnia magát. Tamás a karakterekre terjesztette ki az oldalakra, szakaszokra és bekezdésekre alkalmazható szegélyt, és az eközben szerzett tapasztalatairól számolt be. Az ő dolga eléggé szerteágazó volt, és az előadása nem sikerült olyan jóra, picit alulmaradt az angol nyelvvel szemben – sebaj, azt a török srácot se dobálták meg, aki az első diáján kijelentette, hogy az angol nyelvtan szabályait most felfüggesztené :).

Utolsó előadásként arra ültem be, amely a kollaboratív szerkesztésről szólt. A legnagyobb gond ezzel, hogy az ODF formátumot nem erre találták ki, amit a meglévő etherpad-szerű szerkesztők használnak, az nagyon eltérő. Emiatt egy kíséleti projekt indult, amely egy webes szerkesztőtt készített, amelybe egyszerre többen is írhatnak, de már képes a dokumentumot ODF-ben exportálni. Egyelőre itt tartanak, hogy mikor lesz ebből LibreOffice-összetevő, az bizonytalan.

És akkor ez volt az első nap, este hackathont szervezett a CloudOn, ahol a cél interoperabilitási hibák javítása volt. Nekem mondjuk épp volt valami sürgős fordítanivalóm, de ezzel együtt sem dobtak ki. Laci megszerelt egy kupac elválasztási hibát, Krisztián és Tamás pedig a közösséggel ismerkedett – kreatívkodtak és a nemzetközi kollégákkal beszélgettek.

Valencia régió közigazgatása sikeresen migrált LibreOffice-ra

toros, 2013. augusztus 27. kedd

A spanyol autonóm régió, Valencia vezetése sikeresen befejezte a szabad és nyílt forráskódú LibreOffice irodai programcsomagra történő migrációját. A régió informatikai osztálya bejelentette, hogy az irodai programcsomag a régió 120 ezer számítógépére került fel, köztük iskolák és bíróságok gépeire. A migráció éves szinten 1,5 millió euró megtakarítást jelent a helyi kormányzat számára a szoftverlicencek költségében.

Valencia

„A gazdasági előnyökön túl más haszna is van a szabad és nyílt forráskódú szoftvernek, így például az, hogy a megoldás egyaránt elérhető katalán és spanyol nyelven, és függetlenséget biztosít az IT beszállítótól, amely így bátorítja az üzleti versenyt” – nyilatkozta az informatikáért felelős osztály igazgatója, Sofia Bellés. „Arra is lehetőségünk van, hogy a szoftvert módosítsuk és adaptáljuk az igényeinken megfelelően” – emelte ki nyilatkozatában.

Bellés állítása szerint Valencia régió 2012 második felében kezdte meg a migrációt, és máris segített 1,3 millió euró megspórolásában, amelyet egyébként a zárt forráskódú irodai szoftver licenceire kellett volna költeni. A váltás része annak az intézkedéssorozatnak, amelyet a régió tanácsa az informatikai költségek csökkentése érdekében hozott, részben a szoftverlicenceken történő megtakarítás formájában.

Nyilatkozatában az informatikai osztály további szabad szoftveres kezdeményezésekre is rámutatott, mint amilyen a Lliurex Linux disztribúció bevezetése 110 ezer PC-n a régió összes iskolájában. Ez több mint 30 millió euró megtakarítást hozott a 2005-ös bevezetés óta.

„A szabad irodai programcsomag telepítése a régió önkormányzatának szabad szoftverek használata melletti stratégiai elkötelezettségének része. Nem csak a licencköltségek megtakarításában segít, de a helyi informatikai szektor fejlődését is segíti, támogatja a katalán nyelv használatát a digitális világban, és javítja az interoperabilitást és biztonságot a régió informatikai rendszereiben.”

forrás: Joinup
kép: Flickr, jpcolasso, CC-by-nd 2.0 licenc

LibreOffice 4.1: mérföldkő az interoperabilitásban

toros, 2013. július 25. csütörtök

Az irodai programcsomag nagy számban tartalmaz olyan fejlesztéseket, amelyek új szintre emelik a kompatibilitást a zárt és régi fájlformátumokkal

Berlin, 2013. Július 24. – A Document Foundation bejelenti a LibreOffice 4.1-et, amely nem csak minden idők legjobb, de egyben a legmagasabb szintű interoperabilitást is biztosító szabad irodai programcsomagja. A LibreOffice 4.1 nagy számú fejlesztéssel szolgál a dokumentumok kompatibilitása területén, amely így könnyebbé teszi a zárt szoftverek felhasználóival történő információcserét az eredeti tartalom és a formázás megőrzése mellett.

Az interoperabilitás kulcsfontosságú érték a LibreOffice számára, amely 2012 eleje óta a de facto szabvány a szabad irodai programcsomagokra történő migrációban. Számos fejlesztés történt a Microsoft OOXML import és export, valamint a régi Microsoft Office és RTF fájlformátum szűrők területén. A fejlesztések legnagyobb része a migrációs projekteket támogató fejlesztőktől származik, akik hivatalos támogatási szerződés keretében dolgoznak.

Fontos szerepet töltenek be az interoperabilitásban az olyan szolgáltatások, mint például a betűkészletek beágyazása a Writer, Calc, Impress és Draw alkalmazásokban. Ez segít megőrizni a dokumentumok vizuális megjelenését akkor is, ha a célszámítógépen nem található meg az adott betűkészlet. Szintén az interoperabilitást javítja az Excel 2013-ban megjelent új függvények ODF OpenFormula kompatibilis exportja és importja.

Az interoperabilitás mellett a LibreOffice 4.1 számos egyéb területen kínál új szolgáltatásokat és fejlesztéseket. Ezek részletes felsorolása itt olvasható:

Az alábbiakban ezek közül a legfontosabbakat soroltuk fel:

  • Képek forgatása a Writerben 90 fokonként;
  • Impress prezentációk készítése képsorozatokból a PhotoAlbum szolgáltatás segítségével;
  • A Vonal és Pont (XY) Calc diagramtípusok esetén elérhető a lépcsős vonal típus;
  • A megjegyzéseket megjelenítő sáv egyszerűen ki- és bekapcsolható a vonalzón lévő gomb segítségével;
  • Az utoljára megnyitott dokumentumok közvetlenül elérhetők az eszköztárról a Megnyitás gomb melletti lenyíló menü segítségével, valamint fejlettebbé vált a fájlnevek megjelenítése az utoljára megnyitott dokumentumok listájában;
  • A Calc táblázatkezelő a kijelölt cellák számát akkor is számolja, ha azok nem szomszédosak;
  • A szöveghez fűzött megjegyzések a Writerben akár több bekezdésre is vonatkozhatnak.

A LibreOffice 4.1 több, az Apache OpenOffice irodai programcsomagból származó szolgáltatást is átemelt, köztük a Symphony oldalsávot, amely egészen addig kísérleti szolgáltatás marad, amíg nem lesz integrálva a felületielem-elrendezési technikával (amely dinamikusan átméretezhetővé, így a LibreOffice más ablakaival konzisztenssé teszi).

A LibreOffice 4.1 komoly fejlesztési folyamat eredményeként érkezik. Erről bővebben az alapítványi blogon olvashat: wp.me/p1byPE-q0.

A LibreOffice letöltése

A LibreOffice 4.1 már letölthető a következő címről: www.libreoffice.org/download. A LibreOffice bővítményeket a következő oldalon találhatja: extensions.libreoffice.org/extension-center.

A változások listája az alábbi oldalakon olvasható:

Támogassa a The Document Foundationt

A The Document Foundationt a LibreOffice felhasználók, a szabad szoftverek hívei és a közösség tagjai a donate.libreoffice.org oldalon támogathatják. Az így gyűjtött pénzt az alapítvány az infrastruktúra fejlesztésére, valamint a projekt iránti figyelem felkeltésére szolgáló marketing tevékenységre fordítja globális és lokális szinten egyaránt.

A The Document Foundationről (TDF)

A The Document Foundation egy nyílt, független, önmagát irányító, meritokratikus szervezet, amely az OpenOffice.org közösségben végzett tíz évnyi elkötelezett munkára épül. A TDF abban a hitben jött létre, hogy a független szervezeti kultúra a legjobbat hozza ki a vállalatokból és önkéntes hozzájárulókból, és a legjobb szabad irodai programcsomag megszületését eredményezi. A TDF nyitott minden egyén számára, aki elfogadja annak alapértékeit és hozzájárul a tevékenységéhez. Az alapítvány szívesen fogadja a vállalati részvételt is, például olyan formában, hogy annak alkalmazottja egyenrangú félként vesz részt a közösség munkájában. A TDF-nek 2013. június 30-án több mint 160 tagja, és 3000-nél is több önkéntese és hozzájárulója van világszerte.

forrás: blog.documentfoundation.org/2013/07/25/libreoffice-4-1-interoperability/

Az AMD csatlakozott a TDF tanácsadó bizottságához

toros, 2013. július 3. szerda

A LibreOffice mögött álló alapítvány, a The Document Foundation (TDF) bejelentette, hogy az AMD csatlakozott az alapítvány tanácsadó bizottságához. Az AMD elsősorban x86 kompatibilis processzorairól és nagy teljesítményű grafikus csipjeiről ismert. A gyártó jelentőségét jól mutatja, hogy a közelmúltban bejelentett új generációs konzolok, a PS4 és az XBOX One egyaránt a gyártó nagy teljesítményű integrált processzoraira épülnek majd.

A TDF és az AMD együttműködésének célja első körben, hogy az AMD GPU-k (Graphics Processing Unit) és APU-k (Accelerated Processing Unit) által kínált teljesítményt és párhuzamos feldolgozási képességet kiaknázzák a táblázatok kezelésében, ezzel segítve az összetett táblázatokkal dolgozók munkáját.

A fejlesztések hatását leginkább azok fogják érezni, akiknek AMD APU működik a gépükben, de a munka eredményeként a jövőben minden felhasználó nagyobb táblázatokkal dolgozhat, gyorsabban, mint eddig.

Az AMD belépésével 11-re bővült a The Document Foundation tanácsadó testületének tagsága. A tagok: AMD, Google, RedHat, SUSE, Intel, Lanedo, the King Abdulaziz City of Science and Technology (KACST), the Inter-Ministry Mutalisation for an Open Productivity Suite (MIMO), Free Software Foundation (FSF), Software in the Public Interest és Freies Office Deutschland e.V.

További információk a The Document Foundation hivatalos közleményében.

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/