Fwd: Re: Saving changes

[Willem Ferguson]

-------- Original Message --------
Subject: 	Re: Saving changes
Date: 	Wed, 02 Jul 2014 17:59:51 +0200
From: 	Willem Ferguson <willemferguson at zoology.up.ac.za>
Reply-To: 	willemferguson at zoology.up.ac.za
Organization: 	University of Pretoria
To: 	Robert Helling <helling at atdotde.de>



On 02/07/2014 17:39, Robert Helling wrote:
>
> On 02.07.2014, at 16:23, Dirk Hohndel <dirk at hohndel.org 
> <mailto:dirk at hohndel.org>> wrote:
>
> Hi,
>
>> I agree, we could be smarter and more consistent about when we show the
>> Save/Cancel buttons.
>
> I only see a small problem: The buttons (cancel, save) are there for 
> edits of information of a single dive (what you do in the tabs) while 
> actions from the dive list context menu (renumbering, adding pictures, 
> shifting times, assigning to trips) potentially operate on the list of 
> all selected dives.
>
> Plus the meaning of "Save" on the button does _not_ mean "save to 
> disk" but it means "commit to dive list" while the context menu 
> entries quasi per definition act on the dive list.
>
> So, I maintain, we are consistent: Button action transfers info from 
> tab to dive list. To save the dive list to disk use the Ctrl-S and 
> equivalents.
>
> To get rid of any confusion we might rename the button to "Commit 
> changes to dive list". Then nobody thinks anything is written to disk.
>
> What do you think?
>
> Best
> Robert
>
> The issue is that the Save/Cancel buttons come up purely by only 
> focusing on the dive notes tab. I have come to live with it, even 
> though it is inconvenient. But the optimal solution would be for the 
> Save/Cancel buttons to come up the moment when a character is 
> inserted, changed  or deleted from the dive notes tab, not merely by 
> focusing on the tab.
Kind regards,
willem



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140702/e2e5e186/attachment-0001.html>