review cpp-lib example

This commit is contained in:
pls.153 2022-01-22 21:12:15 +01:00
parent eb54b6fd41
commit 2e67185cd2
3 changed files with 18 additions and 21 deletions

View file

@ -1,4 +1,4 @@
QT += core
QT += widgets
TEMPLATE = lib
CONFIG += plugin release
DESTDIR = ../

View file

@ -1,4 +1,6 @@
#include "lib.h"
#include <QApplication>
#include <QMessageBox>
#include <QtDebug>
QT_BEGIN_NAMESPACE
@ -8,18 +10,21 @@ QObject* ini() {
static QObject* cpp = 0;
if(!cpp) {
cpp = new CPP;
// needed for QMessageBox
static int argc = 1;
static char* argv[] = {"cpp"};
new QApplication(argc, argv);
}
return cpp;
}
// insert here your function implementations
QVariant CPP::hello(const QVariant& arg) {
QString msg;
QDebug debug(&msg);
debug << arg;
qDebug() << "hello" << arg;
QMessageBox::information(nullptr, "hello", msg);
return arg;
}

View file

@ -14,26 +14,18 @@ Run
```
$ lqml ~/slime/qml-start-swank.lisp
$ emacs
$ emacs run.lisp
```
In Slime do:
```
(defvar *cpp* (qload-c++ "cpp"))
After `M-x slime-connect` and loading `run.lisp`, you can see that, despite
the argument and return type simply being defined as `QVariant`, you may also
pass lists, because a `QVariant` can also be of type `QVariantList`, so this
is a perfect fit for (nested) Lisp lists.
(define-qt-wrappers *cpp*)
(hello *cpp* '(1 "two" (1.25 #(50 -50 75))))
```
Now look at the console output where you launched the `lqml` executable.
As you can see, although the argument and return type are simply defined as
`QVariant`, you may also pass lists, because a `QVariant` can also be of type
`QVariantList`, so this is a perfect fit for (nested) Lisp lists.
So, we pass a nested Lisp list, and it gets printed on Qt side with the
respective types. Then the `QVariantList` is returend to Lisp, where it is
So, we pass a nested Lisp list, and it gets shown on Qt side with the
respective types. Then the `QVariantList` is returned to Lisp, where it is
automatically converted back to a nested Lisp list.
Realy convenient!
Really convenient!