Patch: TODO highlighting in comments

Andreas Pakulat 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.

Andreas

-- 
Good day to let down old friends who need help.




More information about the KDevelop-devel mailing list