[ Nedeljko @ 26.08.2012. 13:58 ] @
Ovog meseca finsko preduzeće digia otkupilo je Qt. Najavljeno je da Qt neće kao do sada podržavati samo Windows, MacOS X, GNU/Linux (tačnije POSIX/X11), i boraniju od mobilnih sistema Symbian, Maemo, MeeGo, već i Android i iOS.

Embarcadero najavljuje podršku za Windows, MacOS X, Android i iOS, pri čemu baš dobro šiša sa cenama (digia šiša još žešće, ali ima i LGPLv2.1/GPLv3 licence) i nema GNU/Linux u ponudi. Videćemo šta će izaći iz ovoga.
[ ByteCode @ 31.08.2012. 13:40 ] @
Iskreno cisto sumnjam da ce tu QT nesto zaziveti kad je u pitanju android i iOS. pre svega razvojna okruzenja za Android i iOS su besplatna, i nisu ograniceni sa GPL licencnom. Opet sa druge strane, sve aplikacije za android koje ne koriste java viruelnu masinu su iskreno receno rizik da nece raditi na svim telefonima. Jeste da ARM ima monopol u ovom trenutku ali recimo ni intel nije bas za potcenjivanje.

http://www.ubergizmo.com/2012/...d-android-smartphone-revealed/

Kad si aplikaciju napisao za javu apsolutno te ne zanima koji je hardver ispod koji radi.
[ Goran Rakić @ 31.08.2012. 14:18 ] @
http://developer.android.com/guide/google/play/filters.html
http://developer.android.com/g.../publishing/multiple-apks.html

Ispravka: Izgleda da multiple APKs varijanta nije spremna za situaciju kada imamo native kod za različite arhitekture. Ljudi se dovijaju na razne načine.

Što se iPhone dvorišta tiče, oni već jesu native.

[Ovu poruku je menjao Goran Rakić dana 31.08.2012. u 15:32 GMT+1]
[ Nedeljko @ 31.08.2012. 15:29 ] @
ByteCode

Koliko znam, java ne radi na iOS-u ili nisam u pravu?

Drugo, odakle ti da je Qt ograničen GPL licencom? Nije uopšte. Besplatan je pod LGPLv2.1, koja dozvoljava dinamičko linkovanje sa vlasničkim modulima.
[ ByteCode @ 31.08.2012. 16:31 ] @
Citat:
Nedeljko: ByteCode

Koliko znam, java ne radi na iOS-u ili nisam u pravu?

Drugo, odakle ti da je Qt ograničen GPL licencom? Nije uopšte. Besplatan je pod LGPLv2.1, koja dozvoljava dinamičko linkovanje sa vlasničkim modulima.


U pravu si ne radi, tamo radi Objective-C, koji je skrndelj na svoj nacin kao i Qt. Ali ako nista drugo dolazi kao zvanican programski jezik i uvek sve najnovije stvari su dostupne kako za iphone tako i java u varijanti za android, sve ostalo kaska brze ili sporije. Za native varijantama. Realno koliko god to ruzno izgledalo ali na duze staze vise se isplati imati native aplikaciju za svaku platformu nego se muciti sa nekim cross platform resenjima.


A sta hoces da kazes sa tim dinamickim linkovanjem ? Da uz svaki android telefon dolazi i neka QT biblioteka onako tek da linkujes dinamicki po zelji ?
[ ByteCode @ 31.08.2012. 16:36 ] @
Citat:
Goran Rakić:
Ispravka: Izgleda da multiple APKs varijanta nije spremna za situaciju kada imamo native kod za različite arhitekture. Ljudi se dovijaju na razne načine.

Što se iPhone dvorišta tiče, oni već jesu native.

[Ovu poruku je menjao Goran Rakić dana 31.08.2012. u 15:32 GMT+1]


