[Geany-devel] GProject - the second attempt

[Jiří Techet]

On Fri, Jul 16, 2010 at 19:49, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> 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.

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.

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

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