TCL And Qt binding

[Alex (Oleksandr) Malyushytskyy]

Hello,

I am really new to tcl.
Is there up-to-date guide/examples on tcl binding with Qt 5?
Al searches I make end up on old posts with Qt4 and all links do not exists anymore.

Many thanks,
Alex

[Robert Heller]

Why in the world would you want to use Qt with Tcl? Normally, GUI programming
with Tcl is done with Tk, the GUI package specificly designed for Tcl.

>
> Many thanks,
> Alex
>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[Alex (Oleksandr) Malyushytskyy]

Robert,

I do not have much experience with Tk, so I will avoid making comments about Tk features.
But Qt provides easy behind scene integration with modern graphics engines and basic has graphics scene/view implementation which is my employer wants and I was hired for.
tcl is used to let people issue commands from the terminal, one of the command is opening the ui to review the graphics.
That is for users who is familiar with tcl and prefer to do it this way. But in reality GUI should be able everything without need of tcl.

Best regards,
Alex


On Wednesday, June 23, 2021 at 3:11:49 PM UTC-7, Robert Heller wrote:

[Rich]

"Alex (Oleksandr) Malyushytskyy" <al...@flex-logix.com> wrote:

> On Wednesday, June 23, 2021 at 3:11:49 PM UTC-7, Robert Heller wrote:
>> At Wed, 23 Jun 2021 14:49:08 -0700 (PDT) "Alex (Oleksandr) Malyushytskyy" wrote:
>>
>> >
>> > Hello,
>> >
>> > I am really new to tcl.
>> > Is there up-to-date guide/examples on tcl binding with Qt 5?
>> > Al searches I make end up on old posts with Qt4 and all links do
>> > not exists anymore.

The link from Wikipedia goes here, which works:

https://sourceforge.net/projects/qtcl/

>> Why in the world would you want to use Qt with Tcl? Normally, GUI
>> programming with Tcl is done with Tk, the GUI package specificly
>> designed for Tcl.
>>

> Robert,
> I do not have much experience with Tk, so I will avoid making
> comments about Tk features.
> But Qt provides easy behind scene integration with modern graphics
> engines and basic has graphics scene/view implementation which is my
> employer wants and I was hired for.
> tcl is used to let people issue commands from the terminal, one of
> the command is opening the ui to review the graphics.
> That is for users who is familiar with tcl and prefer to do it this
> way. But in reality GUI should be able everything without need of
> tcl.

Wikipedia lists a Qt4 binding for Tcl:
https://en.wikipedia.org/wiki/List_of_language_bindings_for_Qt_4

Wikipedia does not list a Qt5 binding for Tcl:
https://en.wikipedia.org/wiki/List_of_language_bindings_for_Qt_5

This implies that no Qt5 binding exists.

So in this case, it looks like if you want a Qt5 binding, you'll have
to create one yourself.

[Alex (Oleksandr) Malyushytskyy]

Thanks Robert,

https://sourceforge.net/projects/qtcl/ did work for me today, I tried it last Friday and I was getting a totally unrelated file from sourceforge.
Now have a chance to look in the code and try to port it.

Many thanks!
Alex


On Wednesday, June 23, 2021 at 3:45:18 PM UTC-7, Rich wrote:

[Petro Kazmirchuk]

In my company we have a complex C++/Qt/Tcl application, and a lot of effort was invested in integrating Tcl and Qt event loops. It was far from trivial, and still doesn't work reliably after 10+ years of polishing (and occasionally gets broken with Qt upgrades).
Instead of integrating Tcl interpreter in C++, I highly recommend to have a proper RPC framework to communicate between C++/Qt and Tcl in a separate process.

[briang]

On Tuesday, July 6, 2021 at 12:10:40 PM UTC-7, Petro Kazmirchuk wrote:
> In my company we have a complex C++/Qt/Tcl application, and a lot of effort was invested in integrating Tcl and Qt event loops. It was far from trivial, and still doesn't work reliably after 10+ years of polishing (and occasionally gets broken with Qt upgrades).

Interesting. My experience was the opposite in that I found it fairly uncomplicated. I implemented a custom Qt/Tcl notifier to integrate the Qt and Tcl event loops. It's worked pretty much flawlessly and is still in use by my former employer. The tricky parts I discovered are these: 1) Tcl_DoOneEvent() has to be at the top of the QtApplication event loop. At least at the time I implemented this, Qt had no way to acknowledge the existence of other event queues, whereas, Tcl is designed with this concept. Letting Tcl control the event loop at the root, makes handling various end cases actually work. 2) Thread-enabled Tcl is required, and the custom notifier must be thread-aware. 3) I've seen what appears to be Tcl integration bugs actually turn out to be bad design; the application Qt code was poorly written in that it does not respect a proper Model/View/Controller pattern, and 4) consequently, the event loop code has to deal with recursion appropriately.

https://ssl.webpack.de/www.eurotcl.eu/pastevents.html#eurotcl2019
https://youtu.be/1CRhEBzFjFc

> Instead of integrating Tcl interpreter in C++, I highly recommend to have a proper RPC framework to communicate between C++/Qt and Tcl in a separate process.

That's one way to avoid problems :)

[Petro Kazmirchuk]

Hello Brian,
thank you so much for the material, it looks really useful. Back when I was trying to google the topic ~6y ago, there was very little information on Qt/Tcl integration.
Of course, a lot of factors have to be considered when choosing between embedded Tcl vs RPC. Embedded Tcl is certainly easier to debug (due to having both Tcl and C++ code in the same code stack) and more performant, and should be safe when the interpreter runs in the main application thread. However, if embedded interpreters are running in multiple threads and use Tk windows, it becomes very prominent that some low-level code (e.g. X11 or incr Tcl) was never written with thread safety in mind, and a crash in these parts will take all your application down.

[briang]

I wouldn't mix Tk with Qt in the same application as it would only lead to user experience complications. The look would be wrong to begin with. I recall that tracking [focus] correctly was also a challenge. My conclusion at the time I investigated this was that there wasn't enough benefit to mixing the two together.

I'm pretty sure X11 and Tk are thread safe, but I could be mistaken, it's been a long time since I've dealt with this aspect. For sanity sake, any GUI implementation should be confined to a single thread, at least the "view" portion of a "model/view/control" pattern. With Tk, the MVC are all wrapped up together. This does not mean that the business logic (computational part) couldn't be in another thread.

[Petro Kazmirchuk]

in case you're curious, this is a bug in X11 that we hit in 2019
https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/31
working around it was easy, but crash investigation took a long time :(
basically, our application runs many user Tcl scripts in parallel, and they may use Tk, iTk, iwidgets etc. And whenever our users load some half-baked Tcl extension that can crash, our whole application crashes, and the blame is on us :(

[EL]

I would make sure that only one Tcl_Interp is created in one thread and
the scripts are consumed from a queue and processed in this one Interp,
eventually with slave interps. Many different threads can produce
scripts and put them in the queue.

Eventually the Qt or Tcl event loop can be utilized, but doesn't have
too I think... The pattern could also be self-implemented, it's
relatively easy.


--
EL

[Dave Thomas]

Hi Brian,

I found the presentation you made and the paper you wrote on Tcl/Qt event loop integration to very informative. I plan to go down that path and start the implementation in an existing Qt application.

But, I didn't see anything in either paper about the requirement for "Thread-enabled Tcl" and "custom notifier must be thread-aware". Was that something you discovered after the paper and presentation? Can you elaborate on why threading is required and what that means to the notifier implementation (versus what's in the paper/presentation?)

Thanks!

[briang]

Hi Dave,

For thread enabled Tcl, any common data, used with an interp, must be limited to a particular thread. Sharing data across threads must be done in a protected thread-safe manner. (Tcl has some API's to help with this.) Tcl maintains an isolated environment per thread for the interpreters. This is done by using hash table indexed by thread id for any common state for the thread. Each thread that has an interp, also has its own notifier. (possible confusion point: a slave interp is not the same as threads, and has nothing to do with threads.) Simply put, the notifier code has to be "aware" that there can be be multiple notifiers running concurrently, so memory access has to be handled carefully. This applies to any Tcl extensions, written in C, that has global state as well, not just the notifier. This is what is meant by "thread-aware".

Unfortunately, I don't recall any details about Qt thread handling. It's been too long since I've looked at or touched any Qt code.

Let me know if you have any questions.

-Brian