request for review and testing: default file name

Dirk Hohndel dirk at hohndel.org
Tue Sep 11 08:15:54 PDT 2012


Jef Driesen <jefdriesen at telenet.be> writes:

> 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.

You misunderstand. Several people here pointed out that they use one
system account to track their own diving and that of their spouse. Or to
separately track recreational and technical diving. And that may mean
different dive computer, different preferences in which columns to
display, etc.

> 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.

That's completely bogus. Don't even go there.

> 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

Certainly not. We are storing the settings in the OS native format for a
reason. 

> 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.

We support that today and it isn't going away. You simply can close the
file you are viewing and open a different one.

> 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 :-)

That is not what is being proposed.

What is proposed is a system where you have can have multiple
personalities in subsurface (I would prefer to use the term 'profile',
but that's already used for the dive profile so it would only cause
confusion). 

Each personality has its own settings and its own default datafile. Of
course you are still able to change the default datafile, to close it,
to open another file, etc.

This is done with a UI inside subsurface. By default you don't see any
of this and everything works as expected for a single user with a single
file (that is likely the vast majority of the users).

In the preferences the user can opt to add another personality which
they can assign a nickname to ("tec" "wife" "backup-computer"). The
preferences then get a new notebook page that is populated with the same
settings the user has right now, but with a different default datafile
(which the user can of course change - initially I'd do it based on the
nickname). When closing subsurface all those settings are saved together
in the native settings system of their OS.

But given that I am trying to get a release out in a couple of weeks I
am hesitant to work on this for now. Instead I will cherry pick the
useful fixes from the current defaultfile branch (as the file handling
right now is quite illogical and at times flat out wrong) and leave the
rest for development work after 2.0.

/D


More information about the subsurface mailing list