feat: add some content to README

1 files changed, 85 insertions, 5 deletions

diff --git a/README.md b/README.md
index 209372d..8618251 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,88 @@
 # GpgFrontend Modules
 
-This repository holds project files related to the development of the
-GpgFrontend module. A new module is developed by creating a new folder, under
-src.
+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).
 
-These modules will be automatically compiled and released with each GpgFrontend
-release.
+## 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.