aboutsummaryrefslogtreecommitdiffstats
path: root/src/content/docs/advanced/module-controller.md
blob: 7f5dfaad0530a94dd3294b3a0fe8618c3975af09 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
---
title: "Module Controller: Extending GpgFrontend Functionality"
sidebar:
  label: Module Controller
---

The **Module Controller** in **GpgFrontend** allows users to manage modular
extensions that enhance the core functionality of the application. These modules
provide features such as email integration, version checking, and key
synchronization, offering flexibility for different workflows.

This guide provides an overview of the **Module Controller** interface,
instructions for managing modules, and guidance for advanced users interested in
developing custom modules.

---

## Accessing the Module Controller

To access the **Module Controller**:

1. Open the **Advanced** menu in the top toolbar.
2. Select **Open Module Controller**.

   ![Open Module Controller](https://image.cdn.bktus.com/i/2024/11/29/fa515b3c-d9b1-70f5-c355-832b6bf07a38.webp)

The **Module Controller** interface consists of the following tabs:

- **Registered Modules**
- **Global Register Table**

---

## Registered Modules Tab

The **Registered Modules** tab displays all available modules and provides tools
for managing their activation, metadata, and storage.

### Key Features

1. **Module List**

   - The left panel lists all currently available modules.
   - Modules prefixed with `*` are **Integrated Modules**, meaning they are
     bundled with the GpgFrontend application.

2. **Module Information**

   - When a module is selected, detailed metadata is displayed in the right
     panel, including:

     - **ID**: The unique identifier of the module.
     - **Version**: The current module version.
     - **SDK Version**: The version of the SDK required by the module.
     - **Path**: The physical location of the module file.
     - **Activation Status**: Indicates whether the module is active or set to
       auto-activate.

     Example:

     ```
     - ID: com.bktus.gpgfrontend.module.email
     - Version: 1.0.0
     - SDK Version: 2.1.5
     - Path: /path/to/module/file
     - Auto Activate: True
     - Active: True
     ```

   ![Registered Modules](https://image.cdn.bktus.com/i/2024/11/29/b35d35f9-4ae2-0d3b-917d-a6fb815711f9.webp)

3. **Module Actions**

   - **Deactivate**: Temporarily disables the selected module.
   - **Disable Auto Activate**: Prevents the module from loading automatically
     when GpgFrontend starts.

4. **Show Mods Directory**

   - Opens the directory where external modules are stored. Users can manually
     add or remove custom modules by placing or deleting files in this
     directory.

   > **Tip for Integrated Modules**:

   - **Windows/Mac Users**: Integrated Modules (prefixed with `*`) can be
     removed by deleting the corresponding `.dll` (Windows) or `.dylib` (Mac)
     file from the `modules` directory.
   - **Linux Users**: Due to the nature of **AppImage** and **Flatpak**
     packages, removing Integrated Modules may require recompiling and
     repackaging the application.

## Global Register Table Tab

The **Global Register Table** provides a detailed view of the internal data
structure used by GpgFrontend and its modules. This table is primarily useful
for developers and advanced users who want to debug or inspect module
interactions with the core application.

### Key Features

1. **Key-Value Data**

   - Displays the hierarchical structure of global variables, including:
     - Module-specific settings (e.g., version checking, state tracking).
     - GnuPG paths and environment configurations.
   - Example:
     ```
     gpgme:
       ctx:
         app_path: /opt/homebrew/Cellar/gnupg/2.4.5_1/bin/gpg
         gnupg_version: 2.4.5
         gpgconf_path: /opt/homebrew/bin/gpgconf
     ```

2. **Navigation**

   - Expand nodes to explore detailed properties for modules or core components.

   ![Global Register Table](https://image.cdn.bktus.com/i/2024/11/29/e4a74c1d-c81a-166f-abd8-4f3f4f92f4d0.webp)

## Developing Custom Modules

The **Module Controller** supports custom modules, allowing developers to extend
GpgFrontend's functionality for specialized use cases. All modules adhere to a
strict **C ABI (Application Binary Interface)** and are dynamically linked to
the `libgpgfrontend_sdk` library.

### Key Points for Developers

1. **C ABI Compliance**

   - Modules must be implemented using the C ABI to ensure compatibility across
     all supported platforms (Windows, macOS, Linux).

2. **Dynamic SDK Linking**

   - Modules interact with GpgFrontend by linking dynamically to the
     **libgpgfrontend_sdk** library. This library provides the necessary
     interfaces for module initialization, data exchange, and runtime
     interaction.

3. **SDK Limitations**

   - The current SDK API is still under development and may not cover all
     potential use cases. Developers are encouraged to contact the project
     maintainer for guidance or feature requests.

4. **Getting Started**
   - Place the compiled module file (`.dll`, `.dylib`, or `.so`) in the
     `modules` directory. Use the **Show Mods Directory** button to locate this
     directory.

---

## Tips for Managing Modules

1. **Backup Before Changes**

   - Always create a backup of the `modules` directory before making changes,
     especially when adding or removing modules.

2. **Regular Updates**

   - Check for updates to both GpgFrontend and its modules to ensure
     compatibility and access to the latest features.

3. **Safe Removal**

   - Follow the guidelines for deleting Integrated Modules based on your
     platform to avoid accidental issues.

4. **Use Global Register Table for Debugging**
   - Advanced users can verify module configurations and GPG environment paths
     through the **Global Register Table**.

---

## Example Module: Version Checking

The **VersionChecking** module is a bundled example of how GpgFrontend uses
modules to provide additional functionality.

### Features:

- Checks the current application version.
- Displays release notes for new updates.
- Notifies users when an upgrade is available.

### Example Metadata:

```
- ID: com.bktus.gpgfrontend.module.version_checking
- Version: 1.0.0
- Auto Activate: True
```

### Global Register Table:

```
com.bktus.gpgfrontend.module.version_checking:
  current_version: v2.1.5
  need_upgrade: false
  latest_version: v2.1.5
```

---

By leveraging the **Module Controller**, users can customize and extend
GpgFrontend to suit their needs. Developers interested in creating new modules
are encouraged to experiment with the SDK and collaborate with the maintainer
for additional API support. For more details, visit the [GpgFrontend Modules
GitHub
Repository](https://github.com/saturneric/GpgFrontend-Modules/blob/main/README.md).