Kao sto rekoh ustedis na mostu platis na cupriji. Jedine varijante gde to prolazi jesu neki frameworkovi bazirani na javascriptu koji koriste iz java script sa samog operativnog sistema mobilnog telefona. Ali to nije dovoljno brzo, plus ako nesto podje kako ne treba, mozes samo da places jer neces videti stack trace gde i kako je pukao program.
[ Nedeljko @ 31.08.2012. 18:01 ] @
Citat:
ByteCode: A sta hoces da kazes sa tim dinamickim linkovanjem ? Da uz svaki android telefon dolazi i neka QT biblioteka onako tek da linkujes dinamicki po zelji?

Pa, ne znam, ti si prvi pominjao GPL ograničenost. Poenta je u tome šta si ti hteo s tim.

A po čemu je Qt skrndelj? Šta mu tačno zameraš?
[ Ivan Dimkovic @ 31.08.2012. 18:36 ] @
Citat:
Goran Rakić:
http://developer.android.com/guide/google/play/filters.html
http://developer.android.com/g.../publishing/multiple-apks.html

Ispravka: Izgleda da multiple APKs varijanta nije spremna za situaciju kada imamo native kod za različite arhitekture. Ljudi se dovijaju na razne načine.

Što se iPhone dvorišta tiče, oni već jesu native.


Ne znam da li sam u toku, ali koliko se secam iOS legalne aplikacije (za AppStore) ne mogu koristiti privatne dinamicke biblioteke - tako da, ako ljudi budu hteli da koriste LGPL verziju QT-a, to ce biti malo pipavo na iOS-u zbog toga sto ce morati biti staticki ulinkovan sa aplikacijom.
[ Nedeljko @ 31.08.2012. 20:39 ] @
A odakle ti da digia neće objaviti Qt za iOS pod LGPL sa nekim izuzetkom? Ako je već takva politika, sasvim je očekivano da se prilagodi okolnostima.
[ ByteCode @ 01.09.2012. 00:26 ] @
Citat:
Nedeljko:
Citat:
ByteCode: A sta hoces da kazes sa tim dinamickim linkovanjem ? Da uz svaki android telefon dolazi i neka QT biblioteka onako tek da linkujes dinamicki po zelji?

Pa, ne znam, ti si prvi pominjao GPL ograničenost. Poenta je u tome šta si ti hteo s tim.

A po čemu je Qt skrndelj? Šta mu tačno zameraš?


Pa zato sto to nije cisti C++, vec moras da stavljas neki QOBJECT direktivu kojom se tvoj kod modifikuje u neki C++, koji se posle kompajlira. Debagovanje toga je mala nocna mora.
[ Nedeljko @ 01.09.2012. 09:17 ] @
Smeta ti metaobjektni kompajler?

Pa, ne znam u čemu je problem sa debagovanjem. Nikada sa tim nisam imao problema. Ako sam jurio neki bag, uvek su razlozi bili sasvim druge vrste.
[ franticnick @ 01.09.2012. 11:43 ] @
Qt je dobar frejmwork sa zanimljivim konceptima kada je rad sa UI u pitanju. Medjutim tesko je poverovati da ce uspeti da izbori svoje mesto na Androidu ili iOS-u.

Posto su native resenja vec dovoljno dobra da bi ih Qt ugrozio, cross-platform je jedina karta na koju moze da igra. A tu su mesta vec zauzeta frejmvorcima tipa PhoneGap.

Nekako se uvek sete Qt-a kad je voz vec odavno prosao. Tako je bilo i sa nokijinim pokusajem da ozivi Symbian. Da su uzeli Qt na vreme (nekoliko godina ranije) mozda bi i bilo nekih sansi za Symbian.
[ Goran Rakić @ 01.09.2012. 12:00 ] @
PhoneGap ne daje native kod, Qt na iOS/Android treba porediti sa onim što radi Xamarin za C#.

Ne pratim detaljno, ali ne znači da će i QWidget biti u moblinoj ponudi, možda će se osloniti na native UI. Kako nema nikakvih dostupnih detalja, možemo samo da nagađamo. Lično nisam previše optimističan.

Ja uopšte nisam u mobile dev svetu tako da komentare uzimajte kritički.
[ franticnick @ 01.09.2012. 19:19 ] @
Citat:
Goran Rakić: PhoneGap ne daje native kod, Qt na iOS/Android treba porediti sa onim što radi Xamarin za C#.

Ne pratim detaljno, ali ne znači da će i QWidget biti u moblinoj ponudi, možda će se osloniti na native UI. Kako nema nikakvih dostupnih detalja, možemo samo da nagađamo. Lično nisam previše optimističan.

Ja uopšte nisam u mobile dev svetu tako da komentare uzimajte kritički.


Ma ima resenja koliko hoces, evo ovaj frejmwojk izbacuje native (izmedju ostalog): http://www.appcelerator.com/platform/titanium-sdk

Qt je jednostavno opet zakasnio na zurku ...
[ Nedeljko @ 01.09.2012. 20:25 ] @
OK, postoji li alat koji nudi prenosivost na nivou izvornog koda između sistema

Windws, MacOS X, GNU/Linux, Android, iOS?

Znači, najmanje jedan.
[ deerbeer @ 01.09.2012. 21:06 ] @
@ByteCode
Sta imas da debagujjes moc-ov kod koji ti generise?
Znas li uopste cemu sluzi Q_OBJECT makro ili pricas onako napamet?

A plus sto uopste nije obavezan da ga stavljas uvek u deklaraciju ..
[ Nedeljko @ 02.09.2012. 09:33 ] @
Obavezan si da ga stavljaš u deklaraciju klase ako ona treba da ima signale i/ili slotove i takva klasa mora da nasleđuje QObject. Pritom se Q_OBJECT makro ne nasleđuje. Mora ga imati svaka klasa koja treba da ima signale i/ili slotove, bez obzira na to da li je izvedena iz klase koja ga ima. Takođe, kada promeniš nešto po tom pitanju, moraš izvršiti qmake ponovo da bi se ponovo pokrenuo moc.

Nravno, ako klasa nema signale i/ili slotove, ne treba joj Q_OBJECT makro, bez obzira na to da li je izvedena iz QObject klase ili ne.

No, ni meni nije jasno na koje je probleme sa debagovanjem ByteCode mislio.
[ franticnick @ 02.09.2012. 10:45 ] @
Citat:
Nedeljko:
OK, postoji li alat koji nudi prenosivost na nivou izvornog koda između sistema

Windws, MacOS X, GNU/Linux, Android, iOS?

Znači, najmanje jedan.


Pa ni Qt to trenutno nije. Mozda jednog dana postane ali to i dalje ne garantuje nikakav uspeh. Prenosivost koda je samo jedna (doduse bitna) stavka u nizu stvari koje se gledaju kada se bira frejmwork za rad.

Qt nije od juce, postoji vec 20 godina i nesto ne primecujem da je zaziveo kao alat koga ljudi rado biraju kada je recimo OS X u pitanju.
[ Ivan Dimkovic @ 02.09.2012. 14:07 ] @
Citat:
Nedeljko:
A odakle ti da digia neće objaviti Qt za iOS pod LGPL sa nekim izuzetkom? Ako je već takva politika, sasvim je očekivano da se prilagodi okolnostima.


Nemam pojma odakle mi takva ideja, posto je ni nemam ;-) Samo sam naveo trenutnu situaciju.

Sta ce Digia da uradi, pojma nemam - ali ako zele da njihov framework bude primenjiv na iOS-u prakticno, morace biti staticki linkovan. Kao sto si rekao, to verovatno znaci da ce se prilagoditi okolnostima i da ce omoguciti staticko linkovanje bez LGPL posledica (obaveza) ako zele da ih neko ozbiljno koristi u ne-LGPL/GPL projektima.

Da li ce tako biti? Ko zna - videcemo. Ali za sada tako nije.

[ Nedeljko @ 02.09.2012. 22:48 ] @
Citat:
franticnick: Qt nije od juce, postoji vec 20 godina i nesto ne primecujem da je zaziveo kao alat koga ljudi rado biraju kada je recimo OS X u pitanju.

