Archiwa tagu: QT5

JS / Ecmascript w QtQuick.

Wysłany by

Od lat krążę wokół tematu ale trafiłem ostatnio na fajną książkę o ES6 (Learning JS z O’Reilly’ego) i sporo rzeczy w tej wersji standardu mi się podoba. Na tyle to fajne, że postanowiłem trochę poeksperymentować. Nieprzypadkowo akurat z ES6, bo Qt5.12 ma obsługiwać Ecmascript w wersji 6-tej. Fajne toto i szybkie, a z Qt nie musi być przywiązane do backendu, czy przeglądarki:

import QtQuick 2.11
import QtQuick.Window 2.11

Window {
    visible: true
    width: 640
    height: 480
    title: qsTr("JS fun 2")

    Rectangle {
        id: rect
        width: parent.width-100; height: parent.height-100
        border.color: 'red'
        border.width: 10
        anchors.centerIn: parent

        function get_fibo(n) {
            function fibo(n) {
                if (n < 1)
                    return 0;
                if (n <= 2)
                    return 1;
               return fibo(n-1) + fibo(n-2);
            }
            var ret = '';
            for (var i=0; i<n; i++)
                ret += fibo(i) + ' ';
            return ret;
        }

        Text {
            text: parent.get_fibo(15)
            anchors.centerIn: parent
        }
    }
}
fib_js
JS w QML nie wymaga magicznych sztuczek. Można go sobie ot tak używać, jak widać w powyższym przykładzie.
Nieco dziwny jest scoping w QML, bo jeśli obiekt który wywołujemy znajduje się w obiekcie nadrzędnym, trzeba się do niego dostać np. przez parent albo id. Jeśli nie, trzeba obiekt, np. funkcję wrzucić do obiektu najgłówniejszego ;). Może ma to jakieś głębsze uzasadnienie, a może to się zmieni w implementacji ES6.

Wywoływanie slotu w C++ z QML.

Wysłany by

Moje eksperymenty z QtQuick2 spowodowały, że całkowicie zmieniłem zdanie na temat Qt5 i muszę przyznać, że minę mam coraz częściej taką 8-O.

cppslotfromqml
Po przemyśleniu możliwości model-view-controller, gdzie widok generowany jest z QML przez OpenGL, a dynamiczne z natury dzisiejszych urządzeń zmiany interfejsu zakodowane są w EcmaScript (JS) osadzonym w QML, oprócz tego łatwość wywoływania funkcji w C++ i Javie, dochodzę do wniosku, że Qt5 rządzi ;).

Hello World w QtQuick2.

Wysłany by

QtQuick jest fascynujące:

Animacje to nawet nie kilka linijek kodu… a za ich wyświetlanie odpowiada OpenGL lub OpenGL ES 2.0.

QtQuick może być też osadzone w klasycznym oknie QWindow:

qmlAle póki co, nadal w Qt-5.5.1 nie działa to na Androidzie (QtQuick i QWidgets to dwie osobne powierzchnie wyświetlania w OpenGL, na Antku nie jest to póki co obsługiwane i może być albo QtQuick albo QWidgets).


ui->setupUi(this);

QQuickView *view = new QQuickView;
QWidget *container = QWidget::createWindowContainer(view, this);
view->setSource(QUrl::fromLocalFile("main.qml"));

ui->verticalLayout->addWidget(container);

OptionsDialog.

Wysłany by

TreeView na Androidzie sprawdza się średnio, zastanawiałem się jak to można by zrobić w Qt5 i przyznam szczerze, łatwo nie jest. QScrollView ma jedną podstawową wadę: póki co nie obsługuje przewijania jednym palcem i trzeba mu zostawić włączony scrollbar, na szczęście udało się go poprawić za pomocą stylów:

