On Sun, Jul 11, 2010 at 15:19, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
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":)
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...
- 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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel