KDevelop Project Filters
Hey all!
Today, after a bit more than a month since I started working on it, I merged the projectfilter branches into KDevplatform/KDevelop. This is a generic configuration interface and library which allows users to customize which folders/files KDevelop includes in a project.
How to use it
Context Menu
The simplest way to use the new code to exclude items from a project, is to use the context menu. Simply right click on any folder/file (not the project root, or anything target related) and choose the “exclude item from project” action. This will then add a filter for the selected item(s). If you want to undo this, go to the project configuration (see below) and remove the filter.
Configuration
For more advanced management of project filters, or to remove filters and/or adapt the default filters, you need to go to the project configuration and select the new “Project Filter” config page. This allows you to add new filters, remove existing ones or edit them, including reordering them.
How it works
The pattern syntax uses QRegExp::WildcardUnix on relative project paths. This should be fairly easy to grasp and similar to what you know from e.g. .gitignore or svn:ignore. Generally, if you can write a .gitignore file then you should be able to configure your KDevelop project as well!
If you wonder what you can do with the include/exclude pattern type, see again the documentation of .gitignore and it’s !pattern syntax. It allows you to selectively unhide some paths which where previously hidden. E.g. you can only show *.cpp files in your project by first excluding all files * and then adding an inclusive pattern for *.cpp.
Note that the distinction between files/folders is probably not required most of the time. It does allow for some better performance though and may make some patterns more easy to write.
Note to Users-Who-Compile-Master-From-Source
Those of you who build KDevelop/KDevplatfrom from git master, please make sure to remove kcm_kdev_genericprojectmanagersettings.so and just to make sure also remove kcm_kdev_genericprojectmanagersettings.desktop. Otherwise you’ll get the old generic manager configuration alongside the new project filter, which may break things.
If you install KDevelop via the package manager of your distribution, you should have nothing to do but wait until we release a new KDevelop version (4.6) which will then include this new feature!
Anyhow, please test this and report bugs on bugs.kde.org. Feature requests also welcome, but I like that this new UI is rather simple and still powerful. I’m reluctant to add more here. Something which I do want to implement in the future though is support for reading e.g. .gitignore files and hiding files based on that from the project. The new API I added to KDevplatform should make this rather easy btw. You/I just have to write a new plugin implementing the IProjectFilterProvider interface and then we could e.g. query git directly for whether a given path is included or not.
Cheers!
| Attachment | Size |
|---|---|
| kdev-projectfilter-config.png | 83.62 KB |
| kdev-projectfilter-ctxmenu.png | 24.93 KB |
Comments
Want to comment? Send me an email!
Comment by Anonymous (2015-08-17 07:02:00)
The reply to the suggestion about filtering “the project ‘build info’ from project context? I think it is build info, has what looks like a build icon….” was to wait for version 4.6.1.
Now I’m using version 4.7.1 and they still in the project view. Is there a way to remove them?
Comment by vasaka (not verified) (2014-04-23 11:43:00)
Is there a way to exclude files that are not in the project root, it works for dirs, but not for files.
Comment by gary (not verified) (2013-12-21 21:04:00)
is there a way to filter the project ‘build info’ from project context? I think it is build info, has what looks like a build icon. for example: all clean config.o debug install . . . files.h|.cpp
at least to get rid of the build *.o . I have the rule for file types for *.o
thanks
Comment by Milian Wolff (2013-12-22 20:01:00)
This was added just a day after the 4.6.0 release. Please stay tuned for 4.6.1.
Comment by lynxlynx (not verified) (2013-09-04 00:27:00)
Great, finally I’ll be able to exclude the build dir and its crashy extraneus entries in the quickopen completion!
Comment by ben (not verified) (2013-09-03 17:54:00)
Instead of “Type: Inclusive/Exclusive”, I think a better terminology for the third column would be “Action: Include/Exclude”. It would make it easier to understand on first sight.
Comment by Milian Wolff (2013-09-06 01:19:00)
Cool, thanks for the suggestion. I’ll change this now.
Comment by kbroulik (not verified) (2013-09-03 13:34:00)
What I’m really missing at work is a way for KDevelop to not show classes from a specific directory in the Classes browser (the entire library/ folder in my project) but that they are still recognized and presented for auto- completion. I can either completely exclude the directory from the project or have my Class list spammed with classes I don’t need to inspect but only use and see in auto-completion.
Comment by Milian Wolff (2013-09-06 01:17:00)
That you should be able to achieve by excluding the folder, no? You’ll still get auto-completion then. Or what kind of project is that? not C++ but a script language? the situation is different there ;-)
Comment by stativ (not verified) (2013-09-03 10:04:00)
Awesome! I’m playing with it right now and it looks like a very usefull feature. And what would make it even more awesome would be the support for hiding project targets. Especially with autotools-based projects there can be a ton of useless targets.
Comment by stativ (not verified) (2013-09-03 10:09:00)
One more idea - it would be cool if it could read filters from .gitignore (or any other vcs ignore file). I guess this should be handled by the VCS integration, though.
Comment by Milian Wolff (2013-09-06 01:18:00)
Yeah, read my blog post above. This is also something I had in mind.
Comment by stativ (not verified) (2013-09-06 20:04:00)
Oh, I’m sorry. I missed that because I thought the last section is only about compiling, which was something I have already done so I skipped it. Anyway, it’s great to hear that you already considered this option. I’m looking forward to the future development.