O kwestię layoutów mam ochotę zapytać któregoś z developerów, bo niestety są bardzo nieprzewidywalne. Nigdy nie wiadomo gdzie i jak dany widget się wyświetli. Na powyższym zrzucie odległości między obiektami są różne, a powinny być względnie spójne, bo na samym dole kontenera dodałem expander, który powinien wszystko co powyżej niego ładnie do siebie dosunąć…

Mam nadzieję, że kiedyś pojawi się spójne scrollview z obsługą single finger pan. Póki co się nie zanosi. A przecież aplikacji w QtWidgets jest niewspółmiernie więcej na wolności, niż w QtQuick.

AspeQt na Kazam Tornado 348.

Wysłany by

A oto żywy dowód na prawidłową obsługę usb-host przez Kazam Tornado:

Przy okazji powiększyłem trochę przyciski i jeśli ekran jest mniejszy od 5″ to log jest wyłączony (wyświetla się na pasku statusu), a hbox-y wypełniają cały ekran:

Screenshot_2015-09-06-02-59-05Z małych ważnych zmian: usunąłem orientację poziomą i dzięki temu można sobie wybrać plik do załadowania w Fileselektorze w pionie (więcej się mieści).

scr-orient

 

AspeQt dla Windows.

Wysłany by

Piętnaście emulowanych napędów w AspeQt to było dla mnie zdecydowanie za dużo 🙂 więc „zandroidyzowałem” plik projektu z repo dla Androida i wydzieliłem co androidowe, dzięki czemu mój fork AspeQt dla Antka kompiluje się też pod Windows i pod Linuksem. Obsługa portu odbywa się wtedy przez standardowy moduł serialport-{win32,linux}.cpp. Przy okazji poprawiłem kodowanie znaków, które w AspeQt pod Windows było skopane od dawna:

AspeQt_WindowsBinarka dla Windows z wymaganymi bibliotekami tutaj.

winandroidlinux

Qt5 – Natywny file&directory selector przez JNI.

Wysłany by

QFileDialog w Qt5 na Androidzie jest fatalny. Na szczęście znalazłem minimalistyczny fileselector:

http://www.scorchworks.com/Blog/simple-file-dialog-for-android-applications/

który świetnie się sprawdza w AspeQT:

IMG_20150719_123904Musiałem go tylko lekko zmodyfikować, bo na nazwę pliku oczekuję w pętli po stronie Qt (lame, ale brakło mi czasu na bardziej eleganckie rozwiązanie)  i bez Cancel nie dało się z niej wyskoczyć:

QAndroidJniObject::callStaticMethod<void>("net/greblus/MyActivity", "runFileChooser", "()V");

QString fileName = NULL;
do
{
   QAndroidJniObject jFileName = QAndroidJniObject::getStaticObjectField<jstring>("net/greblus/MyActivity", "m_chosen");
   fileName = jFileName.toString();

   if (fileName == "Cancelled") {fileName.clear(); break;}
   if (fileName == "None") QThread::yieldCurrentThread();
}
while (fileName == "None");

A w Javie, cały widz polega na tym, że MyActivity jest singletonem i niestatyczne metody (jak w FileChooser) trzeba wołać w wątku UI Androida z instancji singletona:


public class MyActivity extends QtActivity
{
   ...
   public static MyActivity s_activity = null;
   ...
   public void onCreate(Bundle savedInstanceState)
   {
      s_activity = this;
   }
   ...
}

public static void runFileChooser() {
   m_chosen = "None";
   MyActivity.s_activity.runOnUiThread( new FileChooser() );
}

i wtedy można z C++ wywołać QAndroidJNIObject tak:

QAndroidJniObject::callStaticMethod<void>("net/greblus/MyActivity", "runFileChooser", "()V");

Lekko zmodyfikowany plik tutaj.

bigger_aspeqt

Java ByteBuffer w Qt5.

Wysłany by

1. Współdzielenie danych między Javą a Qt5 chyba mam opanowane:

ByteArrayW Javie to wygląda np. tak:

