request for review and testing: default file name

[Jef Driesen]

On 2012-09-11 17:15, Dirk Hohndel wrote:
> Jef Driesen <jefdriesen at telenet.be> writes:
>> 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 don't think I misunderstood you. In fact, I think we are going in the 
same direction for most things, but with some subtle differences here 
and there.

What I wanted to say is that currently the settings (e.g. dive computer 
model, visible columns, etc) are stored per system account (e.g. gconf). 
If you for example have configured subsurface for recreational dives, 
and then open a file containing technical dives, subsurface will remain 
in recreational mode. That's because the settings are associated with 
the system account and not the file.

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

Or course you can store the settings in the native format, but that was 
not my point. What I wanted to say that to support a multi-user 
application, you not only need multiple files, but also store the 
settings per file. Saving the settings into a file next to the file with 
the dives was just an example to illustrate the concept. I assume you 
can achieve the same with gconf too.

But today that's not the case, and from your previous emails it was not 
really clear to me that you wanted to change that. I guess that is what 
caused the confusion.

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

Let's say you have a personality A with a certain file X associated. 
What happens if you load another file Y and save it? Does the 
personality A gets linked with the new file Y, or does it stay linked to 
the original file X? What if I adjust the settings after opening Y? Are 
these changes saved to the personality, or are these changes only 
temporary?

With just a weak link between the personality and the data file, I 
think there will be several tricky corner cases. I believe that the only 
way to avoid that is to either make it a permanent, unbreakable link (as 
I described in cases #1 and #2 of my previous mail), or make them 
completely independent (see below).

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

That sounds perfectly fine, except that I wouldn't link the 
"personality" to a (default) filename. The personality as you described 
it here, feels more like a system to create multiple application 
"viewing modes" to me. In this sense it's an extensions to the already 
existing pre-defined layouts (list, profile, info and paned). But 
instead of being limited to the layout, a personality will also store 
the columns, and some other settings.

This sounds like a great idea to me, but I still don't get why you 
would couple this to a specific filename? Let's say I have created a tec 
and rec personality. I think that with your proposal (and correct me if 
I'm wrong) switching personality would also mean switching to another 
file. However with my proposal, opening the file and switching the 
personality are completely independent. You can open your rec (or tec) 
file, and view it with your rec or tec personality. If someone prefers 
to keep both your rec and tec dives in a single file, you can still 
easily switch personality on a per dive basis. Or switch between a 
metric and imperial personality, or...

To easily manage multiple files, I think having the application listing 
the last X files, is as simple as switching between personalities linked 
to files (your proposal).

BTW, I don't see a reason why anyone would create a personality for a 
backup computer. I think the primary purpose of logbook is to track 
dives, not dive computers. If you are using multiple dive computers on a 
single dive, why would you store those as different dives in different 
logbook? I think it makes a lot more sense to support dives with 
multiple profiles in subsurface. But that's another discussion.

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

Sure, no problem.

Jef