[openeda:2004] - XML, GRAFIKA, Memorijska reprezentacija elemenata... by <ivankoi@tesla.rcub.bg.ac.yu>

Mozda je jos rano da govorim o ovome, jer jos se nisam dovoljno nacitao
dokumentacije :). Naravno intenzivno radim na tome.
Izvinjavam se svima sto nisam bio na sastanku. Bio sam bolestan, ali me je
Tixo dobro izvestio kako je bilo.

Evo o cemu se radi:

     Treca grupa treba da smisli odgovarajuce definicije za elemente kako
bi se elementi mogli lepo cuvati na disku.
s obzirom cemo u realnom radu imati ogroman broj elemenata grupisanim po
bibliotekama ne mozemo da smestamo tolike gomile podataka u XML fajlove,
jer bi parsiranje trajalo "godinama". Trenutno najinteresantnija ideja je
da se jedna komponenta cuva u jednom XML fajlu. Posledica toga bi bila da
bismo morali da se smaramo i da pravimo rutine koje bi pretrazivale tolike
kolicine fajlova, koji su mali ali ih ima mnogo. Elegantno resenje da se
ne izmislja topla voda je neka light-weight baza podataka u koju cemo
smestati opise elemenata i koristiti C/C++ API baze da ih citamo i pisemo
po potrebi. Tesko je zamisliti da bi mogli da napravimo bolje mehanizme za
upravljanje velikim brojem elemenata od vec gotovog sistema. Ovakvih
laganih, a zgodnih baza ima i razmisljamo koja bi bila najzgodnija, a ovaj
pristup nije neuobicajen u drugim aplikacijama.

     Dalje... XML zapis diktirace najverovatnije "zivot" i drugim grupama
(1. i 2.). Memorijska reprezentacija elemenata u radnoj memoriji koju
bi trebalo da smisli 2. tim, se sama namece. Ako kosristimo male XML
fajlove onda cemo da koristimo i DOM parser ciji je rezultat DOM
stablo u memoriji. Predlazem da clanovi druge grupe pogledaju XML
modul u Qt dokumentaciji, i da vide prednosti ovakvog modela. Shvatam
da ce clanovi druge grupe morati da uloze dodatni napor za ucenje ali
ce im rad biti olaksan, jer ce koristiti gotove Qt klase za
manipulaciju i nece morati da smisljaju neke dinamicke strukture i da
pisu metode za rad sa njima.

     I konacno... Ovde sam najtanji, ali mozda neko nesto zna vise o tome,
a i ja cu se nacitati narednih dana... Tice se graficke
reprezentacije elemenata. Toptanova prica o QCanvas-u je OK, ali to
nas ne resava problema vektor vs. bitmap. Grafika mora biti
vektorska, zbog zumiranja pre svege. Mozda cemo u editoru biblioteka
i moci bez zuma ali to ce nas cekati kasnije  kod editora sema. A kad
vec moramo da koristimo vektorsku grafiku i da pamtimo linije, tacke
, pravougaonike i sl. u fajlovima da bi mogli posle da ih vratimo na
ekran, onda nema razloga da smisljamo neki format vec treba da
koristimo SVG (Scalable Vector Graphic) koji je XML-ast format koji
je podrzan QPicture klasom za snimanje i ucitavanje grafike sa diska
na ekran. On kao i svaki XML moze da se parsuje i lako koristi sto
navodi na razmisljanje kako da se to lepo i koristi. Ovo sam naveo
kao neku smernicu 1. grupi nek mi ne zamere. QCanvas je OK i
upoznavanje sa njim je pod obavezno... tako se meni bar cini.


Sva ova prica je posledica konsultacija sa grupnum XML guruom Tixom, pa bi
valjalo da on pojasni nesto sto sam ja zaboravio i/ili pogresio.


TOPTANE drz' se pa se nadam se vidimo skoro zivi i zdravi!