request for review and testing: default file name

[Dirk Hohndel]

Mikko Rasa <tdb at tdb.fi> writes:

> On 10.09.2012 17:30, Dirk Hohndel wrote:
>>
>> On Sep 9, 2012, at 11:05 PM, Henrik Brautaset Aronsen wrote:
>>
>>> Den 10.09.12 02:43, skrev Dirk Hohndel:
>>>> This is reasonably well tested on Linux and somewhat tested on
>>>> MacOS. Completely untested (beyond compliling) on Windows.
>>>>
>>>> I /think/ it implements a reasonable logic:
>>>>
>>>> if filenames are given, everything is like today.
>>>> if no filename is given, it attempts to open the default file and sets
>>>> it (even if the open failed) as the existing file name (so a first time
>>>> user will get that as the default name when savin).
>>>> The preferences dialog allows a change of the default file location.
>>>>
>>>> I'd especially appreciate feedback from Mac and Windows users - and of
>>>> course general code review.
>>>
>>> Hi Dirk.
>>>
>>> I can't quite get it to work:
>>>
>>> 1) Open Subsurface
>>> 2) In Preferences, verify that ~/Library/Application Support/Subsurface/henrik.xml is selected
>>> 3) Log » Import » XML file » test1.xml
>>> 4) Save
>>> 5) Quit
>>> 6) Re-open Subsurface
>>> 7) No log is opened?!
>>>
>>> There's nothing written to ~/Library/Application Support/Subsurface/henrik.xml either (but the folder is created). And if I leave out 4), Subsurface doesn't ask me to save.
>>
>> I'll track this down. It's one of the thing that I tested in the process, but as usual some later "fix" may have broken it again.
>
> An strace reveals that it's saving over the imported file.  For me, it's 
> not even creating any directories in this case.

That is a rather obvious "feature" in the existing code that I hadn't
noticed, yet. Whenever a new XML file is openend (through an import or
file open) it rather rudely assumes that THIS must be the file to use
for everything and overwrites the existing_filename. Not nice at all.

> If I import dives from my dive computer instead, subsurface creates the 
> directory ~/subsurface with 0600 permissions, and then fails to save the 
> file because the directory lacks the execute permission bit.  The 
> failure is not communicated to the user in any way.

Oops. Silly me.

> After correcting the permissions, the file gets saved and then loaded on 
> a subsequent startup.

Ok, so something is working...

> I don't know if I like the correct behavior.  When I start an 
> application in a blank state, do some changes, and tell it to save my 
> work, I expect to be asked where to save it.  Perhaps just saving files 
> somewhere is the way the industry is heading, with cloud computing and 
> all, but until a more advanced FS comes along that lets me search for 
> files based on the program that created them, I'd like to be in control 
> of where the files are saved.

Yeah, that is this fundamental design decision.

Do we see Subsurface as a program that normally is used by people who
have a need for more than one dive database?

My assumption has always been that the typical user would track only
their own dives and do so in one file - and would be happy if we made
this as easy and painfree from them as possible.

Now let's assume that user wants to look at someone else's dives for a
change. With the way things are setup now (in my defaultfile branch)
this won't work - we are missing the close function to stop using one
file and start using another one.

We'd close the current file (and save if necessary). We'd open the new
file and mark that as the existing_filename. We'd (hopefully) do the
right thing when saving.

All that behavior still makes perfect sense to me.


What we don't get is the nice "two user" setup that was requested - with
multiple files that one could easily switch between.

Is this something that a lot of people will use? I can think of a couple
of ways to implement such a multi database scenario; one of them would
be the 'recent file' option suggested by a few people here, but I'm not
a huge fan of that idea.

I'd rather have the user set up "number of subsurface data files to
track" in the preferences, give each file a nickname and then have the
option in the file menu to switch between those nicknames...

/D