[Geany-devel] GProject - the second attempt

[Dimitar Zhekov]

On Fri, 16 Jul 2010 15:14:04 +0200
Jiří Techet <techet at gmail.com> wrote:

> On Wed, Jul 14, 2010 at 21:11, Dimitar Zhekov <dimitar.zhekov at 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:
> 
> 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.

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).

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

The file type configuration should be rare. With buildin types, edit
fields should suffice, if that's what you mean by two tabs.

> 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

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.

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

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.

-- 
E-gards: Jimmy