| Chapter 6. YaST Modules | ||
|---|---|---|
 |  | |
| Chapter 6. YaST Modules | ||
|---|---|---|
| | | |
Table of Contents
Creating modules for YaST means extending its functionality. For this being possible it is necessary to follow the infrastructural and functional particularities of YaST as well as some guidelines regarding the interaction of the module with the user and the rest of the system. In the following we'll have a closer look at these topics .
Throughout this document the term “YCP module” was mentioned repeatedly without providing a sharp definition. In fact the term “module” is used quite loosely in the YaST world, because there are several kinds of modules involved in different contexts. The following text shall lighten this topic.
Different kinds of YCP modules
Generic YCP modules
In principle every YCP file that provides a distinct functionality can be seen as a module. Typical representatives of this kind of module are the inst_xxx.ycp files that are part of the YaST installer. Modules of this kind mostly represent rather self-contained functionality, e.g like inst_keyboard.ycp that provides the user dialog for selecting a keyboard during installation. These modules are usually called via CallFunction().
Library modules
This kind of module can be seen as what is called a library in other programming languages. Usually these modules are a collection of functions that must be included to be used. As with other programming languages, including in YCP means merely text insertion that takes place each and every time an include is stated. This is often adverse with respect to speed and memory consumption.
True YCP modules
This kind of module is the most interesting one. True modules represent an “object oriented” approach to module design. Because the mechanisms associated with them deserve some special mention, the next section will cover this topic in more detail.
| |  | |
| 5.6. Useful SCR Agents |  | 6.2. True YCP Modules |