Qt API for WLX plugins

[corporator]

Hi folks!

First of all great thanks to the authors of Total Commander for such a great file manager!

To make it even better and simplify development of WLX extensions I created an intermediate library which provides C++ WLX API for Qt classes.

Qt is a big C++ toolkit which includes as UI as many other classes. It simplifies development of UI and allows a programmer to build a fine GUI in just several lines of code.

The intermediate layer I wrote transforms native WinAPI calls, structures, and event processing into an ordinary Qt entities such as QWidget's and other.

This plugin API can be obtained at my GitHub: https://github.com/a-ilin/tcqtface

Please feel free ask any questions, make suggestions and provide feedback

P.S. I will post detailed HOWTO on the API in a couple of days. By now you can look at the example plugin which renders Qt interface .ui files: QtUiViewer. It is located at the same Git repo.

A screenshot of the QtUiViewer example plugin built with this API:
Image: https://raw.githubusercontent.com/a-ilin/tcqtface/master/qtuiviewer/screenshot.png

[ghisler(Author)]

Looks really useful for lister plugins, thanks! About the 32-bit+64-bit dlls, maybe you could load the 64-bit dlls from subdir "64" or "x64" below the plugin directory? The plugin installer can handle subdirs, and loading dlls from a subdir is easy: use GetModuleFileName() for the dll hinstance, and then remove the plugin name and append the subdir and dll name.

[corporator]

Yes, I tried that, however, loading Qt from a subdir is not so easy: it needs customized embedded manifest to load shared compile-time linked DLLs, and Qt DLLs need such manifest too because of cross-dependency loading.
However aside the loading there is a problem inside Qt which leads to a crash on plugin unloading and reloading.
So I found static linking into a single .WLX file as a nice solution for those two problems.

[milo1012]

Nice work.
I'm curious : how big would such statically linked WLX DLL typically be? I like the basic Qt concept, but the DLLs are just unnecessarily huge since years. Last time I did a 4.x project with dynamic DLLs I had 8 MB (QtCore4.dll QtGui4.dll).

Besides that: Isn't there still that license problem with statically linked projects?
http://stackoverflow.com/questions/12654613/static-linking-qt-with-open-source-version
I know that it hindered a lot of developers in the past, and I can't imagine it being any different for the WLX interface.

[corporator]

2milo1012
Thanks!
Typically the size is depends on used Qt libraries and target architecture. For example, statically linked QtUiViewer has the size of 11 / 14 MB for 32 / 64 bit correspondingly.
I don't think the size of program modules has a significant priority for general computers this time. IMHO, code quality/stability/performance are more important

As far as I know Qt is still has different licensing options. For commercial customers there is a possibility to keep the sources closed even in case of static linkage or Qt code modification.
Although open-source Qt version is licensed as GPL or LGPL, so you are right, open-source Qt users should provide the sources in case of static linkage.

Unfortunately using dynamic linkage with Qt for WLX modules is currently lead to a crash on plugin unloading/reloading. And this is definitely Qt problem.
There is a description of the case: http://www.hexblog.com/?p=991
The material is about IDA plugin, however it is applicable to any application that uses Qt as a sideload, shared non-compile-time linked modules.

[milo1012]

For example, statically linked QtUiViewer has the size of 11 / 14 MB for 32 / 64 bit correspondingly.
I don't think the size of program modules has a significant priority for general computers this time. IMHO, code quality/stability/performance are more important

Sure, size may be less important nowadays. But still: > 10 MB for a bit of GUI interaction is a sign of a bloated OO based code. And for example, a similar sized Tcl/Tk project of mine compiled to less than 2 MB. So it just bothers me to know "what could have been" if the Qt source didn't turn into such a OO mess during the last years. And BTW, most existing WLX plug-ins are far less than that, mostly because they deal with the Windows GDI and interface functions directly, and I know that most TC users tend to prefer "reasonably sized" plug-ins.

Anyway, it still is a good option for doing decent wlx gui interaction through a well-known and standardized interface. I might give it a try for a plug-in idea I have.



As for the 32/64 DLL dir problem:
I did a Q&D hack in the past by just modifying the import table for the x64 main executable, like:
QtCore4.dll -> QtCor64.dll
QtGui4.dll -> QtGu64.dll
and renamed the x64 Qt DLLs accordingly. So with that you could have both plug-in versions in the same dir.

[petermad]

Shouldn't this topic be moved to the "Plugins and addons: devel.+support (English)" section ?

[corporator]

2petermad
Oh, sure, I think it would be the right place.

2milo1012
Yes, Qt5 became bigger than Qt4. However Qt is not just GUI classes, it contains wrappers for a lot of platform-dependent functions. And some things like QString have different implementations for the same task. For example it can use plain old byte-to-byte string conversion, or Intel SSE optimized code at compatible CPUs, the choice is made at runtime. All such things take disk space.

I agree that it would be cool to have small binaries. Although there is no such option with Qt.

Thanks for the advise about hacking DLL imports.
I found another approach. The idea is to separate 32 and 64 binaries, including the wlx itself, into different directories. And in the parent directory there should be only "proxy" wlx which will load corresponding library from a subdir. That proxy wlx should not be linked with Qt. To make TC see only needed specific exported functions I made a runtime modification hack of export table of the proxy wlx, which is dependent on the exported functions from the original wlx.

However I met the crash in Qt described above which was so annoying so I decided to use static linkage, and the need of that directory structure with proxy wlx was disappeared.
Currently I have a couple of plugins which are based on Qt excluding the example UI viewer. Both of them are statically linked, and I have no noticeable issues.

[milo1012]

Yes, Qt5 became bigger than Qt4. However Qt is not just GUI classes, it contains wrappers for a lot of platform-dependent functions...

Yes, I know. But having a large function pool doesn't explain the sheer size, but the OO jumble with tons of nested classes and layers that even simplest function calls need to get through. The source became a mess during the last years, with tons of lagacy stuff not being able to get fully removed due to nested code (and BTW hundreds of warnings when you compile it yourself). That's why also 4.x got bigger and bigger. I remember first working with it back when version 3.x was out, where the necessary runtime was still quite small (maybe 2 MB IIRC). I already compiled the mentioned Qt 4 myself and disabled most of the optional stuff (-no-qt3support -no-multimedia -no-exceptions -no-rtti -no-style-xxx etc.) but still got the mentioned 8 MB.

But sure, the general footprint of the lib is probably something we have to live with.

[Hacker]

[mod]Moved to the Plugins and addons forum.

Hacker (Moderator)[/mod]