Sharing a Qt application?
-
I am not at all familiar with Qt, so I hope these questions are not too basic or nonsensical: :)
Is there a entry point in to a Qt application where I can hook in so as to capture the final window data as it's sent to the OS frame buffer?
Here is the reason I am asking:
I am building an application that I want to deploy on both Windows and Linux. (Perhaps Mac OS, eventually)
Our tech support/training people would like to be able to start a remote desktop session with customers to help explain various application features. Rather than using the OS provided remote desktop services, I'd like to just export my own application via an embedded VNC server.
This way our tech support agents only see our application, and we would have far better control over getting the session set up in the first place. (Full OS level sharing would be reserved for a backup in serious cases)
It might also provide a framework for both better auditing of what the remote tech support agent is doing, and enabling better application-specific collaboration features.
Can this be done?
For output: Is there a place in a Qt application where I can capture the final as-drawn windows to feed to an embedded VNC server?
For input: Is there a place in a Qt application to insert the mouse/keyboard events from the remote tech support agent and merge them with the local keyboard/mouse events?
Thank you
David -
Hi,
For output:
for output, you could write you own paint engine. It is responsible for drawing and double buffering.
see "paint system":http://doc.qt.nokia.com/4.7/paintsystem.html and "qpaintengine":http://doc.qt.nokia.com/4.7/qpaintengine.html . You could (depending on your license model of Qt) copy the raster paint engine and add the VNC there. But it don't think it will not be a fast thing to do.For input:
I think you need some OSS depending stuff for that. You have to emit spontaneous events, which is not possible by QCoreApplication::postEvent(). So you must inject that to the OS, which is afaik only possible by platform dependent stuff (direct OS API calls).
-
The paint engine approach is in the lower part of the painting system.
There you have control on the real paint device, the raster paint engine has the double buffer etc. So this is the only place I can imagine to add such stuff. But I don't want to be the one to implement it :-) -
[quote author="Andre" date="1300724872"]Sounds like something that is not feasible. Even if you could get the contents of a window, what about multiple windows, such as pop up dialogs for selecting a file? [/quote]
Yes, that would those would have to be composited in an intelligent manner.
-
Gerolf, thank you for the reply.
Output:
Why would implementing at the "Qt to OS graphics API layer" be any worse than a standalone VNC server that is asking the OS to provide updates to painted windows?
If anything, I would have guessed that performance could be better given that Qt has intimate knowledge of what was actually updated.Input: Can you clarify why the input injection would have to happen at the OS level?
-
Output:
If you create a paint engin, it's exactly the place where to map from qt to OS. Perhaps you can also just implement a custom QPaintDevice, but to check that, you have to dive the docs.
Input:
I already tried to inject mouse and key events. They are different if you do postEvent(new QKeyEvent()) than if created by the os. For windows you can get the keyboard state and change it. Then the input seems identical to real key presses. You can check QApplication (or QCoreApplication, don't know exactly) what they do on e.g. windows events and how they handle them. Could also be that the mapping happens in QWidget somewhere.
If you use Qt methods to inject the events, it MUST be the exact identical way.