[Geany-devel] [PATCH 12/19] Use relative paths in the project files

[Jiří Techet]

On Thu, Aug 5, 2010 at 13:50, Lex Trotman <elextr at gmail.com> wrote:
> On 5 August 2010 21:20, Jiří Techet <techet at gmail.com> wrote:
>>>> Sure, I had this in mind - but the patch is completely independent of
>>>> where the project file is located. So for instance if you have:
>>>>
>>>> ~/foo.geany
>>>> and project directory is in: ~/projects/foo
>>>> then foo.geany refers to files as: ./projects/foo
>>>
>>>
>>> But then how does it work when I move projects/foo somewhere,
>>> foo.geany is again disconnected.  Thats why I suggested that the
>>> project file had to move with the project tree so the relative
>>> addresses kept working.
>>
>> Yes, that's true. Clearly both ways of doing it have some advantages
>> and some disadvantages. The disadvantage of your solution is that the
>> thing like renaming the projects directory I mentioned in my last
>> example wouldn't work. For me, relative paths are better (I can move
>> the project to different accounts with different home directory and
>> directory structure) but I can imagine that for someone who often
>> moves the project file relatively to the project directory, absolute
>> paths are better. But is the latter really common real-life use case
>> scenario? If so, a configuration option should be introduced.
>>
>
> Oh, I agree that relative paths with everything in the project tree are fine.
>
> And I want to be able to move project trees, its quite common, so I am
> happy you are trying to fix the problem.
>
> But for the reasons given previously I don't keep the project file in
> the tree.  Therefore all moves or renames of project directories break
> the project file irrespective of absolute or relative paths.
>
> And the Geany default is to keep the project file out of the tree.
>
>
>>>
>>> Maybe the paths in foo.geany should be relative to the project base
>>> directory, not the project file, then if you move the project you only
>>> have to correct the base directory and it will all work again.
>>
>> Sure, can be done, but this won't do what you expect would happen. Why:
>>
>> 1. Move the project file so the paths become invalid.
>> 2. Load the project (none of the files opens because the paths are invalid)
>> 3. Edit the base directory.
>> 4. Save the project file - this saves all the open documents but
>> because there are none of them open, it just clears the list in the
>> project file.
>>
>> This would only work if you edit the project file manually before you open it.
>
> True it would need to re-try the file list after the edit of the base
> directory, maybe a reload files tick box on the project properties?
> The file list should not have been overwritten at this stage.

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:

1. 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)
2. Use full paths for files outside of the project directory (relative
paths couldn't be used for open files from other volumes)
3. Use full paths for the session file (already works this way)
4. 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)

Cheers,

Jiri

>
> Cheers
> Lex
>