request for review and testing: default file name

[Jef Driesen]

On 2012-09-10 21:48, Dirk Hohndel wrote:
> On Sep 10, 2012, at 12:44 PM, Jef Driesen wrote:
>> I'm in favor of a documents based approach. There are several valid 
>> reasons for using multiple files. Multiple divers sharing the same 
>> desktop (e.g. my wife dives too), a technical diver may track 
>> technical dives and recreational dives separately, an instructor 
>> tracking training dives separately from the fun dives, etc.
>>
>> How about remember the last X files, instead of just the last file? 
>> It's common practice in lots of applications (e.g. gedit, evince, 
>> libreoffice, etc) so it should be familiar to users. And it allows 
>> easy switching between the most used files.
>
> But different users may have different settings / preferences.
> Different dive computers. They want to see different columns. In your
> recreational dives you don't care about OTUs but in your tec dives 
> you
> do. Etc.

If the settings are associated with the user account, then all 
documents opened under that account will indeed share the same settings. 
But how is that different from the current situation? The settings are 
already stored per user in gconf.

I think the only alternatives are:

1. Enforce the use of only one file per user account. If you need 
multiple files for whatever reason, you'll need to create a separate 
user account. In this case, using a single filename (fixed or 
configurable in the settings) makes perfect sense to me.

This might be acceptable for the "my wife dives too" case, but 
definitely not for the case where a single users prefers to maintain 
multiple logbooks.

2. Have built-in multi-user support directly in the application. In 
this case the application manages multiple "divers" internally. I 
explicitly used to word "divers" here and not just "files", because I 
believe this will requires more than just supporting multiple files. At 
the mimimum also the settings will have to be stored per diver. For 
example in a directory structure like this:

$HOME/subsurface/<diver>/dives.xml
$HOME/subsurface/<diver>/settings.xml

And then you need some user interface for switching between the 
available divers, add/remove divers, etc. But that's very different from 
the concept of opening/saving files. In this case, I don't think it 
makes any sense to allow the user to customize the filename at all. 
Except maybe for the base directory (e.g. $HOME/subsurface).

This may work very well for the "my wife dives too" case, but I think 
it will also be less convenient and less intuitive for the single user 
with multiple logbooks scenario. I also don't see how you would support 
the ability to open and view standalone files, except for importing them 
into the diver's database of course.

My point is that if you only take into account the filename, I don't 
see any benefits over a pure documents based approach. It only makes 
certain scenarios (some of which we may not even have thought of) more 
difficult, without any real benefits. At least that's how I see it :-)

> So just using multiple filenames works for gedit or libreoffice, but
> in subsurface we have additional context that would also have to
> switch, I think.

Applications like gedit also have additional context. Gedit has several 
settings, like textwrapping, tabstops, line numbers, etc. But these 
influence how the data is viewed and/or interacted with, not the actual 
document content. Let's say I open a logbook with mainly tech dives, and 
my subsurface is configured for recreational dives, then the extra info 
is still there. It's just not shown.

Jef