> From: g...@ir.bbn.com
> Robert Norris <rw_nor...@hotmail.com> writes:
>> In order to support Relative Filenames (within primarily Viking files)
>> and to (re)opening from where one last opened a file,
>> Viking changes it's working directory to the last successfully opened
>> directory.
> At first glance this sounds broken.

Yes, in fact it is.

>> In the specific use case above, this can be worked around using pwd to
>> ensure a full path filename is used e.g.:
>> viking gpx.viking `pwd`/ETREX30-archive/2013-10-01\ *
> That's a very unusual user interface. I have never seen another
> command-line program that took multiple filenames where each filename
> was interpreted relative to the previous directory.

This is just a workaround for this specific Viking 1.5 release.

>> See commit "SF#3028797: Remember last directory used when saving /
>> opening main files." for when this was introduced:
>> https://sourceforge.net/p/viking/code/ci/317298355967f8465d2ddff8ae61b428a188778f
>> Perhaps to the best way is mitigate this issue is to only change the
>> directory only when opening a .vik file type.
> Perhaps the previous-directory behavior should be strictly limited to
> the cases where it is documented to do that. I wonder if there is prior
> art in other programs, and if some token in filenames should mean
> relative to the .vik file. But I can see how all filenames that don't
> start with / in a .vik file should perhaps be relative to the .vik.

After some thought, I think I was conflating two issues - such that the change 
directory "answer", works only in limited cases.

In the code, the use of GTK function gtk_file_chooser_set_current_folder() on 
opening files via the GUI, should address the SourceForge issue above - the 
change directory is I think unnecessary for this. 

Then to support relative paths, change to the directory when opening a .vik 
file but then simply return to the previous working directory (which it does 
not do ATM) so there no unintentional side effects.

Thank you for taking time to report this issue.

I will incorporate this fix in v1.5.1 with some other small fixes.              
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
Viking-devel mailing list
Viking home page: http://viking.sf.net/

Reply via email to