[Geany-devel] GProject - the second attempt

Fri Jul 16 13:14:04 UTC 2010

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

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 at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>