QT5.2.0 fuer Android

> Ich würde Dir dankbar sein, wenn du einen Wiki Artikel daraus machst,

Tut mir leid, aber ich gehoere zur Generation Emacs. :-)

BTW: Im Vergleich zu Necessitas merkt man deutlich das es mit Android/Qt 
vorran geht. Hier und da hakelt es noch etwas, aber so im grossen und 
ganzen finde ich es jetzt ganz nett.

Oh..und wenn man vorher viel mit Eclipse rumgemacht hat dann ist der 
QTcreator sicher etwas gewoehnungbeduerftig, aber man hat die ganze Zeit 
ein Laecheln auf dem Lippen weil er VIEL schneller ist.

Olaf

Olaf schrieb:
>> Ich würde Dir dankbar sein, wenn du einen Wiki Artikel daraus
> machst,
>
> Tut mir leid, aber ich gehoere zur Generation Emacs. :-)
>
> BTW: Im Vergleich zu Necessitas merkt man deutlich das es mit Android/Qt
> vorran geht. Hier und da hakelt es noch etwas, aber so im grossen und
> ganzen finde ich es jetzt ganz nett.

Was stört dich denn an Necessitas? Ich nutze es auch, und es läuft 
eigentlich sehr gut. Die von dir angesprochenen Installations-Eskapaden 
habe ich damit auch nicht gehabt.

> Oh..und wenn man vorher viel mit Eclipse rumgemacht hat dann ist der
> QTcreator sicher etwas gewoehnungbeduerftig, aber man hat die ganze Zeit
> ein Laecheln auf dem Lippen weil er VIEL schneller ist.

Ich nutze vim, da ich den auch für alles andere verwende. Der ist mir 
schnell genug. ;-)

> Was stört dich denn an Necessitas?

Garnichts. Ich fand es super. Aber man merkt das Qt5.2 eine 
Weiterentwicklung ist. Die Ecken und Kanten sind jetzt besser 
gepolstert. :-)

> Die von dir angesprochenen Installations-Eskapaden
> habe ich damit auch nicht gehabt.

Ich auch nicht. Und wirst du mit einer anderen Distribution vielleicht 
auch nicht haben wenn es zufaellig die ist mit der Qt entwickelt wurde.


> Ich übrigens auch, aber warum sollte das ein Hinderungsgrund
> für einen Wiki-Artikel sein?

Ich habe es noch nicht verstanden wie ich hier bei mir auf meinem 
Rechner einen Artikel schreiben soll und zwar so das ich hier bei mir 
alles machen kann und es dann spaeter komplett irgendwo hochlade. Ich 
moechte ueber das was ich schreibe selber die Kontrolle behalten bis es 
fertig ist. Ich moechte z.B auch ueber einen laengeren Zeitraum an einem 
Text basteln koennen ohne das jemand anderes den zwischendurch sehen 
oder gar bearbeiten kann.
Sollte das moeglich sein, dann schreib doch einen Wiki-Artikel der es 
mir erklaert. :-)

Allerdings denke ich sowieso das das was ich hier beschrieben habe eine 
ganz gute Hilfe fuer jemanden sein kann der zufaellig auf eines der 
Probleme stoesst das ich auch hatte, wegen der starken Diversifikationen 
der einzelnen Linuxsysteme aber kaum von so grosser Bedeutung ist das 
man da ernsthaft ein paper schreiben sollte.

BTW: Ich musste meine Aenderung an der libz wieder zuruecknehmen.

[root@criseis lib]# l libz*
lrwxrwxrwx. 1 root root    13 28. Dez 22:41 libz.so.1 -> libz.so.1.2.3
-rwxr-xr-x. 1 root root 76880 10. Dez 2011  libz.so.1.2.3
-rwxr-xr-x. 1 root root 90964 30. Nov 14:28 libz.so.1.2.8

Einige wenige Programme moegen die neue libz naemlich nicht und werfen 
dann errors in /var/log/messages:
segfault at 0 ip 006ff451 sp bfc091bc error 4 in 
libc-2.12.so[67f000+190000]

Eines dieser Programme ist gdm. Das ist dann der Grund warum ihr am 
naechsten Tag beim booten vor verschlossener Tuer steht. :-)

Leider laeuft Qt5.2 mit der alten Version zweifelhaft. Die Compilierung 
laeuft zwar ohne Fehler durch, aber man bekommt das hier in den Issues:

/lib/libz.so.1: no version information availailable (required by 
/home/olaf/sources/Android/Qt5.2.0/android-ndk-r8e/toolchain/arm-linux-a 
ndroideabi-4.7/prebuilt/linux-x86/bin/../lib/gcc/arm-linux/androideabi/4 
.7/../../../../arm-linux/andoideabi/bin/ld)

Man kann das also vielleicht ignorieren, was fuer sich genommen ja auch 
schonmal eine interessante Information ist wenn man ein solches System 
bei sich installiert. Ich hab im uebrigen auch mal probiert es bei mir 
mit dem android-ndk-r7c ans laufen zu bekommen, aber es nicht geschafft. 
(weiss den Grund nicht mehr) Von daher koennte das Problem auch andere 
Leute betreffen wenn ihr System nicht auf gcc4.7 laeuft. Leider wird 
einem aber auch klar wieso SF/Redhat noch nicht umgestiegen sind. Das 
Problem betrifft naemlich nicht nur gdm. (da wird es nur zuerst 
deutlich) vermutlich muesste man sein halbes System neu compilieren.

Mein system basiert noch darauf:
[olaf] ~: gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)



Olaf

> Was stört dich denn an Necessitas?

Was ich nochmal vertiefen sollte...

Der Grund warum ich modernisiert habe ist die Hoffnung auf neue 
Featuere, insbesondere der Integration von Bluetooth und der seriellen 
Libary.

Eine noch offene Frage ist dann wie einfach es wird mit meinen Xperia 
Z-Tablett ueber ein BTM222 auf externe Hardware zuzugreifen.

Olaf

Etwas off-topic, aber passt vielleicht hier gut rein:

Man kann verschiedene Versionen von folgender Webseite laden:
http://qt-project.org/downloads

Wenn man QT 5.2.0 Variante x bereits installiert hat,
kann man dann QT 5.2.0 Variante y einfach dazu installieren?

Ich habe z.B. bereits QT 5.2.0 (64 Bit, Windows) installiert,
um Windows-Applikationen damit zu entwickeln.
Kann ich mit jetzt einfach QT 5.2.0 for Android installieren
oder macht das Probleme?

Eine kleine Steigerung meiner Frage:
QT 5.2.0 für Windows (unter Windows) ist 64 Bit,
QT 5.2.0 für Android (unter Windows) gibt es scheinbar nur als 32 Bit.

Kann man damit eigentlich auch Cross-Compilen?
Also unter Windows ein Linux-Binary erzeugen?
Oder unter Linux ein Windows-Binary erzeugen?
Ist ebenso auch ein Mac-Binary unter Windows erzeugbar?

> Kann man damit eigentlich auch Cross-Compilen?
> Also unter Windows ein Linux-Binary erzeugen?
> Oder unter Linux ein Windows-Binary erzeugen?

Ich habe keine Ahnung von Windows, aber grundsaetzlich sollte es 
moeglich sein da ja die Androidcompiler auch alles Crosscompiler sind. 
Man muesste sich dann halt einfach noch einen passenden Crosscompiler 
uebersetzen und da einbinden. Es ist jedenfalls sehr einfach moeglich 
ein Android-QT programm mit einem anderen Kit zu uebersetzen und dann 
unter Linux laufen zu lassen.


BTW: Noch ein Hinweiss der mir leider etwas verspaetet aufgefallen ist. 
Man sollte wohl zuerst mal das Kleingedruckte lesen, seufz. Die neue 
QT5.2 unterstuetzt grundsaetzlich so Sachen wie Bluetooth und die Libary 
zu Abstraktion der seriellen Schnittstelle, aber sie tut dies noch nicht 
unter Android. Damit ist Qt5.2 ziemlich unbrauchbar solange man nicht 
libusb auf sein Zielsystem portiert und native anspricht.

Olaf

> eine build.xml existiert und evt. hier hochladen?

Klar.
Nicht das ich jetzt wuesste wer die genau wann im Build-Prozess erzeugt, 
aber es wundert mich das die bei dir nicht erzeugt wird. Ich denke doch 
das mal jemand einen Build ausprobiert hat bevor sie die Windowsversion 
released haben.

> Gibt es für Linux/Windows von QT eigentlich keine
> How-To, wie man das ganze installiert,
> was man dazu alles braucht, usw.?

Das habe ich ja fuer Linux im Prinzip beschrieben. Allerdings ist sowas 
bei Linux mit Vorsicht zu geniessen weil sich die Distributionen 
unterscheiden. Es gibt bestimmt auch Leute wo es einfach so 
funktioniert.

Wenn alles gut laeuft muss man nur das QT-Script starten, danach SDK/NDK 
darin auspacken und ist fertig.

Aber es ist schon noch wichtig das man versteht was unter der Motorhaube 
passiert. Der ganze Buildprozess hat noch so einige Macken.

> Was allerdings an Java so dermaßen furchtbar sein soll, verstehe
> ich nicht.

Alles was ich bisher gesehen habe das mit Java gemacht war, war total 
lahm. Auf einem PC nervt das nur, auf einem tragbaren Device kostet das 
Akkulaufzeit. Ein Sharp Zaurus (400Mhz) mit QTopia/QTembedded fuehlt 
sich meistens schneller an als mein Handy mit xGhz und 4xCPU.

Olaf

> Ist das etwas, was man einstellen kann
> (z.B. dpi oder automatische Anpassung)
> oder muss man sich in der App selbst darum kümmern?

Darauf bin ich auch schon gestossen. Grundsaetzlich kannst du ja die 
Schriftgroesse im Creator auch einstellen und es damit hinbekommen.
Allerdings ist das Deviceabhaengig und damit natuerlich bloed.

Ich denke daher auch das dies entweder ein Programmierfehler oder ein 
Designfehler ist.

Olaf

> Wenn man ein Layout ergänzt (ich hab die ganzen UI-Elemente in ein
> gridLayout kopiert), dann sind die Buttons/Texte richtig.

Interessant, ich war eigentlich der Meinung auch ein Layout erzeugt zu 
haben. Aber ich hab auch irgendwo gelesen das da noch etwas buggy sein 
soll.
Muss ich wohl nochmal reinschauen.

Jetzt koennte man im Prinzip ja mit dem System arbeiten, tja wenn man 
halt auch mal Hardware ansprechen koennte. Schliesslich ist das ja ein 
Hardwareforum. Aber so wie ich das sehe gibt es da nur zwei 
Moeglichkeiten. Entweder warten bis es irgendwann in QT integriert ist, 
oder die libusb integrieren. Letzeres aber vermutlich mit dem Nachteil 
das ein Programm immer root-Priviligen braucht. Oder uebersehe ich da 
etwas?

Olaf

Der grafische Widget Designer ist nur für "normale" PC Bildschirme mit 
ca 100dpi Auflösing gedacht. Für Android Handies eignet sich der Editor 
kaum.

Bei QML soll es besser sein, ich hab QML aber noch nie verwendet.

Ich bin inzwischen dazu über gegangen, die Widgets durch C++ Quellcode 
zu erstellen. Dann erscheinen fast alle Sache automatisch 
zufriedenstellend, man muss nichtmal Höhe und Breite angeben. Layouts 
sind auf jeden Fall Pflicht, damit sich die Fenster an unterschiedliche 
Bildschirmghrößen anpassen.

Icons und Bilder skaliere ich relativ zur Schriftgröße (analog zur 
Einheit "em" in Webseiten).

Inzwischen habe ich auch Bluetooth hinbekommen: 
http://stefanfrings.de/android_qt/index.html

Wegen der Performance:
- Qt Programme starten viel langsamer, als Java Programme. Logisch, denn 
die Java Libraries werden ja schon vorher beim Booten des Gerätes 
geladen.
- Qt Programme belegen viel mehr RAM, weil sie Qt Libraries nachladen 
müssen.
- Ich gehe davon aus, dass C/C++ Programme unter Android viel schneller 
laufen, weil die Java VM nicht sonderlich ausgefuchst ist. Die Java VM 
von Oracle ist gefühlt 5x schneller, als die Dalvik VM in Android.
- Allerdings werden die meisten Programme eher von I/O ausgebremst, so 
dass die Rechenleistung weit weniger wichtig ist, als oft behauptet.

Ich bevorzuge Qt, weil meine Programme damit auch auf dem Desktop laufen 
können.