Patch: TODO highlighting in comments
apaku at gmx.de
Sun Oct 17 08:20:25 UTC 2010
On 17.10.10 02:43:14, Ciprian Ciubotariu wrote:
> Though perhaps a bit off-topic, I'd like to use the opportunity to add some
> thoughts on having configuration levels and a system for overriding these as
> the scope tightens. I've mentioned this idea on IRC (I am CMoH on IRC btw) but
> didn't raise any comments.
> Here is what I'd expect from the IDE's configuration framework:
> 1. application-level configuration
> 2. session-level configuration
> 3. project-level configuration
> 4. perhaps file level, but I've seldom used such a feature except in those
> nasty IDEs that also handle the build themselves
Actually it should be app-level < session-level < project-level <
developer-level. The last one is whats stored inside
<project/.kdev4/<project>.kdev4. The project stuff is in the
top-level <project>.kdev4. File-level is totally useless except for a
very few things and for those rare cases having a way of just writing a
special config file somewhere should be enough.
> Each level is the default for the higher levels, where level 1 (application
> level) would define a value for all options. Each level above would allow me to
> override the values supplied by the previous level, or to reset my change.
> There's also the question on where to store transient configs, like session
> open windows, current window layout, currently selected filter in the TODO
> window and similar stuff.
> Would you find idea this useful? Does it stand any chance within the current
> KCM design (I haven't even saw its API)?
We actually had a start of that about 2-3 years back. It was quite a
hack and had no suitable GUI either. So basically this merely depends on
writing a suitable GUI to move options up/down and someone finding a
suitable way of implementing this with KConfig or write a KConfig
replacement which does support what we need. The project-kcm's and the
IProject::projectConfiguration() does some cascading already, but
especially the kcm-config-setup with The ProjectKCModule and
ProjectConfigSkeleton is quite cumbersome and error-prone.
Good day to let down old friends who need help.
More information about the KDevelop-devel