[Geany-devel] GProject - the second attempt

[Jiří Techet]

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

I wasn't against your idea - I just meant that all the possible
problems should be considered in advance before doing any change.

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

Four months ago I actually didn't know there is Geany. Considering how
good IDE it is, it's a real shame that it's not much more widespread -
in my opinion it's because people just don't know about it. Geany
definitely needs better marketing - maybe Enrico and Nick could start
selling coffee mugs and T-shirts with Geany icon :-).

> 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

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. What I need is to see only those that I'm
going to edit/search. A few examples:

1. At work with the project I'm working on all the source files have
one of the following extensions: C, H, idl. From the CORBA idl files,
headers with the h extension are generated. But I'll never want to
search/edit these files so they shouldn't be included in this
particular project. And of course there are other projects where I
want to see files with the h extension.

2. Let's say you use automake for your project - in this case you want
to see and edit only the Makefile.am files, not Makefile.in and
Makefile. On the other hand, in a different project you don't use
automake and want to edit Makefile directly.

3. For web applications the developers may want to see all .py .php
files while web page designers want to see .html and .css for the very
same project. And for a different project the developers may want to
see all the files.

So in short, I won't implement it this way because it wouldn't fulfill
my and other people's needs. (The default set of patterns could be
made per-plugin configurable though.)

>
> And so, the Geany project patterns will be used, instead of being
> overriden and locked (effectively disabled). As a side effect, the

Direct editing is disabled but they are editable by gproject - the
resulting set of patterns is the union of the three fields in
gproject. These (geany project) patterns are also saved in the project
file so you won't lose them if you create a project by geany with
gproject and open it later with geany without gproject installed.

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

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. On the other hand, when
you select "project" in the combo box, you explicitly say that you
want it this way.

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

Yes, whatever - this was just a quick idea how it might look like (I
wanted to make the combo box as small as possible to have more space
for the patterns).

Cheers,

Jiri

>
> --
> E-gards: Jimmy
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>