Iskreno, koga uopšte briga za MacOS X? Bitno je da je njegova upotreba u porastu na Windows platformi.
[ Nedeljko @ 03.09.2012. 22:15 ] @
Citat:
Ivan Dimkovic: Sta ce Digia da uradi, pojma nemam - ali ako zele da njihov framework bude primenjiv na iOS-u prakticno, morace biti staticki linkovan. Kao sto si rekao, to verovatno znaci da ce se prilagoditi okolnostima i da ce omoguciti staticko linkovanje bez LGPL posledica (obaveza) ako zele da ih neko ozbiljno koristi u ne-LGPL/GPL projektima.

Da ja pravim neki lib, steoleo bi me bojko za iSranja (iOS i MacOS X). Ako bih je stavio pod LGPL, uopšte me ne bi interesovalo da li će iko to da kompajlira za iSranje ili neće (ja ne bih kompajlirao) i kakve bi to imalo posledice na tim platformama, sve dok mi ne krši licencu.

No, u tom slučaju je gnjava odlično rešenje. Radi svuda gde treba: Windows (desktop + server, za telefone i tablete je nebitan), GNU/Linux, Android i voila!
[ franticnick @ 09.09.2012. 21:00 ] @
Citat:
Nedeljko: Iskreno, koga uopšte briga za MacOS X? Bitno je da je njegova upotreba u porastu na Windows platformi.


Pa i tu je pitanje da li je popularniji od WxWidgets na primer.
[ Nedeljko @ 09.09.2012. 22:13 ] @
Koristio sam wxWidgets i njegova prednost je bila upravo u tome što je Qt bio besplatan samo pod GPL, a otkako je pod LGPL, nisam siguran da wxWidgets može više da mu konkuriše. Ne znam odakle ti da je wxWidgets popularniji.
[ franticnick @ 09.09.2012. 22:23 ] @
Citat:
Nedeljko: Koristio sam wxWidgets i njegova prednost je bila upravo u tome što je Qt bio besplatan samo pod GPL, a otkako je pod LGPL, nisam siguran da wxWidgets može više da mu konkuriše. Ne znam odakle ti da je wxWidgets popularniji.


Ne tvrdim da jeste. Cisto neki subjektivni osecaj, mozda gresim.
[ Nedeljko @ 09.09.2012. 23:04 ] @
Ubeđen sam da grešiš.

Jedine su mu prednosti što ima manji hello world i što je besplatan za statičko povezivanje. Qt ima konkretnije prednosti.
[ ByteCode @ 17.09.2012. 11:14 ] @
Citat:
deerbeer: @ByteCode
Sta imas da debagujjes moc-ov kod koji ti generise?
Znas li uopste cemu sluzi Q_OBJECT makro ili pricas onako napamet?

A plus sto uopste nije obavezan da ga stavljas uvek u deklaraciju ..


Sluzi da bi povezao paradigmu singnala/slotova u C++ kod, problem je sto klase koje implementiras imaju i neke akcije koje jos treba da urade a ne cisto povezivanje signala i slotova. I kad se tvoj kod izmesa sa onime sto je moc kompajler uradio ne bude uvek cist kod.


Drugi problem na koji sam naisao koristeci te cross platform varijante je sledeci. Kad deployujes aplikaciju na appstore/google play .... sa svim tim resenjima ne vidis lepo stack trace gde je pukao program. Dok recimo native Android java aplikacija lepo prikaze stack trace i vidis gde je pukao program i zasto.

Drugi problem koji ti cross platform frameworci imaju jeste da su wall garden okruzenja, znaci sve je divno i krasno dokle god si unutar tog okruzenja, a recimo treba da ukljucis neku 3rd party biblioteku npr ads, ili mozda biblioteku za prepoznavanje barcode-a e tu ces da rodis mecku da to odradis kako treba.
[ dejanet @ 17.09.2012. 12:08 ] @
Citat:
ByteCode: Drugi problem koji ti cross platform frameworci imaju jeste da su wall garden okruzenja, znaci sve je divno i krasno dokle god si unutar tog okruzenja, a recimo treba da ukljucis neku 3rd party biblioteku npr ads, ili mozda biblioteku za prepoznavanje barcode-a e tu ces da rodis mecku da to odradis kako treba.

