Jesli li probao nešto do sad?

Ne radi se o tome da li sam i šta probao, već da li neko zna za takvu biblioteku.

- Qt ne čuva kompatibilnost unazad. Qt4 nije ni binarno ni sors kompatibilan sa Qt3.
- wxWidgets 2.7.x nije kompatibilan sa 2.6.x.
- FLTK 2.x mislim da nije kompatibilan sa FLTK 1.x. Ispravite me ako grešim.
- Gtk+ mislim da nije kompatibilan unazad. Nisam ga koristio do sada, ali bih rado počeo ako je kompatibilan unazad. Da li je objektno orjentisan?

Ono što mi se zaista sviđa je Lazarus. On ima samo jednu manu - zasnovan je na Free Pascal jeziku. Radije bih koristio C++.

Mislim da sve biblioteke imaju problem sa nasleđivanjem, jer su to uvijek u početku neki prototipi i pokušaji koji završe čak kao i komercijale, i kad tad mora doći do nekih radikalnih promjena, unapređenja gdje se javlja nekompaktibilnost. Najveći problem je čak i binarna nekompaktibilnost, kao što si pomenuo!

Ja sam razvijao program na GTK+ 2.2 i taj isti program nije htjeo da radi na Linuxu koji ima GTK+ 2.8 verziju, možeš skonati, i nije proradio dok nije instaliran GTK+ 2.2.

Stoga, ostavljam ovo nekom iskusnijem da malo bolje objasni, ja sam samo iznijeo svoje iskustvo...

P.S. Što se tiče Lazarusa, ko god je jednom radio nešto u Delphiju, mislim da upošte neće imati problem da pređe na Lazarus.

Qt4 nije kompatibilan sa Qt3 ali mozes da racunas da ce sad jedno dugo vreme Qt4 i njegovi upgrade-i biti kompatibilni. Kao sto je i Qt3 dugo vremena drzao svoj API. Sumnjam da ces naci i jednu biblioteku koja cuva kompatibilnos unazad bas toliko... Zasto bi to radili ako shvate da mogu neke stvari mnogo bolje da rese... :-/

Da, FLTK 2.x nije kompatibilan sa 1.x, ali FLTK 2.x je posebna grana razvoja, ciji razvoj jos uvek nije zavrsen do stabilne faze. Ona izmedju ostalog treba da implementira neke karakteristike koje 1.x grana nema (podrska za promenu izgleda itd.) od kojih je dobar deo vec implementiran (npr. UNIKOD podrska za neke jezike, smestanje svega vezanog za biblioteku u "fltk" imenski prostor itd.).
Zasebne grane bi trebale da budu kompatiblne sa starijim verzijama. Medjutim, jedna od boljih osobina ove biblioteke je sto je biblioteka mala i optimizovana za staticko povezivanje, pa ako se odlucis za ovakav nacin povezivanja tvog programa to ce umnogome umanjiti zavisnost barem na binarnom nivou.

Postoje jos neke biblioteke koje bi verovatno hteo da proveris da vidis da li ti odgovaraju. Listu bi mogao da pogledas npr. ovde gde koliko vidim nisu samo biblioteke za graficki korisnicki interfejs.

Izdvojio bih FOX biblioteku, koja je stabilna i ima UNIKOD podrsku ali iskreno ne znam koliko odrzava kompatibilnost sa ranijim verzijama. Izgled na podrzanim platformama je konzistentan i nalik na programe u Vindouzu 9x.

Ne znam da li bi odgovarala tvojim potrebama ali je svakako interesantna i Ultimate++ biblioteka, ciji su programi, kada sam je poslednji put preveo samo da vidim kako izgleda (pre godinu dana) na Linuksu imale skoro autoenticni izgled programa na Vindouzu XP :) Uporedjenje sa nekim drugim biblioteka na nivou izvornog koda mozes da pogledas ovde: http://upp.sourceforge.net/www$uppweb$comparison$en-us.html

Javi za koju si se odlucio :)

Jedan tip je isprobavao razne GUI biblioteke ovog meseca i blogovao o tome. Vidi ako ti nešto pomogne:

http://garrys-brain.blogspot.com/2006_10_01_archive.html

