Export On-Screen Data to XML
-
I am confused Gerolf. Why exactly would not be able to use an adapted Qt, or a Qt plugin if you have no control over the app code? As long as the code is dynamically linked, you should be able to replace the Qt libraries with your own, rigged version, right? Or am I overlooking something?
-
I don't think so. As long as the new modified Qt library is binary compatible it should work fine. One subtletty to watch out for would be the plugin build key (if the app uses plugins).
-
[quote author="Andre" date="1300431206"]I am confused Gerolf. Why exactly would not be able to use an adapted Qt, or a Qt plugin if you have no control over the app code? As long as the code is dynamically linked, you should be able to replace the Qt libraries with your own, rigged version, right? Or am I overlooking something?[/quote]
If the Qt version was build by configure without default parameters, how do you know which ones to use? And If you have no access to the code, where to know which internals might be used (although they shouldn't)?
A plug-in must always be used by the code to be instantiated, so if the app code does not load the plug-in, it will not be loaded, right?
Adopted version of Qt would work if you know exactly, which compilers, configure switches etc were used for the app, and if it's not a must for the test to use the same version as it will be used at customer side (one requirement we have, no modified things for tests).
-
Well... It remains to be seen if the Qt version in use is non-standard, of course. That would be quite easy to try, I think. A standard Qt program takes command line parameters to select things like the QStyle plugin to use. Other plugins are actually loaded on startup, like the SQL drivers. I think you could abuse that. Of course, you might run into trouble, it is not guaranteed to work for each and every situation, but for a relatively standard Qt-based program, I think it would go a long way with a pretty decent change of success.