Osvedcilo se:

- Osobne mi prislo pri tvorbe uzivatelske dokumentace vhodne, kdyz
jsem ji psal sam - pusobila pak vic jednotne, kapitoly byly psany
podobnym stylem. Mozna by neskodilo, kdyby i podobu dialogu urcoval
jeden clovek (v nasem projektu je tvorilo nekolik lidi a vysledek byl
Eintopf).

- Vedeni todo filu.

Problemy:

- [Linux -> Windows] Pri pokusu o prenos aplikace psane s pouzitim Qt
2.3.2 na OS Windows nastal problem. Pri operaci DnD v prubehu dragu
nejsou na Windows dorucovany nektere udalosti. V dusledku toho mi
neslo sledovat napriklad pohyb mysi v prubehu dragu (coz jsem chtel
vyuzit pro vykresleni nejakeho widgetu na prislusnem miste). V mailing
listu (tusim, ze se jmenoval qt-devel) jsem se dozvedel, ze se s timto
problemem nekdo jiz obracel na trolltech (vyvojari Qt) a dostal
odpoved ve smyslu, ze takove veci se proste deji a ze jde o zalezitost
Windows.

- [Linux] Mam podezreni, ze knihovna Qt 2.3.2 obsahuje v kodu pro DnD
bug, ktery muze vest k segfaultu. Problem se projevoval pri rychle
opakovanem provadeni rychlych operaci DnD. Demonstrovat to slo
napriklad na vzorovem prikladu prilozenem ke zdrojakum knihovny;
priklad se jmenuje "dragtest". Zkuste zbesile provadet operace DnD, ja
jsem po par hodinach ziskal cvik, diky kteremu aplikace pri dalsich
pokusech behem kratke doby sletela. Predpokladejme, ze jde o bug. S
timto bugem se nam podarilo uspesne vyrovnat (tj. padani aplikace pri
DnD se pri testech neprojevilo) osetrenim kritickych operaci. IMHO je
problem v tom, ze Qt pro ulozeni odkaz na tazenou vec pouzivaji jedno
misto v pameti, ktere nemaji dobre chranene. Hrozi pak, ze dojde k
prepsani odkazu drive nez je zrusen stary objekt. Po te dojde namisto
zruseni stareho objektu ke zruseni noveho a pri pokusu o pristup k
tomu novemu (ktery byl zdestruovan) dojde k segfaultu. Tenhle problem
jsem snad vyresil tim, ze jsem si daval pozor, abych nenastartoval
drag dokud nebylo ukonceno zpracovani dragu predchoziho.

- [Linux] Rozhrani sitovych (TCP/IP) sluzeb je v Qt realisovano
neblokujicimi funkcemi, ktere se vsak smi volat pouze z GUI threadu.
GUI thread se nesmi nikde zablokovat a cekat na akci zvenku (butonkovani,
sit) protoze to by byl dead-lock. Pokud chcete blokujici funkce
pro sitove rozhrani (jako ze kazdy normalni clovek je chce),
vede to nutne k napsani wrapperu. Takze mate blokujici funkce,
ktere vsak nemuzete z popsanych duvodu volat z GUI threadu.
Abyste nemusili psat KA, tak si udelate framework, ktery se chova,
jako byste v GUI threadu volali blokujici funkce. Ale tou dobou
jsou zdrojaky necitelne, program neladitelny a efektivita se podela
kdovikam.

- [Linux] Obcas se pri pouzivani aplikace psane v Qt 2.3.2 stavalo, ze
udalost souvisejici s operaci DnD neobsahovala zadna data. Netroufnu
si prohlasit to za bug v Qt, ale pokud byste se s tim nekdo setkali,
vite, ze se to stalo i mne :-) Vyresil jsem to testem, jestli jsou
data nebo nejsou. Pokud ne, operaci DnD jsem ignoroval. Pri praci s
aplikaci jsem pak nepocitil zadne omezeni.

- [Linux] Pri praci na projektu jsem narazil na problem, kdy dochazela
vlakna - ackoli (dle meho nazoru) byla vsechna drive vytvorena vlakna
joinovana ci detachovana, pthread_create selhalo. Nejprve jsme
implementovali zasobarnu vlaken, kam se vlakna ukladala po vykonani
urcite cinnosti a byla v pripade potreby pouzita pro dalsi praci. (coz
mohlo vest i ke zrychleni prace - vlakna se nestartovala pomoci
pthread_create). Pozdeji jsem si vsiml, ze problem nam zpusobil
debugger gdb - i jednoduchy testovaci program, ktery jen vytvarel
vlakna a pak je joinoval, v nem skoncil na problemu s pthread_create,
ackoli bez debuggeru bezel dle ocekavani.

Pro priste:

- [prg] Kdybych psal projekt znovu, udelal bych jeden soubor, kde by
byly shromazdene vsechny chybove hlasky. Na zaver by se pak snadno
zjistilo, ktere je potreba zdokumentovat.