-
-
Notifications
You must be signed in to change notification settings - Fork 22
Separate integration library #348
Comments
Further request for the separate library (or even an additional package like an integration-dev package): include all required header files to be able to compile the integration plugins. |
To simplify the separation of the common interfaces and classes I will create the integration library as a Qt Project Include (.pri) instead of a full blown static library. With a static library we have another build dependency for 4 platforms and all existing build setups (Developer setup, GitHub Actions CI, Docker build image, Buildroot custom packages) need major work. |
- included all header files - refactored to Qt Include Project Part of YIO-Remote/remote-software#348
- Moved all sources and headers to ./src - New project include files with consistent naming - Added README - Fixed cpplint issues Part of YIO-Remote/remote-software#348
- GitHub action to verify code guidelines - Fixed cpplint issues Part of YIO-Remote/remote-software#348
- Included Qt linguist in qmake - GitHub Action to verify code guidelines - Fixed cpplint issues - Improved logging Part of YIO-Remote/remote-software#348
- GitHub Action to verify code guidelines - Fixed cpplint issues - Fixed reconnect handling: QWebSocket.close may only be called if socket is valid - Renamed socket and timer member vars - Improved logging Part of YIO-Remote/remote-software#348
- GitHub Action to verify code guidelines - Fixed cpplint issues Part of YIO-Remote/remote-software#348
- GitHub Action to verify code guidelines - Fixed most cpplint issues Part of YIO-Remote/remote-software#348
- GitHub Action to build dynamic library - GitHub Action to verify code guidelines Part of YIO-Remote/remote-software#348
- GitHub Action to build dynamic library - GitHub Action to verify code guidelines - Fixed cpplint issues Part of YIO-Remote/remote-software#348
- Using the base integration interfaces instead of generic QObject. Part of YIO-Remote/remote-software#348
- Using the base integration interfaces instead of generic QObject. Part of YIO-Remote/remote-software#348
- Using the base integration interfaces instead of generic QObject. Part of YIO-Remote/remote-software#348
- Using the base integration interfaces instead of generic QObject. Part of YIO-Remote/remote-software#348
Can this be closed @zehnm ? |
It should auto-close once merged into master |
Using the base integration interfaces instead of generic QObject. Part of YIO-Remote/remote-software#348
- GitHub Action to build dynamic library - GitHub Action to verify code guidelines Part of YIO-Remote/remote-software#348
- Using the base integration interfaces instead of generic QObject. Part of YIO-Remote/remote-software#348
- GitHub Action to verify code guidelines - Fixed most cpplint issues Part of YIO-Remote/remote-software#348
- Using the base integration interfaces instead of generic QObject. Part of YIO-Remote/remote-software#348
- GitHub Action to build dynamic library - GitHub Action to verify code guidelines - Fixed cpplint issues Part of YIO-Remote/remote-software#348
- Using the base integration interfaces instead of generic QObject. Part of YIO-Remote/remote-software#348
- GitHub Action to verify code guidelines - Fixed cpplint issues Part of YIO-Remote/remote-software#348
- Using the base integration interfaces instead of generic QObject. Part of YIO-Remote/remote-software#348
- Included Qt linguist in qmake - GitHub Action to verify code guidelines - Fixed cpplint issues - Improved logging Part of YIO-Remote/remote-software#348
- Using the base integration interfaces instead of generic QObject. Part of YIO-Remote/remote-software#348
Especially for the implementation of integrations using QAbstractListModel like media players, weather, ... it makes sense that every integration uses the same "model" classes. I think the sources should be in a separate static integration library, not somewhere in the remote-software source hierarchy.
This integration library can also contain often used functionalities like OAuth, ...
The Integration base class should be there maybe extended to a more functional integration base class covering also the separate "integration thread".
The text was updated successfully, but these errors were encountered: