working towards Subsurface 2.0

[Dirk Hohndel]

On Sep 9, 2012, at 3:30 AM, Lubomir I. Ivanov wrote:

> On 9 September 2012 05:33, Lutz Vieweg <lvml at 5t9.de> wrote:
>> On 09/08/2012 04:11 PM, Dirk Hohndel wrote:
>>> 
>>> So people would prefer something like ~/subsurface_dives.xml to us
>>> creating a directory?
>> 
>> 
>> I do.
>> 
>> 
>>> I dislike cluttering the user's home directory...
>> 
>> 
>> Adding one file to $HOME does not clutter that directory any more than
>> adding one additional subdirectory does. (A directory would make
>> sense if more than one file was usually stored.)
>> 
>> 
>>> This is one of the major shortcomings of Linux as desktop as far as I am
>>> concerned. With everyone doing their own thing, there is no clear structure
>>> and no defaults to rely on.
>> 
>> 
>> I prefer the complexity of freedom to the clear structure of a dictatorship
>> :-)
>> 
>> The default that can be relied upon is that a $HOME directory exists.
>> 
>> Regards,
>> 
>> Lutz Vieweg
>> 
> 
> i think long term planning will really suggest having a
> "~/.subsurface" folder if more than one files have to be wirtten/used
> eventually.

No, dot-folders are for configuration files. I know that some software breaks that rule, but I dislike that.
And funnily enough, Subsurface already uses a dot-folder. Under Linux the config file is in
.gconf/apps/susurface/%gconf.xml

> but somehow i'm missing the point of this feature...
> so basically it will ask the user to save file on exit, but save it to
> this default file location regardless ?

No. The file is supposed to be used as default file if the user simply starts subsurface without a filename (think starting it from a desktop).

> it certainly will work, but i don't think this is application logic
> i've seen before or it could be rare.
> this is more of a backup / protection related functionality and i bet
> 1/5 users will wonder where is this file stored and why. :-)

I definitely don't like the "randomly choose to write to the default file" - and wasn't planning to implement that.

> wouldn't storing a pointer to the last openened file (if exists) in
> the configuration be a more elegant solution via a settings checkbox ?
> this gives the user better control, since _he_ is the one who created
> the file and not the application automatically.

That is an option we could think about.

/D