[Geany-devel] GProject - the second attempt

[Dimitar Zhekov]

On Fri, 9 Jul 2010 23:36:06 +0200
Jiří Techet <techet at gmail.com> wrote:

> On Fri, Jul 9, 2010 at 19:49, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> > On Sun, 4 Jul 2010 00:54:17 +0200
> > 
> > I haven't tested, so correct me if I'm wrong, but it looks like it'll
> > convert even paths outside the project directory, resulting in names
> > like "../../testing/gsm/CHANGES". So if I move the project in a
> 
> Right.
> 
> > different directory on the same machine, it's quite possble that
> > all ../ names will become invalid, while absolute names would have
> > been OK.
> 
> Precisely, I'm aware of that. Both absolute and relative paths have
> some advantages and some disadvantages, but in my opinion the relative
> paths are more useful.
> 
> >
> > The reasonable compromise, IMHO, will be to use relative names for the
> > files under the project directory only.
> 
> Good idea, should be possible. On the other hand there are some cases
> where this wouldn't work. E.g. when you rename your projects
> directory, where you keep all your projects and the referenced
> external files are from other project in that directory.

The renaming of the main projects directory should be rare. But with
alls path relative, any movement of the project up or down in the
directory hierarhy will break all non-project paths, and movement at
the same level can break some of them (for example moving the project
directory from projects/ to backups/ will make the external files from
other project invalid).

The reason to use relative paths is to preserve the project file
names. What happens to the non-project files, we can not tell, and
should not try to guess IMHO.

(and it's just against my aesthetical sense to have paths like
"../../../../../usr/include/gtk-2.0/gdk/gdkevents.h":)

> > But the real question, as pointed out by Lex, is about the ammount of
> > plugin intergation. I see that you got an "OK" from Nick for this -
> > perhaps I should request access to the Edit menu, which contains all
> > the Insert-Some-Text functions, and put the Insert Numbers [from
> > geanyinsertnum] there?..
> 
> Not a question to me I guess.

Of course not, and not to me either, since I'm a very recent member of
the list. Enrico / Nick / Frank should decide on that - and the thread
suggests that Nick is willing to allow some more integration.

> >>     Plugins can override project patterns. In that case the "file patterns"
> >>     field is made inactive in the Project tab of the project properties
> >>     dialog.
> >
> > Can you please remind me what was the reason for that?
> 
> Have a look at the screenshot I posted in the first email of this thread.

I remember the fields from gproject one, but something was bugging me...

> 
> 1. The file icons in the sidebar differ for different pattern groups
> (headers, sources, others). I find it very useful to distinguish
> quickly between different kinds of files.
> 2. Header/sources patterns are used for the "swap header/source"
> feature (others files are skipped from that)
> 3. All the patterns combined are used for the FIF dialog.

...and it finally came out at the top of my mind.

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.

In short:

gproject plugin - global list of source and header types, for swapping
and icons

geany project - all patterns for the current project; most of them
will match some source or header type

gproject project - ignore dirs patterns

And so, the Geany project patterns will be used, instead of being
overriden and locked (effectively disabled). As a side effect, the
user types will only need to be classified as source / header once.

> >>     It should be considered whether the "files" checkbox should exist
> >
> > Indeed. If patterns are entered in the edit field, there are patterns.
> > If the field is empty, there are no patterns. FIF may (and probably
> > does) work in a different way with patterns, but there's no such
> > tooltip or any other suggestion related to the Files checkbox. And if
> > there was, it could be have been displayed directly for the edit field.
> 
> Again, the screenshots of FIF I sent to Nick are one more way how how
> the dialog could look like.

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.

("All" should be "All files" IMO - it took me a few seconds to
understand what it means, and a regular used will probably wounder.)

-- 
E-gards: Jimmy