Yep, uvek je tako.
Mislim da je npr. za ios, Xcode bolje resenje.
[ deerbeer @ 17.09.2012. 12:27 ] @
Citat:

Sluzi da bi povezao paradigmu singnala/slotova u C++ kod, problem je sto klase koje implementiras imaju i neke akcije koje jos treba da urade a ne cisto povezivanje signala i slotova. I kad se tvoj kod izmesa sa onime sto je moc kompajler uradio ne bude uvek cist kod.

Ne kapiram sta si hteo da kazes sa ovim. moc -ov kod je poprilicno transparentan za tebe i to sve radi lepo i ne mesa se sa tvojim kodom ..
Jel problem je sto za te napisane klase sa ugradjenim slotovima neces moci da koristis negde drugde van Qt-a ?
Ako ti se bas ne svidja Q_OBJECT makro inkludujes boost -ov signal-slot lib - http://www.boost.org/doc/libs/1_51_0/doc/html/signals.html i eto ti resenja koje ce ti raditi i na drugom cross platform framework-u.

Opet napominjem da se klase mogu pisati i bez toga ukoliko joj nije potreban signal/slot mehanizam sto ce reci imas poprilicno dovoljno slobode za jedan cross platform framework .

Citat:

Drugi problem koji ti cross platform frameworci imaju jeste da su wall garden okruzenja, znaci sve je divno i krasno dokle god si unutar tog okruzenja, a recimo treba da ukljucis neku 3rd party biblioteku npr ads, ili mozda biblioteku za prepoznavanje barcode-a e tu ces da rodis mecku da to odradis kako treba.

U Qt mozes da ulinkujes i kompajliras bilo sta iz open source sveta sto je posteno odradjeno (c, c++ kod ) i to se radi na prilicno standardan nacin .
Ukoliko imas problem pre ce biti da je do biblioteke nego do frejmvorka ..

[ ByteCode @ 17.09.2012. 13:52 ] @
Citat:
deerbeer: U Qt mozes da ulinkujes i kompajliras bilo sta iz open source sveta sto je posteno odradjeno (c, c++ kod ) i to se radi na prilicno standardan nacin .
Ukoliko imas problem pre ce biti da je do biblioteke nego do frejmvorka ..



Kao sto rekoh sve je to lepo u teoriji, u praksi recimo imas biblioteku koja je specificna za android, npr google admob, posebnu za iphone posebnu za wp7, sve su kao identicne ali api se ipak malko razlikuje za svaku platformu. Ili da idemo malko dalje pa recimo da uzmes neku biblioteku za android ili iOS koja se igra malko sa senzorima tipa akkceleracija ili gps ili kamera npr.

Druga stvar te cross platform varijante generalno kaskaju poslednjim featureima koji se pojavljuju uz nove verzije operativnih sistema. Negde dobijes malo tipa cross platform, razvijas kao kod jedan jedini put a posle toga za bilo sta komplikovanije imas problema.

Pa cak i za android ako se ne izvrsava u okviru JVM-a opet si u problemu, jer pored arm-ovih procesora u igru ulazi i intel polako, tako da to "native" nije nesto sto bi ja gledao u danasnje vreme kao veliki plus.
[ Nedeljko @ 18.09.2012. 06:02 ] @
Citat:
ByteCode: Sluzi da bi povezao paradigmu singnala/slotova u C++ kod, problem je sto klase koje implementiras imaju i neke akcije koje jos treba da urade a ne cisto povezivanje signala i slotova. I kad se tvoj kod izmesa sa onime sto je moc kompajler uradio ne bude uvek cist kod.

