> Hát nem esz a sárga irigység :) hogy diplomatikusan fogalmazzak :)
Én azért büszke vagyok, hogy a csapat egzotikus technológiákra is tud tervezni, nem az van hogy ismerjük a WIn32API-t vagy valamelyik webes UI készletet és csók
A WinMo-n mi is leokádtuk magunkat meg a fejlesztők is, de ha egy WinMo-only készülékre kell tervezned akkor evvan.
A problémám az, hogy mi a tervezőcég vagyunk: nekünk adsz egy technológiai stack-et, az lehet az általatok tervezett UbiAPI, az lehet a XAML, az lehet a LogMeIn-féle SanyiUI (a saját kis belső framework-jük, arra is terveztem), de nem sok éles kódot fogsz tőlünk látni, pszeudokódban írt speciket fogsz kapni, amik kihasználják az adott platform képességeit / kikerülgetik a hátrányait (embeddednél szokott lenni).
Egy menedzsernek viszont elsősorban arra kell gondolnia, hogy a kódnak olyannak kell lennie, hogy ha a release party-ról hazafele menet elüti egy kisbusz az összes fejlesztőt aki összerakta, akkor a piacról tudjon hozzáértő embereket szerezni, akik a kisebb-nagyobb változtatásokat beleerőszakolják.
A JavaScript egy elég elterjedt rendszer ehhez, tetszőleges script kiddie bele tud nyúlni, nyilván olyan minőségben is. Nyilván nem elég gyors, ezért van az hogy a mobilos dolgokat rendszerint Androidra írjuk.
Nincs bajom magával a Qt-val, sőt, fejlesztettem GTK-ban és Qt-ban is, a Qt-nak nagyságrendekkel érettebb, szebb API-ja van. A bajom ott van, hogy ha körbe kéne kérdeznem, hogy "helló, van egy QML-alapú alkalmazásunk, elütötték a programozókat és kéne valaki aki hozzáír egy modult meg átír másik kettőt", előbb kapnék árajánlatot az egész átírására JS-ben, XAML-ben vagy Android alapokon, minthogy találjak ezekhez értő fejlesztőt.
Ami persze részint önmagát generáló folyamat, a Boot to Qt viszont jó ötlet, ha legközelebb nagyon embedded eszközre kell dolgoznunk akkor gondolok rá (mert a sebesség vs készülék ára vs kültéri strapabírás ettől még érv)