FOX otpada jer ne dozvoljava upotrebu više niti u aplikaciji (videti FAQ).

Backward compatibility mozhe ali i ne mora biti veliki problem, narochito kod poznatijih biblioteka.
Ja bih izbegavao biblioteke koje forsiraju svoj izgleda widgeta, to niko ne voli. WxWidgets je, za sada, ipak bez premca

Ja želim sledeće: da krenem u razvoj neke ozbiljne aplikacije, uz moguće potrebno učenje (ako je potrebno), ali da znam da kroz nekoliko godina neću morati da menjam ceo kod zato što je nekome palo na pamet da naruši kompatibilnost unazad. Bitna mi je prvenstveno kompatibilnost na nivou izvornog koda. Binarna se lako može prevazići statičkim povezivanjem. Lepo je čika Bil vodio računa da (uglavnom) sa MS bibliotekama bude tako, a kasnije u .NET-u su uvedeni i asembliji, pa da čovek može da bude miran. Šteta što MFC nije multiplatformska biblioteka.

Ne bih voleo da mi kao jedino rešenje ostane Lazarus, jer bih zaista radije da koristim C++. No, kako stvari stoje, izgleda da bez Paskala nema ništa.

Ni Pascal ponekad nije loše rješenje, pogotovo ako se radi o FreePascal-u. Evo možeš ovdje da se uvjeriš u moć ovog alata!

Tu biblioteku nisam koristio.
Ipak sto se visenitnog programiranje tice u tom odeljku takodje pise i sledece:

Inace, da li je tebi potreban kompletan prenosivi razvojni okvir (framework) ili samo prenosiva biblioteka za graficki korisnicki interfejs?

Paskal je malo ćopav sa kontrolom toka (break, continue, return for) i još nekih stvari., C++ programi su pregledniji, lakše mi je da pronalazim greške itd.

Višenitnost se najčešće koristi upravo za GUI, da bi korisnik mogao da prekine proces koji može dugo da traje. Koliko znam, GUI biblioteke obično ne obezbeđuju samo GUI, nego i umrežavanje, višenitnost itd. Nemam ništa ni protiv povezivanja C++ modula sa modulima pisanim u drugim jezicima, pod uslovom da je to povezivanje prenosivo.

Pa zaista, ako ti je bitno da GUI biblioteka obezbedjuje i "kitchen sink" uzgred, onda ne razumem zashto se opiresh Wx-u :)
Eventualni prekid kompatibilnosti sa starim verzijama je neminovna stvar, pre ili kasnije.

Biblioteke za programiranje grafickog korisnickog interfejsa uopsteno pruzaju upravo to - jedan pristup da se napravi graficki korisnicki interfejs. Radni okviri s druge strane pruzaju npr. i omotace za upravljanje mreznim uticnicama, servisima, nitima, datotekama, tekstom itd.
Ipak, ovo ne bi trebao da "propagiras" u prisustvu Linuks fanatika :) jer ce vrlo verovatno svako pa i ovakvo predlaganje doslednosti, reda/standarda da protumace kao ogranicavanje GNU "slobode", ma kako to skaredno zvucilo. Skoro sam na Linuks forumu pisao i o nekompatibilnosti (ne samo u vezi razvojnih biblioteka) kao jednim od glavnih problema Linuksa. Medjutim, njegovo nepostojanje mi je na posletku objasnjeno upravo tom "slobodom", koja ne bi trebalo nikako da se "skrnavi" pa ni zbog tamo neke kompatibilnosti.

U svakom slucaju, ako ti je doslednost u ovom smislu neophodna, mozda ne bi trebao da se oslanjas na striktnost kod vec pomenutih biblioteka, iako su kod nekih, "fluktacije" u poslednje vreme veoma male (npr. u vezi zasebnih razvojnih grana FLTK-a).

Mene ljudi poput degojsa, Ivana Dimkovića i cyniquea (bivšeg Sundancea), čija znanja lično cenim, ovde smatraju Linux fanatikom.

Dobro niko nije savrsen :))

Nisam stekao utisak da si barem u ovom smislu (kompatibilnost/red i tzv. "ogranicavanje slobode") "fanatik", ako ipak jesi (ili smatras da jesi) onda mislim da ne bi trebao da budes kontradiktoran, ta nekompatibilnost cini mi se, i jeste cena te "slobode" ;)

Srecno.

_{[Ovu poruku je menjao Milan Aksic dana 29.10.2006. u 04:07 GMT+1]}

Smattram da sam fanatik samo utoliko što mi je ikada palo na pamet da postavim makar i jedan post na forumu Advocacy (za prepljuvavanje) i to mi ne služi na čast. Ljudi "hladne glave" koji čitaju moje postove, baš kao i ti, ne stiču utisak da sam fanatik. Koliko puta sam branio closed source/MS/Windows od nekorektnih tvrdnji suprotnog tabora, ali i obrnutro.

A što se slobode tiče, ja sam za razliku od GNU/FSF-ovaca pre svega za slobodu izbora. Ako se nekome više sviđa jedan softver (iz bilo kog razloga) nego neki drugi, neka ga koristi. Ako neko želi da licencira svoje autorsko delo na neki način, neka to i učini. Apsolutno ne smatram niti da je open source, niti da je closed source sam po sebi zlo, kao ni da su GNU licence zlo, kao ni da je MS EULA licenca zlo, kao ni da nešto od toga nema svoju pozitivnu ulogu u društvu, suprotno stavovima oba tabora. Ako nekome nešto ne odgovara, ne mora to da koristi. Po tome se razlikuju OSI i FSF.

Vrlo tesko ces naci biblioteku koja nije menjala svoj API u proslosti, do mere narusavanja kompatibilnosti.

Ako imas vremena i veliku potrebu za cross-platform kompatibilnoscu, i ako ce platform-independent deo koda biti mnogo veci od GUI interfejsa - jedno od resenja je da napravis svoj Windowing API, koji bi preko neke vrste apstrakcionog sloja mapirao na neku poznatu UI biblioteku - time bar stitis svoj kod od znacajnih izmena UI biblioteka.

Kasnije portovanje bi se svodilo samo na izmenu apstrakcionog sloja.

Ovo naravno ima smisla samo ako se radi o velikoj kolicini koda - gde bi bilo neprakticno menjati UI funkcionalnost na mnogo mesta - kada se UI API promeni.

Svaka čast Ivane. Lično mislim da ljudima od struke mnogo više priliče ovakvi forumi nego Advocacy. Šteta što ti, degojs i cynique gubite vreme na advkatisanju. Ovde možete biti mnogo korisniji.

Da, za to rešenje sam znao, i izgleda da će tako ići. Tako funkcionišu video igre koje treba da koriste DirectX , odnosno OpenGL u zavisnosti od toga koja je grafičćka karta ubodena. Tu se čak biblioteka menja dinamički tako što se napravi apstrakcioni sloj u vidu apstraktne klase, a onda se iz te klase izvedu primerci apstrakcionog sloja za svaku od biblioteka, pa se dinamički instancira apstrakcioni objekat koji je primerak odgovarajuće izvedene klase i onda se dalje radi pozivanjem njegovih metoda.

Zahvaljujem svima na korisnim savetima i linkovima. Ako neko bude imao šta da doda, neću imati ništa protiv. Moja će odluka ubrzo pasti ili na wxWidgets (verovatnije) ili možda na VCF.

Off Topic
Gle, gle... Gde ima dima - ima i Dimkovića :)
Šala, naravno... Ivane, bilo bi lepo da češće svraćaš na "ove" forume.

Topic
Nerealno je očekivati da bilo koja "ozbiljna" biblioteka klasa, nakon niza godina, verzija i
usavršavanja, i dalje ostane 100% kompatibilna sa "samom sobom" od svog nastanka.

Primarno, zato što Operativni sistemi nemaju svoj "konačan" oblik i smisao, nego se
menjaju prilično često. GUI biblioteke se trude da isprate sve te novotarije i sasvim je
OK da nakon nekog vremena izvrše "reorganizovanje" sopstvenih interfejsa u skladu sa
novinama. Očuvanje kakve-takve kompatibilnosti sa starim kodom bi vremenom dovelo
do (IMHO) još većeg haosa. Po meni, bolje je raskrstiti sa zastarelim stilovima odmah i
zauvek.

