Page MenuHome

Fix T86231: Saving startup file always remaps relative
AbandonedPublic

Authored by Philipp Oeser (lichtwerk) on Mar 3 2021, 4:36 PM.

Details

Summary

This was reported for a particular path (a custom brush icon) that
changed from an absolute path to a relative path.

Behavior changed in rB3ada1949f863 (with no real reasoning why this
should change).

Now change back to have no remapping take place when saving the startup
file

Diff Detail

Repository
rB Blender
Branch
T86231 (branched from master)
Build Status
Buildable 13232
Build 13232: arc lint + arc unit

Event Timeline

Philipp Oeser (lichtwerk) requested review of this revision.Mar 3 2021, 4:36 PM
Philipp Oeser (lichtwerk) created this revision.

Firstly, the behavior from T86231 isn't good, but I don't think this fix is right either.

Some explanation for whats going on.

  • NONE has the problem that existing relative paths won't be properly updated. (the paths will be broken).
  • RELATIVE was used as the default, so paths that are relative are corrected.
  • There is a special check that makes RELATIVE into RELATIVE_ALL if the file had not yet been saved.

    This is done because anyone who prefers to use relative paths but has not yet saved the file, would get no relative paths, so in this particular case it uses relative all.

    When saving the startup, we don't want this, so I think the fix is to make saving the startup file an exception, for example: P2012 or move logic to a higher level: P2013

Firstly, the behavior from T86231 isn't good, but I don't think this fix is right either.

Some explanation for whats going on.

  • NONE has the problem that existing relative paths won't be properly updated. (the paths will be broken).
  • RELATIVE was used as the default, so paths that are relative are corrected.
  • There is a special check that makes RELATIVE into RELATIVE_ALL if the file had not yet been saved.

    This is done because anyone who prefers to use relative paths but has not yet saved the file, would get no relative paths, so in this particular case it uses relative all.

    When saving the startup, we don't want this, so I think the fix is to make saving the startup file an exception, for example: P2012 or move logic to a higher level: P2013

Sounds good, thx for the explanation, will abandon this patch then.

To follow up on this topic, at first P2013 seemed reasonable. However as the startup file doesn't set a valid base path on load, all paths should be absolute.

Also use save-as-copy, so as not to modify paths of the current file when saving it as a startup file.