On Sat, Aug 7, 2010 at 01:42, Lex Trotman elextr@gmail.com wrote:
I'm a bit worried about having too many special cases (like doing something else when the project file is outside the base directory, especially when it only fixes some problems but introduces another ones) and possibly doing unexpected things (users probably don't expect that files start opening when they edit project properties). So my current preference is:
- Have relative paths as a global option (per-project option isn't
probably needed because every person has usually only one preferred way of storing project files)
Ok
- Use full paths for files outside of the project directory (relative
paths couldn't be used for open files from other volumes)
Ok
- Use full paths for the session file (already works this way)
Ok
- Use relative paths against the project file (IMO using relative
paths against the base directory doesn't solve anything and it's more logical to have all the relative paths against the file in which they are defined)
Good points, neither is a really good solution, so I don't care which you do.
To maintain backward compatibility why not continue to save the absolute paths in [files] and save the relative paths in a separate group in the project file eg [files-relative]. And that way you will know which are relative paths without checking.
That's a very good idea! Saving both relative and absolute path for each file (and base directory) would solve all the problems we have. First the absolute paths would be checked and if not successful, the relative paths would be used. There is some redundancy but this would make all the problems disappear so I think it's worth it.
Cheers,
Jiri
Cheers Lex
Cheers,
Jiri
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel