Project

General

Profile

Bug #8786

Wording: Mixed use of "Folder" and "Directory" in export module's variables.

Added by Richard Wonka over 7 years ago.

Status:
Fixed
Priority:
Medium
Category:
Lighttable
Start date:
06/17/2012
Due date:
% Done:

100%

Estimated time:
Affected Version:
git development version
System:
bitness:
64-bit
hardware architecture:
amd64/x86

Description

In the code, I don't think this is a problem. In the GUI, I think it would clean things up nicely to use only one of the terms (at least mostly) but in the export module it has been mildly annoying a few times now. What was it again? $(HOME_FOLDER) or $(HOME_DIRECTORY)?

Annoying enough to intervene.

I have updated the wording branch to reflect this change in the export variables.

I have in this case unified things to DIR, simply because it's shorter and will render the resulting paths in the export modules more legible.

History

#1 Updated by Jérémy Rosen over 7 years ago

hmmm, it seems you havn't pushed to github (nor asked for a pull request) I am also a bit worried that this change might break existing presets... but since I don't see your change I can't check at this point

#2 Updated by Richard Wonka over 7 years ago

It will break existing presets. So I think it might be politically better off for a major release.

#3 Updated by Richard Wonka over 7 years ago

I have also removed the FOLDER/DIRECTORY suffix from DESKTOP and HOME. Legibility will thank us. :-)

Have pushed the wording branch now.

#4 Updated by Simon Spannagel over 7 years ago

  • Target version set to Candidate for next minor release

#5 Updated by Richard Wonka over 7 years ago

It should™ be relatively simple to construct an updater that adjusts existing presets, right?

How would one go about this?

on_startup() {
  for i in `look for look for legacy presets in the DB` : do
    sed $i s/$OLD_VARNAME/$NEW_VARNAME/ 
    `update DB with new preset`
  done
}

I know the pseudo code is very pseudo - I just want to understand.

This could be kept in the code until, say the next major release.. once done it would only add one DB query with an empty result to the runtime.

Yes?

#6 Updated by Tobias Ellinghaus over 7 years ago

Since we are breaking backwards compatibility in master all the time I wouldn't be too concerned with it and surely wouldn't invest any time in writing extra code to handle it.

#7 Updated by Jérémy Rosen over 7 years ago

shouldn't be very hard with the existing update_param callback... i'll have a look

#8 Updated by Simon Spannagel over 7 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Fixed

Any news on this?
I think your wording branch has been merged, Richard, right? So I close this issue.

#9 Updated by Jérémy Rosen over 7 years ago

  • Assignee set to Jérémy Rosen

yes, my bad, I should have closed the issue, but I forgot to

sorry about that

(assigning the bug to me since I was the one to merge, in case it's needed for historical reference)

Also available in: Atom PDF

Go to top