Library can now also be compiled as a qml plugin / module

[Jeruntu]

I created an extra cmake target SortFilterProxyModelPlugin to build the library as a plugin. This is just a new option and does not affect the other SortFilterProxyModel target. Also the qmake project still works the same as before.

I updated the documentation with instructions on how to build and install this library as a qml module. Due to a namespace conflict I had to rename the import name to QmlSortFilterProxyModel, but only for the plugin, not for the existing target.

Using this library as a qml plugin also makes it possible to use it with tools like qmlscene and qhot.

[oKcerG]

Thanks for this PR, small nitpick : why the SFP_xxxx prefix in the CMake file intead of SFPM_xxx?

[Jeruntu]

Thanks for this PR, small nitpick : why the SFP_xxxx prefix in the CMake file intead of SFPM_xxx?

No specific reason, SFPM would be better indeed. If I change it to SFPM will you merge this PR?

[oKcerG]

Thanks for this PR, small nitpick : why the SFP_xxxx prefix in the CMake file intead of SFPM_xxx?

No specific reason, SFPM would be better indeed. If I change it to SFPM will you merge this PR?

Not sure yet, I plan to compare this PR to PR #80 this weekend since both seems to do the same thing.
What is sure is that I will merge one of the two (modulo some small modifications if needed).

Do you see obvious difference between #80 and your PR? Things not implemented in one or the other?
Both seem to improve the CMake file and add the possibility to build SFPM as a plugin.

[oKcerG]

Why QmlSortFilterProxyModel and not SortFilterProxyModel as already used?
I would prefer SortFilterProxyModel as the default and optionally changeable if you want.

[Jeruntu]

I would also prefer that, however as stated in my comment, I had a namespace conflict while generating the qmltypes file. That is why I had to change the name.

[Jeruntu]

In fact qmlplugindump used for generating the *.qmltypes file is the program where I experienced the namespace conflict. Maybe after generating the types file I can change the module name back to SortFilterProxyModel.

[oKcerG]

On Linux, RUNTIME installs the .so to plugins/lib/.
LIBRARY seems to produce the correct folder hierarchy. Does it work on Windows?

[Jeruntu]

It is not really an ordinary plugin but a qml module. I just checked on my windows installation, Qt itself installs qml modules like this:
msvc2019_64/qml/<name_module>
I would like to change it to be the same way.

[Jeruntu]

Thanks for this PR, small nitpick : why the SFP_xxxx prefix in the CMake file intead of SFPM_xxx?

No specific reason, SFPM would be better indeed. If I change it to SFPM will you merge this PR?

Not sure yet, I plan to compare this PR to PR #80 this weekend since both seems to do the same thing.
What is sure is that I will merge one of the two (modulo some small modifications if needed).

Do you see obvious difference between #80 and your PR? Things not implemented in one or the other?
Both seem to improve the CMake file and add the possibility to build SFPM as a plugin.

There are big differences between #80 and my solution. This PR creates a real QML module, not just a shared library. If you build this library as a QML module, the only thing you'll have to do is add the import path to your application. You'll also have autocompletion in QtCreator thanks to the *.qmltypes file.

PR #80 creates a shared library. This means you'll have to add a bit of code to make this work.

1. In CMake:

find_package(SortFilterProxyModel REQUIRED) 
...
target_link_libraries(your-target
...
SortFilterProxyModel::SortFilterProxyModel
...
)

2. In main.cpp:

QQmlApplicationEngine engine;
...
SortFilterProxyModel::registerQml();
...
engine.load(url);