Kexi/Configuration: Difference between revisions
< Kexi
No edit summary |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
Started by [[User:Jstaniek|Jstaniek]] 21:35, 27 November 2011 (UTC) | |||
This page defines requirements for supporting entities of the program(s) that are configurable. | |||
==Levels of configuration== | |||
Three can be at least three levels of configuration defined: | Three can be at least three levels of configuration defined: | ||
*Application level (per user) | *Application level (per user) | ||
| Line 14: | Line 14: | ||
Certain settings can be present at more than one level. Inheritance can occur then. | Certain settings can be present at more than one level. Inheritance can occur then. | ||
==Requirements== | |||
*Requirement 1: good defaults for settings, ie. expected, easy to remeber by user, typical. | *Requirement 1: good defaults for settings, ie. expected, easy to remeber by user, typical. | ||
*Requirement 2: each setting should have assigned level(s) where it belongs to; settings should have described inheritance if it is present | *Requirement 2: each setting should have assigned level(s) where it belongs to; settings should have described inheritance if it is present | ||
| Line 21: | Line 21: | ||
*Requirement 5: The very same configuration system should be accessible to Kexi database/application developers for defining application-specific settings at Kexi, application, and user level | *Requirement 5: The very same configuration system should be accessible to Kexi database/application developers for defining application-specific settings at Kexi, application, and user level | ||
==Status== | |||
KEXI settings are currently (up to 2.4) accessible via kexirc configuration file. No GUI is available because it is clear the configuration system in Kexi would heavily differ compared to document-driven applications. | |||
==Formal documentation== | |||
Current settings are documented in the source code tree, kexi/doc/dev/settings.txt. There is advantage of having formal notation for settings documentation: they can be used for automatic generation of | Current settings are documented in the source code tree, kexi/doc/dev/settings.txt. There is advantage of having formal notation for settings documentation: they can be used for automatic generation of | ||
*handbook page(s) | *handbook page(s) | ||
Latest revision as of 21:13, 17 May 2023
Started by Jstaniek 21:35, 27 November 2011 (UTC)
This page defines requirements for supporting entities of the program(s) that are configurable.
Levels of configuration
Three can be at least three levels of configuration defined:
- Application level (per user)
- Defaults come from Application defaults
- Project level
- Defaults come from Application defaults and project template defaults
- User Project level
- Defaults come from Project's defaults defined for users
Certain settings can be present at more than one level. Inheritance can occur then.
Requirements
- Requirement 1: good defaults for settings, ie. expected, easy to remeber by user, typical.
- Requirement 2: each setting should have assigned level(s) where it belongs to; settings should have described inheritance if it is present
- Requirement 3: settings should be versioned
- Requirement 4: Harmonization with Calligra and KDE settings: typical settings should be harmonized regarding defaults and naming with identical settings in other Calligra and KDE software.
- Requirement 5: The very same configuration system should be accessible to Kexi database/application developers for defining application-specific settings at Kexi, application, and user level
Status
KEXI settings are currently (up to 2.4) accessible via kexirc configuration file. No GUI is available because it is clear the configuration system in Kexi would heavily differ compared to document-driven applications.
Formal documentation
Current settings are documented in the source code tree, kexi/doc/dev/settings.txt. There is advantage of having formal notation for settings documentation: they can be used for automatic generation of
- handbook page(s)
- manual page(s)
- --help messages
- What's this and Tool tips in the GUI
All this with less maintenance overhead. Thus it is reasonable to keep the documentation of settings in the version control system.