latest defaultfile branch

[Dirk Hohndel]

On Sep 15, 2012, at 6:12 AM, Lubomir I. Ivanov wrote:

> On 15 September 2012 14:39, Dirk Hohndel <dirk at hohndel.org> wrote:
>> Oh, the changes are easy - I have this implemented already. But there are
>> some implications… should we move the Import option from "Log" back to
>> "File"?
>> 
>> Linus moved this the other way in commit 3cace090989b with the rationale
>> that importing dives from a dive computer didn't feel like a 'file operation'.
>> Yet of course importing an XML file is just that.
>> 
> 
> i think the question here is - what is the difference between a file
> and a log and how is that related to subsurface document format ?
> one of the first impressions for me was that the import functionality
> is not in "file", so perhaps you are right the application does indeed
> works with files essentially.
> 
> i'm always about long term planning, so where should "export" be
> added? "export" is a potential feature that can allow the user to
> select 10 dives and write them to a file.

That should be easy enough to add...

>> So the options (as I see them) are:
>> 1) have Open not Close the existing file (status quo)
>> 
>> 2) split Import into two menu items:
>> -- Import File (in the File menu)
>> -- Import Dive Computer (in the Log menu)
>> 
>> 3) continue to have just one Import interface, but move it back to File
>> 
>> 4) have Open indeed open a new file and clear out the divelist, but have
>> no easy way to add more dives to your divelist from the File menu
>> 
>> I think I could live with either 2) or 3) - but 1) and 4) seem very inconsistent.
>> 
> 
> imho:
> 
> 1) it should "close the file", clear data and also indicated the new
> name in the app. titlebar.

I implemented that in the defaultfile branch 

> 2) like i've mentioned above one "import" dialog is ok as long as the
> operations it performs are clear.
> 3) one "import" interface is ok as long as the dialog is not
> complicated and there isn't much of a different between the two
> functions. it should have its title "import" only thought,
> generalizing. for the location i would move it to "file".

That I haven't done yet - I'm kinda waiting for Linus to chime in. He just
returned from China and should be caught up enough on the kernel to
check in here again :-)

> 4) "import" (from file) could allow multiple files instead of "open".
> functionality is a bit flipped currently in contrast to other
> software, i think.

There is actually an odd implementation reason for that.
Open uses the straight file chooser dialog that happily works with
multiple files - so that's what we implemented.
Import uses the file chooser button which restricts you to just one file.
But since implementing that we actually changed the UI flow that clicking
OK in the chooser immediately goes on to import the file and close the
import dialog, so this is a restriction that no longer makes any sense -
the user never gets to see the button with the name of the one file that
they selected.

So I'll change this today to not use the FileChooserButton and instead
allow multiple files to be selected and imported.

I'll spend several hours in airplanes without Internet connection (thank
you, United, the only major US carrier that hasn't figured this out, yet),
which should give me plenty of time to implement that :-) 

> sum.:
> - "open" will perform a "close"

And will only open ONE file which becomes the new datafile.

> - one import dialog is fine

Which will support opening multiple files

> - move "import" to file (think about "export" later on), while the
> "log" menu will remain for operations in the list.

This all makes sense to me.

Anyone else with a strong opinion against this? If yes, please speak up
now, before I head to the airport and start implementing this :-)

/D