Dear all,
I've just successfully installed CommonQt on Windows XP, and is able to run both qt-conv and tutorial-14. However, I have two questions.
1. In qt-conv example, if I run (main t) instead of (main), I got "Class not found: QApplication" error. But when i type (find-qclass "QApplication" t) in REPL, i got 1796.
2. in tutorial-14 example, I had to comment out two lines: ;(with-objects ((rect (#_new QRect -35 -35 70 70))) ; (#_drawPie painter rect 0 (* 90 16)))
Otherwise I'll get: #<THREAD "main thread" RUNNING {23DA8A69}>: No applicable method drawPie found on #<QPainter 0x021705D0> with arguments (# <QRect 0x02174AB8>
0
( *
90
16))
I'm using Qt 4.8.5 library for vs2008 and compiled smokegen/smokeqt with vs2008 express (without SP1)
I used quicklisp to install commonqt yesterday, and is running qt-conv this way (ommited the output of the first 2 commands):
E:>sbcl * (require 'qt) * (load "qt-conv.lisp") * (qt-conv:main t)
debugger invoked on a SIMPLE-ERROR in thread #<THREAD "main thread" RUNNING {23DA8A69}>: Class not found: QApplication
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
(QT:FIND-QCLASS "QApplication" T) 0] 0
* (qt-conv:main) ;; then no error occurred. qt-conv will run perfectly
Thanks in advance!
- Rujia
I played around the examples a little and found the workarounds:
1. qt-conv, call (make-qapplication) BEFORE using QApplication. that works perfectly.
2. tutorial-14, replace (* 90 16) with 1440 and it just worked. Weird! I'll look into this later.
- Rujia
On Wed, Sep 11, 2013 at 11:11 AM, Rujia Liu rujia.liu@gmail.com wrote:
Dear all,
I've just successfully installed CommonQt on Windows XP, and is able to run both qt-conv and tutorial-14. However, I have two questions.
- In qt-conv example, if I run (main t) instead of (main), I got "Class
not found: QApplication" error. But when i type (find-qclass "QApplication" t) in REPL, i got 1796.
- in tutorial-14 example, I had to comment out two lines:
;(with-objects ((rect (#_new QRect -35 -35 70 70))) ; (#_drawPie painter rect 0 (* 90 16)))
Otherwise I'll get: #<THREAD "main thread" RUNNING {23DA8A69}>: No applicable method drawPie found on #<QPainter 0x021705D0> with arguments (# <QRect 0x02174AB8>
0
(
90
16))
I'm using Qt 4.8.5 library for vs2008 and compiled smokegen/smokeqt with vs2008 express (without SP1)
I used quicklisp to install commonqt yesterday, and is running qt-conv this way (ommited the output of the first 2 commands):
E:>sbcl
- (require 'qt)
- (load "qt-conv.lisp")
- (qt-conv:main t)
debugger invoked on a SIMPLE-ERROR in thread #<THREAD "main thread" RUNNING {23DA8A69}>: Class not found: QApplication
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
(QT:FIND-QCLASS "QApplication" T) 0] 0
- (qt-conv:main) ;; then no error occurred. qt-conv will run perfectly
Thanks in advance!
- Rujia
Rujia Liu rujia.liu@gmail.com writes:
I played around the examples a little and found the workarounds:
- qt-conv, call (make-qapplication) BEFORE using QApplication. that works
perfectly.
Right, that was the problem. Fixed in git, thanks.
On Wed, Sep 11, 2013 at 12:18 PM, Stas Boukarev stassats@gmail.com wrote:
Rujia Liu rujia.liu@gmail.com writes:
I played around the examples a little and found the workarounds:
- qt-conv, call (make-qapplication) BEFORE using QApplication. that
works
perfectly.
Right, that was the problem. Fixed in git, thanks.
Thanks!
One more issue for tutorial-14:
When I hit "Quit" button the program terminates, but if I simply close the window by clicking the "cross" button on the top-right corner, the program does NOT terminate.
This is true for both SBCL 1.1.4.0.mswin.1288-90ab477 (that win32-thread fork) and ccl-1.9-windowsx86 so I guess it's not a compiler issue. Further more, qt-conv does not have this bug, so I guess it's just something is missing in tutorial-14's code.
- Rujia
I removed the "new eventloop" stuff from tutorial-14 and changed it according to qt-conv, something like (omitted unwind-protect and hide):
(setf *qapp* (make-qapplication)) (let ((window (test))) (#_exec *qapp*)))
Then it worked.
Great! Now I think I can end my "evaluation process" now and start to write the real applications (one new project, one project that has a ltk version - but tk has some limitations so we'd like to port it to commonqt).
- Rujia
On Wed, Sep 11, 2013 at 2:25 PM, Rujia Liu rujia.liu@gmail.com wrote:
On Wed, Sep 11, 2013 at 12:18 PM, Stas Boukarev stassats@gmail.comwrote:
Rujia Liu rujia.liu@gmail.com writes:
I played around the examples a little and found the workarounds:
- qt-conv, call (make-qapplication) BEFORE using QApplication. that
works
perfectly.
Right, that was the problem. Fixed in git, thanks.
Thanks!
One more issue for tutorial-14:
When I hit "Quit" button the program terminates, but if I simply close the window by clicking the "cross" button on the top-right corner, the program does NOT terminate.
This is true for both SBCL 1.1.4.0.mswin.1288-90ab477 (that win32-thread fork) and ccl-1.9-windowsx86 so I guess it's not a compiler issue. Further more, qt-conv does not have this bug, so I guess it's just something is missing in tutorial-14's code.
- Rujia
Rujia Liu rujia.liu@gmail.com writes:
I removed the "new eventloop" stuff from tutorial-14 and changed it according to qt-conv, something like (omitted unwind-protect and hide):
(setf *qapp* (make-qapplication)) (let ((window (test))) (#_exec *qapp*)))
Then it worked.
Indeed. But it looks like this sequence of code is repeated in all the projects. So, I decided to make it easier. Exported a new variable, qt:*qapplication*. Calling make-qapplication is now equivalent to doing (or *qapp* (setf *qapp* (make-qapplication))). QApplication can be instantiated only once anyway, there's no reason to repeat it in each project.
Moreover, I also added a with-main-window macro. The main function of the tutorial is now simply
(with-main-window (window (make-instance 'game-board)) (#_setGeometry window 100 100 500 355)) which expands into (progn (make-qapplication) (with-objects ((window (make-instance 'game-board))) (#_setGeometry window 100 100 500 355) (#_show window) (#_exec *qapplication*)))
Great! Now I think I can end my "evaluation process" now and start to write the real applications (one new project, one project that has a ltk version
- but tk has some limitations so we'd like to port it to commonqt).
Good to hear that. Feel free to ask any questions, the documentation may be lacking in some aspects. I updated it to mention the above changes. And also added a description on how to better connect signals and some additional information about method overrides. You may want to reread sections http://common-lisp.net/project/commonqt/#id106138 and http://common-lisp.net/project/commonqt/#id106256
On Thu, Sep 12, 2013 at 3:31 AM, Stas Boukarev stassats@gmail.com wrote:
Indeed. But it looks like this sequence of code is repeated in all the projects. So, I decided to make it easier.
That's good! :)
Good to hear that. Feel free to ask any questions, the documentation may be lacking in some aspects.
I updated it to mention the above changes. And also added a description
on how to better connect signals and some additional information about method overrides.
Great. I've just experimented about ways to connect signals yesterday :) I also used with-objects macro, after comparing with C++ version and also looking at the macro's source code. I think the spirit is: if the C++ version used a local object (implicit object construction and destroying), use with-objects; but if the C++ version used a pointer without deleting it, don't use with-objects. Correct me if I'm wrong, and I think this information is quite useful for new CommonQt users if you add it to the documentation.
Another interesting thing is QVector's streaming operator:
QPolygon polygon; polygon << QPoint(10, 20) << QPoint(20, 30);
Of course it's not mandatory to use "<<" but it's convenient. Just curious: can we do it similarly in CommonQt?
BTW: I'm talking about this because I use QPolygon in my project. It uses QGraphicsView heavily and everything is going on very well.
- Rujia
Rujia Liu rujia.liu@gmail.com writes:
On Thu, Sep 12, 2013 at 3:31 AM, Stas Boukarev stassats@gmail.com wrote:
Indeed. But it looks like this sequence of code is repeated in all the projects. So, I decided to make it easier.
That's good! :)
Good to hear that. Feel free to ask any questions, the documentation may be lacking in some aspects.
I updated it to mention the above changes. And also added a description
on how to better connect signals and some additional information about method overrides.
Great. I've just experimented about ways to connect signals yesterday :) I also used with-objects macro, after comparing with C++ version and also looking at the macro's source code. I think the spirit is: if the C++ version used a local object (implicit object construction and destroying), use with-objects; but if the C++ version used a pointer without deleting it, don't use with-objects. Correct me if I'm wrong, and I think this information is quite useful for new CommonQt users if you add it to the documentation.
Another interesting thing is QVector's streaming operator:
QPolygon polygon; polygon << QPoint(10, 20) << QPoint(20, 30);
Of course it's not mandatory to use "<<" but it's convenient. Just curious: can we do it similarly in CommonQt?
BTW: I'm talking about this because I use QPolygon in my project. It uses QGraphicsView heavily and everything is going on very well.
Template classes are problematic, there's no meta information like with QObject, so it has to be marshalled explicitly, i.e. converted to a vector, and then converted back, which may not be the most efficient thing to do. There's currently no QVector<QPoint> marshalling, but it can be added if needed.
P.S. For ordinary classes (#_<< x y z) works.
I'm interested how to marshall it explicitly. Not that I need it now but knowing how it works can increase my confidence that CommonQt can do most things that the C++ version can do. Since our main application is 3D, it's possible that the project (that are currently developed with CommonQt) will also need to use OpenGL.
On Thu, Sep 12, 2013 at 9:51 PM, Stas Boukarev stassats@gmail.com wrote:
Rujia Liu rujia.liu@gmail.com writes:
On Thu, Sep 12, 2013 at 3:31 AM, Stas Boukarev stassats@gmail.com
wrote:
Template classes are problematic, there's no meta information like with
QObject, so it has to be marshalled explicitly, i.e. converted to a vector, and then converted back, which may not be the most efficient thing to do. There's currently no QVector<QPoint> marshalling, but it can be added if needed.
P.S. For ordinary classes (#_<< x y z) works.
With best regards, Stas.
Rujia Liu rujia.liu@gmail.com writes:
I'm interested how to marshall it explicitly. Not that I need it now but knowing how it works can increase my confidence that CommonQt can do most things that the C++ version can do. Since our main application is 3D, it's possible that the project (that are currently developed with CommonQt) will also need to use OpenGL.
It requires changes to commonqt, some people already have managed to add support for QVector<QPoint>: https://github.com/7max/commonqt/commit/0c2bf73813924e8f340d5199ac97d3d504de...
I haven't had the chance to integrate it yet.
Rujia Liu rujia.liu@gmail.com writes:
Dear all,
I've just successfully installed CommonQt on Windows XP, and is able to run both qt-conv and tutorial-14. However, I have two questions.
- In qt-conv example, if I run (main t) instead of (main), I got "Class
not found: QApplication" error. But when i type (find-qclass "QApplication" t) in REPL, i got 1796.
Works fine here, but it uses a bit older way of calling static functions, I updated it. And it should be (main :cde), not T.
- in tutorial-14 example, I had to comment out two lines:
;(with-objects ((rect (#_new QRect -35 -35 70 70))) ; (#_drawPie painter rect 0 (* 90 16)))
There was a problem with optimizing constant expressions. Fixed in git. Thanks for the report.
commonqt-devel@common-lisp.net
-
Rujia Liu -
Stas Boukarev