On Fri, Jul 16, 2010 at 19:49, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
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.
The problem is that you still have to remember that there are some global options and what patterns are set there and possibly have to update the other settings too. Also this would make your project settings unportable - if you move your project file somewhere (or to someone) else, you'll have to re-set the global options on the other machine too to see the same.
- 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)
No, what I'm talking about is when you want to see some files, but want to see them as others instead of sources/headers. For instance, the pattern *.sh will be stored in the global options in the sources field. In some projects you want to see these files really as sources, but in others these will be just some auxiliary scripts used for e.g. setting up the build environment and you'll want to see them as "others". No problem with gproject, but would be a problem with what you propose.
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.
I understand what you have in mind but when thinking about it I'm afraid that it might bring more confusion/inflexibility than the current state.
When talking about bad news, I'm afraid I have also discarded your idea with bookmark folders. I want to keep the plugin simple and straightforward and again I'm afraid the "virtual" folders might bring more bad than good. Now the sidebar displays just the filtered list of project files and I want to keep it as simple as that without any extra settings.
Cheers,
Jiri
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.
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel