On Fri, 16 Jul 2010 15:14:04 +0200 Jiří Techet techet@gmail.com wrote:
On Wed, Jul 14, 2010 at 21:11, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 12 Jul 2010 13:21:03 +0200
The global gproject pattern settings should _only_ be used to classify what files are source and what are header, since gproject needs this data. These settings are _not_ the project patterns. I'll refer to them as "extensions" (they should be probably implemented as patterns for flexibility).
The project patterns, OHOH, are entered as a single list in the Geany project patterns field (currently not displayed). gproject reads them, searches the project directory, and for each file found looks in the gproject h/s settings to classify it as "source", "header" or "other".
OK, I understand now. This would kind of work but I'm afraid there are some usability problems:
- The list of known source extensions would have to be long. This
isn't such a big problem for headers because there is a limited set of extensions used for headers, but there are lots of source file extensions. At least there should be all the extensions from filetype_extensions.conf and possibly others. Such a list makes it very hard to find whether the given extension is present so the user may easily re-introduce the same patterns several times making the list even longer.
Yes, that's why a proposed a buildin list at first. That is, the plugin source contains the lots of well-known source/header extensions, and the edit fields are only used for appending (or overriding, for example .h in the sources field).
- Instead of one place where the user configures patterns there would
be three different places now - the plugin configuration, and two tabs in the project properties dialog. It would be much easier for the user to get lost.
The file type configuration should be rare. With buildin types, edit fields should suffice, if that's what you mean by two tabs.
- For human brain it is easier to understand union than intersection.
With current gproject the list of project patterns is headers AND sources AND others. You clearly see what headers, sources others are. In what you propose it's not so clear:
headers = global_headers INTERSECT project_patterns, sources = global_sources INTERSECT project_patterns, others = project_patterns - global_sources - global_headers
Yes. However, once the exotic extensions are entered in the gproject s/h fields, which is likely to happen with the first few projects, the user will only care about a single flat list. With per-project patterns, the s/h/o will have to be repeated for each new project.
- From the above you can see you have very little control over the
others patterns. Even though it's not the most important feature of the plugin, I like to keep the others list minimal to easily see some special files in the sidebar - these can be makefiles, installation scripts, documentation files - basically whatever the user considers special for the given project - and these can be different for different projects.
What is the problem? Just cut the project patterns to what you want for the project, others = _project_ - sources - headers. I gave an example with "*" only to signify that separating inclusion and classification adds some flexibility (like *.r* instead of *.rc *.rh)
So unless I get NACK from Nick, I would still prefer to be able to override the list of patterns from a plugin. But I'll keep your idea in mind as a backup solution.
We agree to disagree (always wanted to say that:) Needless to say, as the plugin author, the decision is yours.
Well, the 3-state combo is a bit clumsy and unusual, but I can live with that.
Is it so unusual? I find it quite standard. I used the combo instead of radio button because it occupies less vertical space, but conceptually they are almost equivalent IMO.
Unusual for a Find in files function, not by itself.