On Fri, 9 Jul 2010 23:36:06 +0200 Jiří Techet techet@gmail.com wrote:
On Fri, Jul 9, 2010 at 19:49, Dimitar Zhekov dimitar.zhekov@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...
- 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.)