Modules of GpgFrontend
Go to file
2024-07-29 22:21:25 +02:00
cmake feat: remove dependency 'spdlog' 2024-07-27 11:29:29 +02:00
include feat: update copyright info 2024-07-29 22:21:25 +02:00
sdk feat: initialize and move in two modules 2024-07-10 16:12:46 +02:00
src feat: update copyright info 2024-07-29 22:21:25 +02:00
third_party feat: update copyright info 2024-07-29 22:21:25 +02:00
.clang-format feat: initialize and move in two modules 2024-07-10 16:12:46 +02:00
.clang-tidy feat: initialize and move in two modules 2024-07-10 16:12:46 +02:00
.gitignore feat: initialize and move in two modules 2024-07-10 16:12:46 +02:00
.gitmodules feat: remove dependency 'spdlog' 2024-07-27 11:29:29 +02:00
CMakeLists.txt feat: update copyright info 2024-07-29 22:21:25 +02:00
COPYING feat: initialize and move in two modules 2024-07-10 16:12:46 +02:00
README.md feat: add some content to README 2024-07-29 20:41:05 +02:00

GpgFrontend Modules

This repository hosts all the inherited module code for GpgFrontend. These modules are packaged with the GpgFrontend main program by default. The module code hosted in this repository needs to be reviewed by the project maintainer, Saturneric, to ensure high security. Therefore, GpgFrontend automatically loads these modules at startup by default. Users can also disable any or all of these modules in the settings provided by GpgFrontend. On some operating system platforms, GpgFrontend is released via compressed files rather than images, and users can delete a specific module or all modules by removing the corresponding dynamic link library (DLL).

About the Modules

Module support is a key extension feature of GpgFrontend. By encapsulating functionality into modules, users can tailor GpgFrontend to their needs. They can temporarily disable or even delete a particular feature. This approach avoids loading a large amount of code that not everyone may use into the GpgFrontend main program. Consequently, the GpgFrontend main program becomes more stable, concise, and focused on performing tasks well.

Another benefit of introducing module support is that anyone can participate without needing to learn the architecture and various mechanisms of the GpgFrontend main program. Through a brief API provided by the SDK, utilizing easy-to-understand and flexible event and anchor mechanisms, modules can play their roles. Users can write and publish their own modules or contribute to this repository.

SDK and API Usage

The SDK API uses C-style function parameters and ABI. Once the API stabilizes, it will largely remain unchanged, significantly improving the binary compatibility of the SDK dynamic library. Only the integrated modules in this repository will be dynamically loaded during initialization, not user-defined modules.

Due to GPL-3.0's definition regarding whether module code is part of the overall program or a new program, GpgFrontend modules must also be released under the GPL-3.0 or later license. Modules can freely utilize the capabilities of the Qt libraries used by GpgFrontend, including Core, Widget, and Network. This means that modules will only be loaded by GpgFrontend if they use the same version of the Qt libraries.

Modules using an SDK version higher than what GpgFrontend supports will not be loaded. The SDK version number corresponds directly to the GpgFrontend version number. In the absence of comprehensive documentation, users can refer to the implementation code of existing modules to develop their own modules if necessary.

I am committed to adding more modules in the future, and any functionality not directly related to the core focus of GpgFrontend will be developed as modules. Unfortunately, due to time constraints, I cannot maintain both the Qt5 and Qt6 versions of the integrated modules. Therefore, the integrated modules in this repository no longer support Qt5 and will not be released with the Qt5 version of GpgFrontend. However, the Qt5 version of GpgFrontend still includes a complete module system, so users can develop or port their own modules.

Module Development

Compiling a module relies on the SDK header files, which then need to be linked with the corresponding libgpgfrontend_module_sdk library (dynamic library). Specific methods and project configuration can refer to the existing module project configuration files in this repository. Currently, GpgFrontend provides build options to compile and install the SDK, namely GPGFRONTEND_BUILD_TYPE_FULL_SDK and GPGFRONTEND_BUILD_TYPE_ONLY_SDK.

After compiling the SDK with GpgFrontend, it usually includes the include and lib folders. These can be directly installed or placed in the corresponding version number directory under the sdk directory in this repository, such as sdk/2.1.3. Then, you can run the feature configuration and compile the module code in this repository.

Modules are released as single dynamic libraries. The file extension for dynamic libraries varies across operating systems, so the code in this repository needs to be able to compile into dynamic libraries on all operating systems supported by GpgFrontend.

Introducing third-party libraries to integrated modules (other than those already used by GpgFrontend) requires great caution and should only be done when necessary. If the Qt library can provide the required functionality, make every effort to use functions from the Qt library first. If a third-party library is indeed needed, it must be installed as a dynamic library along with the module itself in the correct directory.

User-developed module code does not need to be included in this repository. Users can develop their own modules for personal use or limited distribution. The advantage of placing your module in this repository is that it will be released with GpgFrontend, making it available to a broader audience.