Na primer, danas je Title Bar naslov - "prost" tip podatka. Ko zna u kakvom složenom
obliku i u kakvoj organizacionoj hijerarhiji će on biti za koju godinu/deceniju. Čak i kada
bi se održala kompatibilnost i pređašnja funkcionalnost, pitanje je da li bi to bilo ono
što programer sada hoće, kad vidi šta sve taj Title Bar može. To dakle opet dovodi do
menjanja koda.

Pravljenje nekakvih apstraktih interfejsa spektakularnim kombinacijama Design Patterna
bi verovatno toliko opteretilo biblioteku i otežalo sam razvoj, da bi njena upotrebljivost
postala pod znakom pitanja.


Dok sam radio u jednoj firmi koja je razvijala jedan "veliki" projekat, javili su se slični
problemi. Jedino rešenje koje je vraćalo iz haosa je bila tzv. "komponentizacija":

1) revizija svih interfejsa svih postojećih podsistema (razdvajanje šta je čije)
2) reverzni inženjering sa Rational Rose u UML oblik
3) razvoj 100% koordinisan UML-om.

Dakle, kada smo znali "šta" hoćemo, nije bilo teško ni ono "kako ćemo", bez obzira na
neminovne izmene u kodu.

Kod tebe je još pozitivno to što ne moraš da praviš slične greške, nego odmah imaš
šansu da započneš kako treba.

Takođe dajem glas za wxWidgets.

(jednom, kada sam razgovarao o sličnoj dilemi sa kiklopom74 (a u njega imam beskonačno
poverenje kada je to u pitanju), odluka je takođe pala na wxWidgets, tako da...)

P.S.

Nemoj se uvrediti zbog ovih rečenica gore, jer se prosto "ospem" po telu kad mi neko
pomene kompatibilnost, prenosivost... U onoj firmi koju gore pomenuh, nismo lako uspeli
da "prenesemo" isti kod iste biblioteke klasa - kada smo stari kompajler zamenili novim,
a kamo li kada su bile uključene i druge okolnosti.

Baci oko na mono + monodevelop/#develop + WinForms

WinForms implementacija je prilično kompletna i nema nikakve bojazni za budućom revizijom API-ja :)

+ još ako ne koristiš OS-specific extenzije (P/Invoke na Win32 API na win odnosno Mono.Unix na *nix platformama) dobiješ i binary prenosivost aplikacije po OS-evima.

_{Da, ZNAM da nije C++, ali netko je predlagao i Pascal tako da..}

Razvio sam skoro jedan manji program na jeziku C++. Trebao je da rešava neke kombinatorne zavrzlame i ispostavilo se da sam morao dobro da se oznojim da bih dobio algoritam koji radi prihvatljivom brzinom (sada sam time sasvim zadovoljan). C# može biti čak i brži u odnosu na C++ STL u nekim stvarima, ali u nekim stvarima je drastično sporiji. Recimo, kada se koriste klasični C-ovski nizovi u C++ programima (ne vektori iz STL), nema provere u fazi izvršavanja da li su indeksi u dozvoljenim granicama, dok u C# programima tako nešto nije slučaj. C# programi su "pod kontrolom", i to u fazi izvršavanja, što oduzima izvesno procesorsko vreme.

Jednom rečju, C# i C++ nekako nisu za iste svrhe, odnosno nisu za poređenje, dok objektni paskal i C++ jesu. Naravno da treba koristiti C# tamo gde mu je mesto (a takvih "mesta" je sve više). No, ako to nije slučaj, to jest ako upravljani j4ezici otpadaju, onda otpada i C# kao jedan od njih.

Interesantno je mišljenje koje preovlađuje ovde da je normalno da složene biblioteke ne održavaju kompatibilnost sa prethodnim verzijama. Čak je i MFC backward kompatibilan bar 10-ak godina, a verujem da je slično i sa WxWidgets.

Ne, video igre ne funkcionišu tako. Jedina stvar koja se apstraktuje za GUI je iscrtavanje elemenata, sve ostalo je pogrešan dizajn.

