I have written a library to get JPG files from a webserver continously. It worked fine with Qt 4.6.3 but with the new Qt 4.7.0 I have get the following error for every frame:


Reading ras files from sequential devices not supported


The workaround is the following:

Turn off the automatic format detection, and set the file format explititly:


imageReader->setAutoDetectImageFormat(false);
imageReader->setFormat("JPG";


And no more warnings

I have stucked several times with touchscreens and Qt.
My problem's main reason is that I compiled the Qt and tslib outside the openembedded, because I did not liked the Openebmedded's Qt building method. (Build Qt twice once cross compiled, once for the host.)

I have stucked several times in the following situation:
ts_calibrate calibrates, and ts_test works fine, but my Qt app cursor's moves inverse, or it too sensitive or whatever.

Well it seems to be that the various tslibs do not like another,
and their configuration files are not interchangable. And the best one: Qt app likes to work only with the tslib with what it had been compiled.

So if you ran into the similar problem:

Clean up all your existing tslib stuff:

rm -rf /usr/lib/ts
rm -rf /usr/lib/libts*
rm -rf /usr/bin/ts_*


And place your own compiled tslib's binaries, and plugins there.

After then set the following enviroment variables properly of coures:


export TSLIB_TSEVENTTYPE=INPUT
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/touchscreen0
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/local/tslib/lib/
export LD_LIBRARY_PATH=/usr/local/tslib/lib


Run ts_calibrate

And finally run your Qt app with -qws option.

Van pár feladat aminek a végrehajtását szeretem elkerülni a számítógépemen. Ilyen például a Qt fordítás. Baromi sokáig tart, és végig üvegeli a a gépet. A gentoos "compile 5 hours to run 5 ns faster" filozófia pedig eddig még nem érintette meg a lelkemet.

Beágyazott szuttyok esetén nem mindig adatik meg az a lehetőség, hogy bináris csomagot használjon az ember. Így volt ez most is, amikor egy Friendlyarmos panelre kellett Qt-t varázsolnom. Az openembedded sajnos csak úgy képes Qt-t fordítani, ha az először lefordítja az x86-osat, majd az embeddedet. Ezt el kívántam kerülni, ezért 2 napig reszeltem a bitbake és az mkspec fájlokat, de végül feladtam.
Képtelen volt desktopon futó qmaket összehozni, így végül ezt a leírást használtam:

http://billforums.station51.net/viewtop ... p;p=44#p44

Illetve megspékeltem az opciókat ezekkel:


./configure -embedded arm -xplatform qws/linux-arm-g++ -prefix /usr/local/Qt -little-endian -no-qt3support -opensource -no-accessibility -no-webkit -no-script -no-javascript-jit -no-scripttools -nomake examples -nomake demos -nomake docs -nomake translations -qt-mouse-tslib -DQT_KEYPAD_NAVIGATION -reduce-relocations -fast


A fordítás egy Intel T7400 C2D-n kevesebb mint 20 perc alatt lezajott.

Öröm van a köbön.

A szituáció:

Adott a QGraphicsView aminek a mousePress, mouseRelease, és mouseMove memberjeit overrideolom.
A pressEventben létrehozok egy RockItemet, ami mozgatható, és egy QPolygont rajzol. A moveEventben, amennyiben rajzolás van ehhez az adott RockItem polygonjához fűzöm az event->pos() pontot. A releaseben pedig befejezem az adott elemet (innentől polygont nem polylinet paintel.

A probléma:
Az így letett elemek nem mozgathatóak. Amennyiben a konstruktorban hozunk létre ilyeneke pld. egy QSettingsből, akkor lehet őket mozgatni. Amennyiben mozgatjuk a legutoljára rajzolt RockItemen kívül valamelyik elemet, úgy hogy a sceneRect megváltozzon a friss elem is mozgathatóvá válik. Ha a releaseEventben a setSceneRect()-et hívok nem történik módosulás. A scene frissítésével ugyanez a helyzet.

A megoldás:
RTFM, avagy barátkozás a Qt doksival:
http://doc.trolltech.com/4.6/qgraphicss ... ethod-prop
Akinek ez nem megy annak marad a megoldás mint nekem a googlecodesearch

1) Amikor a QTimerek szórakoznak.

Történt a marsjáróvezérlő programmal, hogy elkezdett néha lefagyni a navigáció. Némi debug után arra jutottam, hogy bizony néhány QTimer nem emittál timeOut() szignált. Hosszas szívózás után rájöttem a dolog nyitjára. A program több saját készítésű könyvtárat használ. (Képletöltő, képfeldolgozó, rovervezérlő). Ez sok szíváshoz vezet, azonban symlinkek nélkül így sikerült megoldanom a földbázis és a marsbázis közös komponenseinek kezelését. A rovervezérlő könyvtárban elkövettem azt az hibát, hogy nem QTimert használtam, hanem a QObject startTimer() és timerEvent(QTimerEvent *event) metódusait az időzítésre. Ez önnmagában nem hiba, sőt átláthatóbb kódot eredményezhet bizonyos esetekben. Azonban a killTimer(int timerid) függvényt csak ésszel szabad használni. A hiba pontos okát nem tudtam feltárni, de annyi bizonyos:

A) killTimer() -t nem hívunk meg nem megfelelően inicializált értékkel

B) killTimer() -t egy timerId-vel csak egyszer hívunk meg.

2) Amikor a windowsos build elbukik mert nem találja a LIBS+= -lsettings -L=../../libs/bin után a settings libet, holott az ott van.

A QtCreator újonnan szeret létrehozni egy shadow build könyvtárat, amiben a fordítás egy desktop nevű könyvtárban történik. Így nem
-L=../../libs/bin -el kell linkelni, hanem egyel fentebbi könyvtárba.


3) Miután sikerrel lefordítottuk a stuffot az alkamazás
QWidget: Must construct a QApplication before a QPaintDevice hibával elszáll.

Az alkalmazásunk és a libjeink azonos módban legyenek fordítva (debug vagy release)

És hogy legyen valami színes is a végére, ami unalmas, és semmitmondó mivel itthonról írok:

A marsbázis fut fostalicska OS-en is némi hekkelés árán.

BTW:
Még : 14 nap van hátra.
Az pontosan annyi mint: 336 óra.
Azaz 20160 perc