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

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.