Aleksandar je napisao(la):
Sta ti se najvise ne svidja kod Designer-a? Kako mislis da bi mogao da se poboljsa, konkretno?
Malo kasnim - prevideo sam da si odgovorio na moj prosli post
Elem, sto se tice Qt Designera, prve dve stvari koje su me od njega odbile su sledece:
1. "rucno" prebacivanje "tamo i ovamo" koristeci moc i ostalo. Znaci, snimim formu/dijalog, pa hajde u terminal, pa da se sve to konvertuje raznim meta-toolsima da bi na kraju dobio cpp kod. Bilo bi lepo kada bi mogao opis forme/dijaloga da se drzi "live" opisan kao nekim kvazi-XML formatom, da reaguje na izmene, pa da na promene direktno, tj live vrsi izmene koda. Bilo bi lakse kada bi gcc recimo podrzavao uvoz takvog zapisa forme, pa da se ne radi izmena koda "live" prilikom izmena, nego samo u slucaju includa takvog fajla. Treca varijanta - najjednostavnija izmena: nekako to povezati sa nazivom projekta (path, ...) pa makar staviti dugme u toolbaru za generisanje koda ili tako nesto - uglavnom na bilo kakav nacin izbeci odlazenje u terminal. Sve ostalo je komfor koji je uvek dobro dosao. Znaci, ako racunam da cu koristiti medju-alat da prebacim dijalog u qt-cpp kod, pa onda drugi da prebacim qt-cpp u "cisti" cpp kod, stavio bih naglasak na malo vecu "transparentnost" celog ovog postupka.
2. da se razumemo, nisam koristio trojku; zadnji Qt koji imam instaliran je 2.3.1 (drzim ga zbog AA fontova), mada sam dublje ulazio samo u 2.2.4, jer je CLX staticki vezan za ovu verziju. Ogradu pominjem zbog sledece boljke Qt dizajnera: imao sam uvek probleme sa dodavanjem drugih Qt ili mojih klasa u toolbar. Nakon nekog vremena sam jednostavno odustao.
Naravno, sve se ovo odnosi na linux verziju, posto, kako sam napomenuo, u winu koristim Qt samo posredno, preko CLX-a, pa win verziju nemam sta da komentarisem. Sto se tice linux verzije, jasno je da Qt development moze mnogo da se unapredi ako se veze za neki development environment. Dakle, treba ispitati da li je koriscenje Qt-a pod linuxom u 90% slucajeva vezano za (lupam sad) Kdevelop, pa ako jeste, isplati se napraviti paketic koji ce pod njim dati neke "extra-features" koji ce omoguciti vecu produktivnost.
Sto se dokumentacije tice, jeste, generisana je direktno iz koda sto ima svoje mane, ali je prednost da je 100% azurna - minor revizije izlaze prakticno svaki mesec (sledece nedelje se ocekuje 3.0.2), pa bi lov na izmene u dokumentaciji bio poguban..
Nemoj pogresno da me razumes, ali to nije ista "vrsta" dokumentacije. Dakle, po stilu pisanja i organizaciji moze vrlo lako da se napravi razlika izmedju "user", "programmer's" i jos neke dokumentacije. Ovakav striktno generisani dokument je (po meni) odlican za oblik "pratece" dokumentacije, koji se obicno koristi u opisne, ali manje-vise interne svrhe. Za jedan komercijalni paket, to mora vise da se okrene korisniku.
Na sta mislis sa "kvalitetniji sistem message dispatchinga"?
Hm, ja razvijam Qt pod Windowsom, tako da slabo poznajem (za sada) X desktop i specificnosti..
Pod ovim "message dispatchingom" sam mislio mapiranje sa CLX-om, ali se mozda nisam jasno izrazio. Mada sam se ogradio da bar 50% u tom mapiranju ide Borlandu na dusu. Pod time sa mislio na broj i tip argumenata koji se prosledjuju event-handlerima. Posto signal-slot mehanizam dozvoljava vecu slobodu, nije to moralo da se ogranicava sa tmessagetype tipom koji uglavnom prenosi jedan cardinal argument. Ok, odradilo se to na drugi nacin, pa sad i nije neki problem.
Sto se tice ovog X-a i detalja, iznecu samo jedan primer; fakticki svaki destop environment podrzava multiple-desktop organizaciju. Dakle, bilo bi lepo kada bi mogao da pokupim inf koliko na toj masini ima desktopova i da "preusmerim" kreiranje forme na [n] desktopu. Za sada funkcionise koncept da se program startuje i forma ce biti otvorena na trenutno aktivnom desktopu. Ali i ovo otvaranje forme na drugom ili "zadnjem" desktopu (recimo za mali monitoring programcic) meni zvuci kao sasvim logican zahtev
Ok, neke informacije mogu da se pokupe od X-a, ali vrlo sturo i neupotrebljivo, jer to i nisu njegove funkcije.