Nisam samo imao u vidu direktne wrappere za GUI. Mislio sam i na neke druge velike biblioteke tipa:
http://www.indyproject.org/
... za sveopšti rad sa socketima. Bilo koja verzija tog Indy-ja je stabilna, ali se interfejsi stalno
grupišu i menjaju, pa je i kompatibilnost poprilično neizvesna. Doduše, izmene su trivijalne i rade
se za 5 min kada se uoči šta treba, ali opet nema 100% zagarantovane kompatibilnosti.


M$ je oduvek vukao pametne poteze i za to im svaka čast. Jedino se postavlja pitanje, da li je ta
kompatibilnost uslovljena "rokom trajanja". Naravno, pri tome ne mislim ništa loše:
10-15 god kompatibilnosti > prelazak na novu razvojnu platformu > ... pa opet, 10-15 god ... To
mi deluje sasvim prihvatljivo.

Nigde tu nisam pomenuo GUI, koji i nije kritičan u igrama. Kritično je iscrtavanje scena u toku igre. Tu igra mora da koristi odgovarajuću biblioteku koja zavisi i od modela grafičke kartice.

Slobodno koristi vektore jer ako koristis [] umesto .at(), push_back() ili insert() onda nema provere granica tako da su isto brzi kao C-ovski nizovi. A ako se bas plasis overhead-a kod vektora onda koristi boost::scoped_array gde nemas nikakav overhead a dobijes exception safe kod i ispravnu copy semantiku.

Pogledaj http://www.elitesecurity.org/t73781-Konstruktor-izuzetak tu je bila rasprava o tome.

Upravo tako. Jedino bih još dodao da treba obratiti pažnju na iteratore koji su u verziji koja dolazi sa VC++ 2005 "checked" čak i u Release modu (i što je najgore, smatraju da su mnogo pametni što su to uradili), pa ih treba "unchekirati" (sad bih dobio keca iz srpskog) eksplicitno: http://www.codeproject.com/scr...97449&id=14112#xx1697449xx

Ovo zaista nisam znao, hvala na vrednoj informaciji.

Nisi morao da pominješ GUI, to je tema ovog thread-a. Iscrtavanje scena je sve manje kritično u igrama, na primer
poslednja na kojoj sam radio apsolutno nema problem sa iscrtavanjem vec sa drugim stvarima - pričam o brzini.
A priča o "odgovarajućoj biblioteci koja zavisi od modela grafičke karte" nema smisla već godinama.
Čemu služi standardizacija i pravljenje API-ja koje si i sam pomenuo nego da program ne mora da misli o tome?
Ako te nešto zanima u vezi pravljenja igara, imaš GameDev forum pa pitaj...

Ovo je već daleko od teme. No, ta igra o kojoj pričaš da nema problema sa iscrtavanjem bi ih itekako imala da je povećan broj detalja koje treba iscrtati. Ne znam zašto onda nove igre traže vremenom sve jače i jače grafičke kartice. Ako upristiš grafiku na nešto što se vrtelo u Quake III, naravno da na savremenim mašinama neće biti nikakvih problema sa iscrtavanjem.

O ovome se nisam raspitivao na forumima, već u firmi koja se bavi time. Gde ti je standardan API koji će da se vrti na Windows, MacOS X i SONY PlayStation platformama? Dobro de, to nije runtime, može se za svaku platformu razviti native verzija (mada onda svaku izmenu na jednoj platformi treba "propratiti" izmenama na preostalim platformama i neće biti prevelikih garancija da će se igraponašati isto na svim platformama), ali standardan višeplatformski API za brzu 3D grafiku ne postoji. Pa, neće valjda 3D igre da se rade u Javi?

Mislim da Tosa i Nedljko misle na razlicite stvari.

Nedeljko, koliko sam razumeo - zeli da koristi osnovne windowing i event funkcije (tipa prozori, graficke kontrole i dispeceri poruka koje signaliziraju GUI dogadjaje) - koje su potrebne za osnovnu interakciju softvera sa korisnikom, i zeli da njegov kod ne bude zavistan od neke 3-party biblioteke ili OS-a, za ovo se cesto koristi apstrakcija.

Tosa, ako sam isto dobro razumeo - smatra da je apstrakcija losa - medjutim njegov use case je igrica, i na apstrakciju se misli u kontekstu primitivnih grafickih funkcija za 3D rendering? Jesam li u pravu?

Ako jesam - cini mi se da ste u pravu i jedan i drugi - u Tosinom slucaju bi apstrakcija predstavljala los dizajn, jer pre svega unosi dodatni, ne tako mali, overhead u grafickom endzinu, a ako je softver zahtevan to moze da bude vrlo lose (osim toga, razlike u filozofiji raznih 3D engine-a mogu biti tolike da je pitanje sta bi se dobilo apstrakcijom osim toga sto bi se problem premestio sa jednog mesta na drugo). Osim toga, postoje i standardizovane 3D biblioteke, pa je problem resen u startu.

U Nedeljkovom primeru apstrakcija i nije tako losa(*), jer je u pitanju samo mali broj funkcija koje nisu pozivane cesto - i odnose se samo na bazicni UI, pa je overhead zanemarljiv + filozofija tih UI endzina je manje-vise ista.



OpenGL? Ne mora se zahtevati binarna kompatibilnost (Java) - vec samo kompatibilnost na nivou izvornog koda, koju koliko znam OpenGL zadovoljava.

(*) Opet, treba postaviti pitanje koliko ce se cesto menjati UI provajder u tom projektu - ako je aplikacija kros-platformska gde se planira znacajno menjanje platformi koje su znacajno drugacije izmedju sebe - treba razmisliti o bazicnoj apstrakciji kako bi se ustedelo vreme menjanja opsteg koda. Medjutim, ako je cilj da se trci na 2-3 velike platforme (tipa: Windows, Linux/BSD) mislim da je daleko pametnije samo koristiti ono sto se nudi - par ljudi je vec predlozilo resenja.

_{[Ovu poruku je menjao Ivan Dimkovic dana 31.10.2006. u 10:15 GMT+1]}

Ono na šta sam ja mislio je high-level kod za baratanje porukama, prozorima i ostalim elementima, dok se na
različitim platformama implementira samo low level podrška za crtanje istih. Ta podrška ima svoju apstrakciju.
Problem je što nije moguće u svakoj situaciji zadržati tu lepu apstrakciju i onda dolazi hack'n'slash metod.
Grafički deo endžina je sve manji u odnosu na ostatak, igre postaju kompleksnije i sada ima mnogo više toga
da se uradi (zvuk, fizika, AI...). Konkretan slučaj o kome sam pričao je projekat za Sony PSP gde je GUI sistem
uzimao preko 40% procesorskog vremena. Adaptacijom sistema da bude "PSP compliant" zauzeće je palo na ~2%.

Poenta priče je malo otišla u stranu, ali dobar dizajn nije uvek dobro rešenje u smislu završavanja projekta na vreme;
pre svega zato što bi zahtevao dosta iteracija dok se ne bi došlo do "idealnog" dizajna. Ja sam lično protiv takvog
modela poslovanja, ali on donosi pare pa ima veći uticaj od mog mišljenja.

Što se tiče više-platformske grafičke biblioteke, ružni (lični stav) OpenGL manje-više radi stvar. Na mnogim game
platformama osim Xbox/Xenon postoji API koji je isti ili sličan OpenGL-u. Baš zbog te velike razlike između dve main
stream konzole se po pravilu radi apstrakcija renderinga koja je prilično high level, a sav ružni posao se odigrava
unutar "drajvera" (praćenje resursa i sl.).

Dakle, apstrakcija svakako jeste neophodna ali nekad je tu čisto forme radi :)

@Nedeljko
Igra nema problema sa crtanjem iz nekoliko razloga, navešću dva:
- svaki PSP je identičan po pitanju hardware-a
- pažljivo je isplanirano

Da li bi mogao da kažeš u kojoj firmi si se raspitivao? Ovo pitam više iz radoznalosti, posebno ako je firma domaća...

Ontopic: za GUI predlažem WxWindows ili QT

Toso,

Nemoj da se ljutiš. Ja svakako mislim da si upućeniji od mene u pravljenje video igara, ali mi tvoje konstatacije deluju malo čudno. Ako iscrtavanje nije kritično, zašto nove igre zahtevaju sve jače grafičke kartice? Imam drugara koji voli da se igra i on mi kaže da grafičku kartu mora da menja najmanje jedanput godišnje. Naravno, s vremena na vreme idu i zvučna kartica i procesor i memorija i matična ploča...

