Location non-edit should not prevent one from selecting another dive

Tomaz Canabrava tcanabrava at kde.org
Wed Aug 26 16:20:00 PDT 2015


On Wed, Aug 26, 2015 at 8:10 PM, Lutz Vieweg <lvml at 5t9.de> wrote:

> On 08/27/2015 12:55 AM, Tomaz Canabrava wrote:
>
>>     I don't know enough about the inner mechanics of that GUI to
>> understand
>>     why this could mean a large-scale change, but isn't binding a press
>>     of the "Enter" key event in an edit field to the same function as when
>>     the "Apply Changes" button is pressed a trivial thing?
>>
>>
>> Not when you are dealing with bulk - changes, for instance:
>> you may have started editing your dive but then realize that you edited
>> the wrong dive
>> hit enter by mistake ( easy to hit ) and you saved your changes
>>
>
> So it takes two mistakes (hitting enter without actually wanting to
> commit plus typing Ctrl-s) to accidentally overwrite one attribute
> of 1 to N dives. And still you want another layer of security by
> requiring a mouse move and button press?
> That seems kind of exaggerated to me... especially if it is only
> one single dive being edited.
>
> Plus, isn't there also an "Undo" function as another safety net?
>
> If somebody really loses data despite all these safety measures,
> Subsurface could display a warning dialog: "Diving is dangerous.
> Fewer mistakes than you just made can cause a fatal accident.
> Please consider more mistake-forgiving recreational activities." ;-)
>

I agree, and that's the reason I'm revisiting this for 5.0
for 4.5 it's too late for a change unfortunately ( mostly because I'm the
main UI developer of subsurface and I'm having almost no spare time to work
on it so we play with what we have )


> Regards,
>
> Lutz Vieweg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150826/3d891bd1/attachment.html>


More information about the subsurface mailing list