[Geany-devel] GProject - the second attempt

[Dimitar Zhekov]

On Mon, 12 Jul 2010 13:21:03 +0200
Jiří Techet <techet at gmail.com> wrote:

> On Sun, Jul 11, 2010 at 15:19, Dimitar Zhekov <dimitar.zhekov at 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.

> > 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, the 3-state combo is a bit clumsy and unusual, but I can live with
that.

-- 
E-gards: Jimmy