public ByteBuffer bbuf = ByteBuffer.allocateDirect(10);
public byte b[] = new byte [] {1, 1, 2, 3, 5, 8, 13, 21, 34, 55};
public static native void sendBufAddr(ByteBuffer buf);
// natywna funkcja w C++ do której przekazujemy adres bufora
// dane z bufora pakujemy do ByteBuffera w ten sposób:
bbuf.put(b);
// i wysyłamy adres do funkcji w C++
sendBufAddr(bbuf);

A funkcja w C++ w wersji minimalistycznej w QT5 wygląda tak:

extern "C" {
   JNIEXPORT void JNICALL
   Java_net_greblus_MyActivity_sendBufAddr(JNIEnv *env,
   jobject, jobject buf)
   {
   jbyte *bbuf = (jbyte *)env->GetDirectBufferAddress(buf);
   // i możemy robić z danymi w bbuf[] co chcemy
   }
}

2. Pakiet jar ze sterownikiem do FTDI działa w Qt5 w MainActivity, więc wszystkie elementy układanki zaczynają do siebie pasować ;).

QAndroidJniObject. To naprawdę działa!

Wysłany by

Jakby ktoś się zastanawiał, to walczę dalej z portem aspeqt na Androida, a dokładniej z obsługą czipu FTDI na Androidzie. Sterownik ftd2xx od FTDI to totalna porażka (segfault goni segfault) i z tego co widzę nie ma szans na obsługę FTDI za pomocą tego sterownika bezpośrednio z C++, bez roota i modyfikacji obrazu systemu.

Na szczęście jest jeszcze libftdi.

Ale i tutaj nie jest tak różowo. W pierwszej kolejności musiałem skompilować libusb na Antka, potem samo libftdi, a to wszystko, żeby się przekonać, że standardowe libusb nie potrafi otworzyć urządzenia bo nie ma do tego uprawnień. I choćby nie wiem jak kombinować z uprawnieniami w Manifest.xml, nic  to nie da.

Jest alternatywne podejście: najpierw z poziomu Javy należy otworzyć urządzenie i uzyskać uprawnienia do usb. Potem przekazać deskryptor pliku urządzenia do libusb. To ponoć działa na delikatnie zmodyfikowanej wersji libusb (mam już ją skompilowaną na Antka).

Mój plan był prosty: z poziomu QT wywołuje klasę Javovą, która otworzy urządzenie i poprosi o uprawnienia, a potem zwróci do QT deskryptor pliku. Plan planem, ale JNI w QAndroidJniObject nie chciało mi działać. Teraz już wiem dlaczego :). Przykład Bogdana Vetry zawierał rozwiązanie problemu w pierwszym komentarzu: plik źródłowy w Javie, umieszczamy w katalogach odpowiadających strukturze pakietu, ale w android/src. Jak pakiet utworzę w android to nie zadziała ;).

Czyli:
1. Tworzymy nowy projekt QT Android.
2. W pliku .pro dodajemy:

QT += core gui androidextras
ANDROID_PACKAGE_SOURCE_DIR = $$PWD/android/

W katalogu projektu dodajemy katalog android/src/net/greblus/MyJavaClass.java:

package net.greblus;

public class MyJavaClass {
     public static int fibonacci(int n)
    {
        if (n < 2)
            return n;
        return fibonacci(n-1) + fibonacci(n-2);
    }
}

i wywołujemy w C++ z QAndroidJniObject w ten sposób:

ret = QAndroidJniObject::callStaticMethod<jint>("net/greblus/MyJavaClass", "fibonacci", "(I)I", n);

Dwa wieczory spędziłem nad tym brakującym src, ale dzięki temu sporo się nauczyłem ;). QT5 to dla mnie w tym momencie toolkit nr 1.

libusb mam już skompilowane, teraz tylko mała modyfikacja libftdi i można próbować z otwieraniem urządzenia z Javy ;).