Citat:
zastita:
Postoji li neka osnova, API, ili sta vec, koja ce da vrsi samo jednu funkciju - da prikazuje na ekran ono sto programer trazi.
Recimo da hocu da napisem svoj GUI koji ce da bude portabilan na Windowsima i na Unixu, sta bih trebao da imam, kako da posaljem neku grafiku na ekran?
Neću da ulazim u razloge zašto bi takav poduhvat bio veoma komplikovan i najverovatnije nepotreban.
U svakom slučaju, treba da se odlučiš prvenstveno u kojem jeziku želiš da radiš. Ako radiš u C-u, lakše ćeš ,,povezivati'' sa programima iz drugih jezika, a ako radiš u C++, imaćeš bolju sintaksnu kontrolu (pošto pretpostavljam da ćeš da praviš u objektnom maniru, a ne
message-based kao što su Xlib i Win32 API). Naravno, ukoliko se odlučiš za neke skript jezike koji imaju već gotovu podršku grafičkog okruženja pod oba sistema, posao će ti biti lakši (ali, pitanje je postoje li takvi skript jezici; možda Tcl/Tk?)
E sada, pretpostaviću da si odabrao C++, kao najrasprostranjeniji predmetno-usmereni (aka objektno-orijentisani ;) programski jezik. Ukoliko želiš da što veću količinu koda možeš bez ikakve izmene da koristiš na obe platforme, potrebno je da napraviš jedan ,,interfejs'' između sistemske grafičke biblioteke (Xlib, Win32 API, Framebuffer, SVGALIB...), i tvog GUI okruženja.
U neku ruku, može se reći da praviš virtuelnu-grafičku-mašinu (dozvolite da je tako nazovem), koja će sadržati samo osnovne grafičke primitive, i baratanje sa porukama (odnosno u predmetnoj paradigmi sa događajima).
Prednost ovakvog pristupa je u tome što će ti najveći deo koda biti lako prenosiv na veliki broj platformi (potrebno je napisati samo grafičke primitive za svaku od njih), ali ono što je velika mana je to što će to raditi relativno sporo. Druga prednost/mana je što će GUI stalno izgledati isto na bilo kojoj platformi (pošto ćeš sam iscrtavati sve predmete i polja za unos).
Ovakav pristup mi se čini da koristi GTK+ (zajedno sa svojim portom na Win32), a najverovatnije i FLTK (leko, ispravi me ako grešim; na Win32 nisam probao).
Drugi pristup bi bio da napraviš dva kompletna zasebna okruženja oko sistemskih API-a, koji bi imali samo isti interfejs. Tada tvoja biblioteka zapravo ne bi bila portabilna, ali bi programi bili. Primer ovakve biblioteke ne znam (možda QT ima podršku i za ovako nešto?).
Prednost ovakvog pristupa bi bila brzina i izgled nalik domaćinu. Naravno, ogromna mana je što moraš za svaki sistem da pišeš praktično kompletnu biblioteku pokušavajući da ostvariš samo isti interfejs.
Moguće je da neke biblioteke koriste pristup između ove dve krajnosti, pa se za to i ti možeš odlučiti.
U svakom slučaju, pored GTK+, FLTK biblioteka (i mnogih drugih), zaista mislim da nema razloga da pišeš svoju (nisam mogao da odolim). Čak, postoje i mnoge druge, manje poznate koje rade i pod FB, SVGALIB, itd...
Toliko.
PS. Dejane, da li FLTK 2.0 podržava UTF-8? Pre par meseci kada sam pravio neke programčiće sa njim nisam uspeo da ga koristim (verzija iz CVS-a naravno)---a nisam bio raspoložen da pišem svoje textedit razrede.
PostPS. Ukoliko zbog preterane upotrebe srpskog jezika ne razumete neke od mojih reči, evo par napomena:
razred -- klasa; predmet -- objekat; poruke -- messages; događaji -- events
Ukoliko je ovo učinilo vaše čitanje težim, odlično :)
set {from = value;}
}
Možda se moje mišljenje promenilo, ali ne i činjenica da sam u pravu.