On Wed, Jul 14, 2010 at 21:11, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 12 Jul 2010 13:21:03 +0200 Jiří Techet techet@gmail.com wrote:
On Sun, Jul 11, 2010 at 15:19, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 9 Jul 2010 23:36:06 +0200
Why have per-project source / header list, instead of global? No matter the project, it's quite unlikely that a .c file will ever become a header, or .h will be source. You can move Source and Header files at plugin level, put there long lists of well-known source and header files, and let the user edit them.
This won't work. The main reason why the patterns are present is not to include as many files to the project as possible (one could use * then), but to get rid of as many uninteresting files as possible. In what you suggest all the source files would be visible in the project
- but I don't want that. [...]
Ah, my explanation wasn't clear enough. 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".
For example:
gproject sources - "*.c *.cpp *.s *.idl...", whatever list of well-known source extensions you come with.
gproject headers - "*.h *.hpp ...", personally I'll add "*.def *.dgl".
Geany patterns for a particular project: "*.c *.h Makefile.*".
Techically, in a such scheme Geany will fully support/control the project patterns which can be also be used by Geany FIF and and other plugins; while gproject will contain the file type classification, which is only used by gproject.
From users POV, I won't need to create 3 patterns for each project, always specifying that "*.h" is header, "*.c" is source, and "Makefile.*" is other. The last pattern does not match any gproject directly; when using a separate build directory, I can even specify a single "*", and gproject will still classify the files properly. :)
The limitation of the global classification is, of course, that it's global. So you won't be able to specify "*.h" as header files for the normal projects, and as "source" for a specific project, like your first example (.idl -> .h). But in the example, you don't want to see them, and they are not real "source" files anywas. In fact, I know not of any "questionable" extensions, and my guess (which can of course be wrong) is that they are uncommon enough not to pose a problem for a single user.
OK, I understand now. This would kind of work but I'm afraid there are some usability problems:
1. 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.
2. 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.
3. 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
4. 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.
5. I still have some feeling that the global list might cause problems in certain situations. I can't give you any example though so maybe the feeling is just irrational...
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.
I think someone already suggested it, but how about a single push button, with the Copy icon for example, that'll copy the project patterns in the edit field? Even make it "autoclick" when a project is loaded. Switching forth to Project and back to Custom seems a bit clumsy.
The reason why I would prefer it the way I suggested is that if you select project, the patterns will be updated automatically whenever you load a project. I'm afraid that the "autoclick" feature would be more confusing/annoying if you specify your custom patterns and they get overwritten every time you load a project.
The custom patterns will be saved in the history; when switching to another project, chances are that I'll want it's patterns, at least as a starting point for customization.
On the other hand, when you select "project" in the combo box, you explicitly say that you want it this way.
Yes. But to remove a single pattern, you need to select "Project" to fill the text entry, then "Custom", and only then edit the list.
Well, for a project you should specify those patterns that you want to use for searching most frequently. Manual overriding the patterns should not be common. On the other hand with the "project" option selected, you can be sure that whenever you load a project, the pattern list will correspond to the project and you don't have to think about updating patterns for the project. When no project is loaded, the "project" option does the same like "all" (the pattern entry becomes empty - I have fixed the "formally correct" feature so empty entry means "all").
I have the "project" option selected almost all the time - I don't have to care about updating patterns when a new project is loaded, it does a sane thing when no project is loaded and I search in customized patterns only rarely (e.g. when I want to search headers only) so it's no problem to switch from "project" to "custom" in these cases.
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.
Regards,
Jiri
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel