On Tue, Dec 29, 2015 at 1:08 AM, Orm Finnendahl <orm.finnendahl@selma.hfmdk-frankfurt.de> wrote:
Am Dienstag, den 29. Dezember 2015 um 00:54:09 Uhr (+0300) schrieb Stas Boukarev:
All the GUI stuff has to be done from the same thread (and on some OSes it has to be the main thread). To communicate with Qt from a different thread use Qt signals, they are thread-safe.
Thanks, that helps! Do you know, why it is impossible to restart the tutorial example after the thread has finished? Restarting in the main thread after closing the window is no problem. The only way to restart the tutorial after running it within sb-threads:make-thread is to restart sbcl. You can restart it in that thread, but only in that thread. The event loop cannot be restarted, but as long as it's running you can execute and close as many windows as you'd like.
-- With best regards, Stas.
I implemented SLIME REPL integration for CommonQt some time ago, don't know whether it still works in recent CommonQt/SLIME versions, see https://github.com/commonqt/commonqt/blob/master/repl-integration.lisp It utilizes SLIME REPL eval hooks to make SLIME REPL evaluate expressions in the context of GUI thread, which is much safer than just starting separate thread and hoping that doing stuff in the main thread will not cause some kind of race condition. When it worked it was enough to do (ql:quickload 'qt-repl) (qt-repl:start-gui-thread) And after that you could do most GUI stuff right from REPL without worrying that something will break. In my not-up-to-date CommonQt fork it still works, at least when using CCL: https://github.com/ivan4th/commonqt On Tue, Dec 29, 2015 at 1:11 AM, Stas Boukarev <stassats@gmail.com> wrote:
On Tue, Dec 29, 2015 at 1:08 AM, Orm Finnendahl <orm.finnendahl@selma.hfmdk-frankfurt.de> wrote:
Am Dienstag, den 29. Dezember 2015 um 00:54:09 Uhr (+0300) schrieb Stas Boukarev:
All the GUI stuff has to be done from the same thread (and on some OSes it has to be the main thread). To communicate with Qt from a different thread use Qt signals, they are thread-safe.
Thanks, that helps! Do you know, why it is impossible to restart the tutorial example after the thread has finished? Restarting in the main thread after closing the window is no problem. The only way to restart the tutorial after running it within sb-threads:make-thread is to restart sbcl. You can restart it in that thread, but only in that thread. The event loop cannot be restarted, but as long as it's running you can execute and close as many windows as you'd like.
-- With best regards, Stas.
-- Ivan Shvedunov <ivan4th@gmail.com> ;; My GPG fingerprint is: 2E61 0748 8E12 BB1A 5AB9 F7D0 613E C0F8 0BC5 2807
Am Dienstag, den 29. Dezember 2015 um 01:53:57 Uhr (+0300) schrieb Ivan Shvedunov:
When it worked it was enough to do (ql:quickload 'qt-repl) (qt-repl:start-gui-thread)
On sbcl/Linux I get: CL-USER> (qt-repl:start-gui-thread) WARNING: Cannot initialize *SLIME-REPL-EVAL-HOOKS*, use (eval-in-gui-thread ...) form. ; No value CL-USER> In the #'start-gui-thread function the call to (find-symbol "*SLIME-REPL-EVAL-HOOKS*" "SWANK") returns NIL,NIL Am I doing something wrong? -- Orm
Am Dienstag, 29. Dezember 2015 11:06 CET, Orm Finnendahl <orm.finnendahl@selma.hfmdk-frankfurt.de> schrieb:
Am Dienstag, den 29. Dezember 2015 um 01:53:57 Uhr (+0300) schrieb Ivan Shvedunov:
When it worked it was enough to do (ql:quickload 'qt-repl) (qt-repl:start-gui-thread)
On sbcl/Linux I get:
CL-USER> (qt-repl:start-gui-thread) WARNING: Cannot initialize *SLIME-REPL-EVAL-HOOKS*, use (eval-in-gui-thread ...) form. ; No value CL-USER>
In the #'start-gui-thread function the call to
(find-symbol "*SLIME-REPL-EVAL-HOOKS*" "SWANK") returns NIL,NIL
Am I doing something wrong?
Hi Orm, you are almost there :-) The qt-repl code unfotunately depends on 'wank-listener-hooks.lisp' which can be found in slime's contrib irectory (but, alas, can't be loaded with slime-setup ...). Load this file and qt-repl:start-gui-thread will work. Nota Bene: while this will give you a working repl whike Qt's event loop runs (i.e. after a call to #_exec) you still need to be careful about wht Qt call you make. Hope that helps RalfD
Am Dienstag, den 29. Dezember 2015 um 14:49:11 Uhr (+0100) schrieb Ralf Mattes:
The qt-repl code unfortunately depends on 'swank-listener-hooks.lisp' which can be found in slime's contrib directory (but, alas, can't be loaded with slime-setup ...). Load this file and qt-repl:start-gui-thread will work.
just for the record: That works like a charm. Thanks to everybody and a nice New Year's Eve! -- Orm
Am Dienstag, 29. Dezember 2015 15:10 CET, Orm Finnendahl <orm.finnendahl@selma.hfmdk-frankfurt.de> schrieb:
Am Dienstag, den 29. Dezember 2015 um 14:49:11 Uhr (+0100) schrieb Ralf Mattes:
The qt-repl code unfortunately depends on 'swank-listener-hooks.lisp' which can be found in slime's contrib directory (but, alas, can't be loaded with slime-setup ...). Load this file and qt-repl:start-gui-thread will work.
just for the record: That works like a charm.
Here's a minimal fix/patch for slime: https://github.com/rmattes/slime/commit/15292d54bf28bfe961e6df9667991484b8a8... With that patch, one can do "(slime-setup '(lime-fancy 'slime-listener-hooks))" and qt-repl will just work. Cheers, RalfD
Thanks to everybody and a nice New Year's Eve!
-- Orm
On Tue, Dec 29, 2015 at 6:21 PM, Ralf Mattes <rm@mh-freiburg.de> wrote:
Am Dienstag, 29. Dezember 2015 15:10 CET, Orm Finnendahl <orm.finnendahl@selma.hfmdk-frankfurt.de> schrieb:
Am Dienstag, den 29. Dezember 2015 um 14:49:11 Uhr (+0100) schrieb Ralf Mattes:
The qt-repl code unfortunately depends on 'swank-listener-hooks.lisp' which can be found in slime's contrib directory (but, alas, can't be loaded with slime-setup ...). Load this file and qt-repl:start-gui-thread will work.
just for the record: That works like a charm.
Here's a minimal fix/patch for slime:
https://github.com/rmattes/slime/commit/15292d54bf28bfe961e6df9667991484b8a8...
With that patch, one can do "(slime-setup '(lime-fancy 'slime-listener-hooks))" and qt-repl will just work.
Applied. -- With best regards, Stas.
I still have problems with qt-repl and qt: As expected, running the following code in qt works fine, but the repl is blocked until the window is closed: (ql:quickload "qt") (in-package :qt) (let* ((app (make-qapplication))) (with-objects ((window (#_new QWidget))) (#_setGeometry window 0 0 300 200) (#_setWindowTitle window "TestWindow") (#_show window) (#_exec app))) Trying the same code in the qt-repl doesn't show the window: (ql:quickload "qt-repl") (in-package :qt-repl) (start-gui-thread) (let* ((app (make-qapplication))) (with-objects ((window (#_new QWidget))) (#_setGeometry window 0 0 300 200) (#_setWindowTitle window "TestWindow") (#_show window) (#_exec app))) ---- On the other hand, opening a window using an external ui file works fine from the qt-repl: (ql:quickload "qt-repl") (in-package :qt-repl) (start-gui-thread) (ensure-smoke :qtuitools) (let* ((app (make-qapplication)) (pathname "/home/orm/work/programmieren/lisp/ui-design/mainwindow.ui") (ui-loader (#_new QUiLoader)) (ui-file (#_new QFile pathname)) (toplevel (#_load ui-loader (progn (#_open ui-file (#_QFile::ReadOnly)) ui-file)))) (#_close ui-file) (#_delete ui-loader) (#_show toplevel) (#_exec app)) Does anybody know what I'm missing? -- Orm
Don't create/exec QApplication when you're using qt-repl, it's already created for you. Put that into separate function and only call it in "production" setting, i.e. when you're not using REPL. On Mon, Jan 4, 2016 at 3:43 PM, Orm Finnendahl < orm.finnendahl@selma.hfmdk-frankfurt.de> wrote:
I still have problems with qt-repl and qt:
As expected, running the following code in qt works fine, but the repl is blocked until the window is closed:
(ql:quickload "qt") (in-package :qt)
(let* ((app (make-qapplication))) (with-objects ((window (#_new QWidget))) (#_setGeometry window 0 0 300 200) (#_setWindowTitle window "TestWindow") (#_show window) (#_exec app)))
Trying the same code in the qt-repl doesn't show the window:
(ql:quickload "qt-repl") (in-package :qt-repl) (start-gui-thread)
(let* ((app (make-qapplication))) (with-objects ((window (#_new QWidget))) (#_setGeometry window 0 0 300 200) (#_setWindowTitle window "TestWindow") (#_show window) (#_exec app)))
---- On the other hand, opening a window using an external ui file works fine from the qt-repl:
(ql:quickload "qt-repl") (in-package :qt-repl) (start-gui-thread) (ensure-smoke :qtuitools)
(let* ((app (make-qapplication)) (pathname "/home/orm/work/programmieren/lisp/ui-design/mainwindow.ui") (ui-loader (#_new QUiLoader)) (ui-file (#_new QFile pathname)) (toplevel (#_load ui-loader (progn (#_open ui-file (#_QFile::ReadOnly)) ui-file)))) (#_close ui-file) (#_delete ui-loader) (#_show toplevel) (#_exec app))
Does anybody know what I'm missing?
-- Orm
-- Ivan Shvedunov <ivan4th@gmail.com> ;; My GPG fingerprint is: 2E61 0748 8E12 BB1A 5AB9 F7D0 613E C0F8 0BC5 2807
Am Dienstag, den 05. Januar 2016 um 02:23:33 Uhr (+0300) schrieb Ivan Shvedunov:
Don't create/exec QApplication when you're using qt-repl, it's already created for you. Put that into separate function and only call it in "production" setting, i.e. when you're not using REPL.
Thanks, that's good to know! Unfortunately the problem remains: Calling: (with-objects ((window (#_new QWidget))) (#_setGeometry window 0 0 300 200) (#_setWindowTitle window "TestWindow") (#_show window)) in the qt-repl after (start-gui-thread) doesn't open the window while doing (ensure-smoke :qtuitools) (let* ((pathname "/home/orm/work/programmieren/lisp/ui-design/mainwindow.ui") (ui-loader (#_new QUiLoader)) (ui-file (#_new QFile pathname)) (toplevel (#_load ui-loader (progn (#_open ui-file (#_QFile::ReadOnly)) ui-file)))) (#_close ui-file) (#_delete ui-loader) (#_show toplevel)) opens the window right away. Does anybody know why? This is fairly important for me as I need to create guis algorithmically and can't predefine them with qt-designer... -- Orm
Hi, on qt gui startup, I alway get a bunch of the following style-warnings (even when just loading and evaluating the tutorial examples): style-warning: Undefined alien: "sw_smoke" style-warning: Undefined alien: "sw_windows_version" style-warning: Undefined alien: "sw_make_qvector_uint" ... As everything works as expected, I assume this is either related to some wrong initialization order, or I'm doing it wrong. Does anybody know, how to circumvent this? -- Orm
That output is expected. On Sun, Sep 30, 2018 at 4:35 PM Orm Finnendahl < orm.finnendahl@selma.hfmdk-frankfurt.de> wrote:
Hi,
on qt gui startup, I alway get a bunch of the following style-warnings (even when just loading and evaluating the tutorial examples):
style-warning: Undefined alien: "sw_smoke" style-warning: Undefined alien: "sw_windows_version" style-warning: Undefined alien: "sw_make_qvector_uint" ...
As everything works as expected, I assume this is either related to some wrong initialization order, or I'm doing it wrong. Does anybody know, how to circumvent this?
-- Orm
participants (4)
-
Ivan Shvedunov -
Orm Finnendahl -
Ralf Mattes -
Stas Boukarev