Biće da ću ja da rodim mečku dok ne shvatim šta tu nije čisto. Da, mnogi Qt-ovi makroi kao Q_OBJECT ne znače ništa C++ kompajleru, nego moc kompajleru koji generiše neki C++ kod koji će C++ kompajler da prevede. Pa? Gde je tu problem sa debagovanjem?
Citat:
ByteCode: Drugi problem na koji sam naisao koristeci te cross platform varijante je sledeci. Kad deployujes aplikaciju na appstore/google play .... sa svim tim resenjima ne vidis lepo stack trace gde je pukao program. Dok recimo native Android java aplikacija lepo prikaze stack trace i vidis gde je pukao program i zasto.

Ne znam za mobilni svet, ali kada je GNU/Linux u pitanju, ako si isporučio program sa debug informacijama i korisnik je uključio generisanje core fajla u slučaju pucanja programa, sve ćeš lepo da vidiš.
Citat:
ByteCode: Drugi problem koji ti cross platform frameworci imaju jeste da su wall garden okruzenja, znaci sve je divno i krasno dokle god si unutar tog okruzenja, a recimo treba da ukljucis neku 3rd party biblioteku npr ads, ili mozda biblioteku za prepoznavanje barcode-a e tu ces da rodis mecku da to odradis kako treba.

Za ovo prvi put čujem. Čekaj, hoćeš da kažeš da ako okruženje nije višeplatformsko da je situacija bolja?
Citat:
ByteCode: Kao sto rekoh sve je to lepo u teoriji, u praksi recimo imas biblioteku koja je specificna za android, npr google admob, posebnu za iphone posebnu za wp7, sve su kao identicne ali api se ipak malko razlikuje za svaku platformu. Ili da idemo malko dalje pa recimo da uzmes neku biblioteku za android ili iOS koja se igra malko sa senzorima tipa akkceleracija ili gps ili kamera npr.

Pa, naravno da je teže raditi za više platformi nego za jednu. E, sad, šta je teže, korišćenje višeplatformskog alata ili potpuno različitih jezika, proceni sam.
[ ByteCode @ 19.09.2012. 11:48 ] @
Citat:
Nedeljko: Biće da ću ja da rodim mečku dok ne shvatim šta tu nije čisto. Da, mnogi Qt-ovi makroi kao Q_OBJECT ne znače ništa C++ kompajleru, nego moc kompajleru koji generiše neki C++ kod koji će C++ kompajler da prevede. Pa? Gde je tu problem sa debagovanjem?


Problem je kad se u jednoj klasi izmesa moc generisan kod sa onim tvojim.

Citat:
Nedeljko:Ne znam za mobilni svet, ali kada je GNU/Linux u pitanju, ako si isporučio program sa debug informacijama i korisnik je uključio generisanje core fajla u slučaju pucanja programa, sve ćeš lepo da vidiš.


A koji je naslov teme ? Ne zanima me kako je da desktop sistemima tipa windows/linux/mac/solaris ... ovde si ogranicen time sta ti provajter tipa google ili apple pruzaju nazad od informacija.

Citat:
NedeljkoZa ovo prvi put čujem. Čekaj, hoćeš da kažeš da ako okruženje nije višeplatformsko da je situacija bolja?


Bolja je i tekako je bolja, recimo imas neku biblioteku za oglase, oni su napravili native biblioteke za svaki od mobilnih platvormi i pokazani su primeri kako se konektujes na iste, gde pri tom biblioteke se delimicno razlikuju od svake platforme ponaosob. I tu si u problemu jer nekim cross platfom varijantom ne mozes da ih ukljucis. Pa na kraju vise stete nego koristi. Tj treba da se dovijas pa da pravis brancheve pa da nekako inkludujes android biblioteku za android build, ios biblioteku za iphone/ipad, i slicne fore. tako da na kraju zavrsices sa "istim" kodom ali koji ce se razlikovati od platforme do platforme, kao sto rekoh ako ne platis na mostu platices na cupriji.
[ Nedeljko @ 19.09.2012. 17:21 ] @
U kojoj se to klasi izmeša moc kod sa mojim? moc kod su isključivo cpp fajlovi, a ne zaglavlja, nigde taj kod ne uključuješ. Taj kod je tamo negde i ti ga i ne vidiš.