KDevelop 4/Configuration
From KDevelop
Contents |
[edit] Basic Ideas of KDevelop4 Configuration
- There should be two configuration dialogs.
- A global KDevelop wide configuration dialog that configures things related to non-project specific stuff
- A project configuration dialog that behaves like so:
- With no project loaded, it changes the defaults used for new projects
- With a project loaded, it changes the user's local settings in their .kdev4 folder for the project.
- The global project file should be kept as small as possible.
- Only things that apply to the project as a whole should be there
- project path
- build manager
- project manager view (maybe)
- project name
- Only things that apply to the project as a whole should be there
[edit] How to provide Configurations for Global Dialog
Simply write a KCModule that uses KConfigXT for the actual configuration infos. The only requirement is that KCModule needs to define the X-KDE-ParentApp and X-KDE-ParentComponent properly. What properly is depends on wether the configuration is part of the KDevelop Platform or part of the application.
For a KCModule that is part of KDevPlatform use "kdevplatform" for both settings, for KCModule's that are special to the application use the application name as X-KDE-ParentApp and leave out the X-KDE-ParentComponent or set it also to the application name.
The KCModules will be listed using the KSettings::Dialog from kutils.
[edit] How to provide Configurations for Projects
This is also done via KCModule and KConfigXT, however there are special classes in KDevPlatform that need to be used. There are ProjectConfigSkeleton and ProjectKCModule and are available as part of kdevplatformproject library.
[edit] ProjectKCModule
ProjectKCModule is a template class that expects the classname of the generated config skeleton subclass as parameter. It does some initialization in the config skeleton using the configuration files for the project that are given via the args parameter.
The .desktop file needs to use "kdevplatformproject" in X-KDE-ParentApp and the name of the plugin (as set via X-KDE-PluginInfo-Name) that it configures for X-KDE-ParentComponent.
[edit] ProjectConfigSkeleton
To make it possible to set the project configuration files for reading/writing the project settings there are special steps needed. First the .kcfg file needs to supply arg="true" as parameter for the kcfgfile element, the name parameter must not be set. Secondly the .kcfgc file needs to set Singleton=true, IncludeFiles=projectconfigskeleton.h and Inherits=KDevelop::ProjectConfigSkeleton.
This will make sure that the .kdev4 file in the project directory will be used to set the default values and that any changes are written to a hidden file under the project directory.
The Configuration Dialog for a project can currently only be accessed via a special submenu under Settings listing all open projects. Also the dialog will still include configuration widgets for all plugins that are loaded. This will change once profile support is back in KDevelop4.
Simple examples for both types of configuration modules can be found in the kdevelop sources. A KCModule for a global application setting exists under lib/shell/settings and project specific settings exist under buildtools/builders/qmakebuilder.
[edit] Previous KDevelop 4 Idea
The idea with the current configuration stuff in KDevelop 4 was to make it easy to configure stuff in KDevelop and have it apply in different situations. For example, if there was no project loaded we (manyoso and mattr) wanted the configuration dialog to make modifications to the global configuration that would apply to the overall application, and when new projects were created, those defaults would be passed down to the new project. If a project was open, then those changes would apply to the user's local project settings. The whole point of the current configuration stuff was to ideally, make it easier on the developers since only one configuration widget would be needed for a plugin, part, or language support to cover the whole entire spectrum of things that could be configured and then tweak where the settings are saved based on what "mode" the configuration dialog was in.
20/20 hindsight now tells us that while it's a nice idea, it probably doesn't work too well in practice just yet.
![[Main Page]](/graphics/theme3/KDevelopBigIcon.png)