Ivane, Toso,

Zar postoji OpenGL za Sony PlayStation? Kako stoji stvar sa ostalim konzolama?

Imam samo još par pitanjca na ovoj temi.

1. Ako zanemarimo licencne razlike, šta smatrate (čisto tehnički) boljom bibliotekom Qt ili wxWidgets? U pitanju nisu nikakve igre, već application development. Za igre ne bih ni postavio pitanje onako kako je glasilo.
2. Gde mogu naći tačan tekst komercijalne licence za Qt? Zanima me je kupim za neke platforme i razvijem vlasnički softver sa njem za te platforme, da li (kasnije, nakon plasmana proizvoda za te platforme) mogu da dokupim Qt komercijalnu licencu za još neku platformu radi prebacivanja projekta i na njih, ili su mi "ruke vezane" tako da vo vjek i vjekov mogu da plasiram takav softver samo na onim platformama za koje sam na početku imao komercijalnu Qt licencu?

Još jednom svima puno hvala na pomoći i vrlo detaljnim i korisnim informacijama.

Nema ljutnje, čisto iznosim stav baziran na iskustvu. Igre na PC-u zahtevaju jače kartice da bi CPU bio
slobodniji. Takođe, zbog bedne arhiteture PC-a veoma je skupo iscrtati bilo šta. Ovde govorim o najobičnijem
DrawPrimitive pozivu, ili nekoj alternativi. Suština problema je da PC ne komunicira sa grafičkom kartom kao
što to radi konzola, pa je veoma teško praviti neko normalno poređenje.
Pored toga, mislim da je potreba za menjanjem hardware-a nametnuta i od strane proizvođača koji utrkivanjem
za najbolji naslov forsiraju granice PC-a i time teraju korisnike da unaprede mašine da bi se igrali kako treba.

OpenGL za PlayStation postoji, posebno za PS3. PSP, primera radi, ima specifičan API ali je i on veoma sličan
nekom primitivnom GL-u. Inače, postoji bolja alternativa od OpenGL-a za ps3.
Xbox i Xenon koriste hibridne verzije DirectX-a koje pružaju nešto veću fleksibilnost nego PC.

Iskreno ne znam dovoljno o razlikama između WxWindows-a i QT-a. Meni Wx deluje primamljivije, mada jedan
moj prijatelj kome izuzetno verujem hvali QT kao sjajno rešenje. Kapiram da oba rade posao korektno...
Jedna razlika je bitna, QT nije baš skroz besplatan koliko se sećam ?!

Qt se može koristiti pod GPL koja dozvoljava razvoj softvera za ličnu upotrebu, kao i razvoj softvera, koji će se plasirati takođe pod GPL. GPL licenca za Qt se ne plaća. Ukoliko želiš da razvijaš vlasnički softver, pošto ti GPL to nr omogućava (jer se tvoj kod linkuje sa Qt), možeš da kupiš komercijalnu Qt licencu koja košta oko 2-3 kiloevra po platformi.

[url] http://www.trolltech.com/produ...es/licensing/licensingoverview [/url]



To naravno mozes da uradis bez problema, ali ako bi razvijao i objavio(veoma bitno) program pod GPL licencom bez
obzira da li koristis besplatnu,GPL ili vlasnicku biblioteku pri tome, taj program nikada vise neces moci da plasiras pod
bilo kojom drugom licencom osim GPL-a,naravno to nema veze sa Qt-om nego je to ogranicenje koje GPL namece.
Ovde bi se samo ogradio da ja nisam pravnik tako da nisam 100 % siguran ali mislim da se to tako tumaci.



Pa najbolji nacin da to saznas je da probas i jedno i drugo i neko trece resenje i onda vidis sta ti vise odgovara.
Inace wxWidgets je objavljen pod L-GPL (Library General Public Licence) licencom sto znaci da mozes plasirati svoj program
kao proprietary,jedino ako promenis nesto u samoj wxWidgets biblioteci onda si duzan da te promene i objavis.
A ako kupis Qt komercijalnu licencu onda sa tom Qt bibliotekom mozes da radis sta god zelis bez ogranicenja.



