I have solved the problem of the calculator not getting keypresses, and let me tell you it was tricky. The problem is that Windows does not know that Qt thinks that *it* (Qt) is managing the focus. Instead, The OS feeds mouse events directly to the calculator when it is visibly on top. But it doesn't do that for keypresses. Here is how I worked around the problem:
When the calculator native window gets embedded into a Qt container object, we then overlay a transparent Qt widget over it. When Qt detects a mouse click on the overlay, it notifies the OS to focus the calculator window. When the Qt focus switches away, Qt notifies the OS that the calculator window no longer has focus. This actually works in my test program. I could not have done this without the help of ChatGPT, or at least it would have taken way longer and have been very frustrating. I had already learned that there are some incompatibilities that affected key handling between Qt-managed windows and OS-managed ones and that some people had been struggling with them. ChatGPT knew about the OS/Qt focus incompatibility and it knew how to call the right Windows functions from within the program. But it needed a lot of guidance from me, including the idea of the transparent overlay. The whole story is a saga that I will post about separately. I don't know how hard it will be to adapt the approach to Linux. It probably won't be too hard for the X11 system, but more and more distros are changing over to Wayland and that is very different. I'm not sure I will tackle it. Getting this HP calculator, which is Windows-only, into Leo satisfies my immediate desire. On Sunday, September 8, 2024 at 9:19:43 AM UTC-4 Thomas Passin wrote: > I have been able to embed an external (non-Leo, non-Python) application in > a Leo window. The attached screen shot shows an HP-42 Reverse Polish > Calculator program running in Leo's main splitter. This program uses an > image of real HP-42 hand-help calculator, as you can see. The calculator > program is not my own work; it has been around for a long time. If I had > known how to embed it, I might not have adapted the RPCalc code to use with > Leo. The HP-42 is much better. > > This is a proof of principle and everything isn't quite right yet. The > calculator responds to mouse presses but it isn't getting the focus and so > doesn't get keypresses as yet. > > I'm not sure what kinds of external programs will be useful this way. A > spreadsheet might be interesting but they usually need to have a large > window so it wouldn't work to confine it in part of Leo's window. The > calculator is useful because I sometimes want to calculate some numbers and > it's convenient to do it within Leo. You could do an image viewer but it > would be tricky to get it to work with Leo's data. And there are one or > more Leo scripts or plugins for viewing images already, including VR3 if > you want to write down a bit of RestructuredText or Markdown. Or you can > paste the full path to an image file into the body and CTRL-Click it. So > there are many ways to handle viewing images already. > > A small-size paint or drawing program might be interesting. > > Anyway, I hope this post will stimulate some ideas. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/052c5372-bd9b-4f64-b299-2b73d1ef12c8n%40googlegroups.com.