Da, ali uz Qt4 ti dolazi i jedan program koji se zove - qt3to4 - koji sluzi za porting aplikacija i koji taj posao odlicno obavlja, sto pokazuje da je Trolltech jedna ozbiljna firma koja vodi racuna o svojim korisnicima, a to je bitna karakteristika kad se bira biblioteka koju zelis da koristis za vece projekte.

Treba malo razmisliti da li je bitnija kompatibilnost ili nesto drugo. S obzirom da svi vode racuna da ako krse kompa. na nivou izvornog koda to bude sto manjeg obima i tako nesto se ne desava u nekim kratkim vremenskim periodima.

Pod ovim drugo mislim na to da li ce ta biblioteka biti razvijana u buducnosti. Jer ako ne bude onda necete imati nikakvih problema sa kompatibilnoscu ali cete morati sami da prosirujete mogucnosti biblioteke.

Koliko sam primetio razvoj open source biblioteka se zasniva na entuzijazmu pojedinaca, finansijskoj podrsci nekih velikih kompanija ili komercijalnom uspehu same biblioteke (hahahha a jel ima jos nesto )

Problem je u tome sto kad je u pitanju entuzijazam razvoj je dosta usporen i zavisi od slobodnog vremena osoba koje su u takvom timu.

Recimo meni se svideo VCF medjutim kad sam video da nema neke osnovne mogucnosti i da linux port kaska pomislio sam OK bice.
Medjutim kad sam malo razmislio i video da osoba na kojoj lezi biblioteka radi jos neki projekat onda sam se zapitao kada ce biti.

Ukoliko nisi entuzijasta da se ukljucis i sam u razvoj GUI biblioteke onda je najbolje drzati se sledeceg principa:

da li zelis da pravis komercijani program ?
Ako je odgovor DA onda definitivno treba ici na komercijalna resenja.

Ako je odgovor NE onda treba videti da li ima resenja iza kojih stoje komercijalne organizacije ili komercijalni uspeh.

Ja trenutno vidim jedino resenje za viseplatformsko GUI programiranje u C++-u, a to je QT sve ostale GUI sam pogledao i svakoj nesto fali.
Inace QT za manju firmu moze da se dobije sa 65% popusta, a za programe koji su pod GPL-om je besplatno.

Ovo sto sam napisao se naravno odnosi na malo vece projekte, a ne na neke manje koje i ako dodje do zaustavljanja razvoja GUI bibl. ili neke nekompatibilnosti nije problem da se napise ponovo taj deo koda.

Ako je za program potrebno vise meseci rada onda je bolje osloniti se na komercijalna resenja.

Poz. Gosha.

Gresis. Ako je on autor celokupnog koda onda moze da menja licence kako mu se cefne.

Srki je u pravu. Kada je upotreba koda u pitanju, njegov vlasnik (a to je autor dok se vlasništvo ne promeni) ima pravo da radi sa njim šta hoće. Ostali nemaju pravo ništa da rade sa njim bez izričite dozvole (licence za upotrebu) vlasnika koda. Krajnjem korisniku je potrebna licenca, a ne vlasniku.

Njega licenca ninašta ne obavezuje, osim onoga čto je izričito napisao u licenci. U GPL se vlasnik obavezuje da na primaoca prenese sva prava i obaveze koje odatle slede. Jedno od prava je da može da dobije izvorni kod. Međutim, vlasnik može u bilo kom trenutku da prestane da izdaje kod, ili da počne da ga izdaje pod drugom licencom.

No, oni koji su kod već primili, i dalje mogu da ga koriste pod uslovima pod kojim su ga primili (što uključuje pravo na izmene, umnožavanje, redistribuciju, dobijanje izvornog koda itd.). Ne moraju čak ni da znaju da se u međuvremenu nešto promenilo. U tom slučaju, ako se vlasniku javi neki od korisnika koji je od njega primio kod bez sorsa, njemu je vlasnik dužan da ga isporuči. Naravno, svi koji su primili program pod nekom licencom i dalje mogu da ga koriste pod tim uslovima.