Confirmation for deletion of files in Dolphin settings also affects Gwenview

Michael Mikowski z_mikowski at yahoo.com
Fri Jun 14 15:45:49 BST 2013


I understand your point Frank.  Let me add though that it is common to open and compare two settings dialogs *from two distinct apps* with the reasonable expectation that they orthogonal.

Some don't think of this kind of situation as a true race condition, but I think it is a fair classification.  Consider the Wikipedia discussion: "A race condition or race hazard is the behavior of an electronic or software system where the output is dependent on the sequence or timing of other uncontrollable events." Our "uncontrollable events" occur when the user changes and commits the shared setting value from either the dolphin or gwenview dialogs.

This is the first example of a defective user experience with this race condition I could think of.  It is likely there are many others.

In any event, what you are proposing is certainly an improvement, and is probably the best near-term solution.  Longer term, I think it certainly makes sense to consider merging the apps.

Cheers, Mike

Frank Reininghaus <frank78ac at googlemail.com> wrote:

>Hi,
>
>2013/6/14 Michael Mikowski:
>> Example race condition:
>>
>> 1. the user has both applications open at the same time
>>
>> 2. The user in one application clicks on confirmed to delete
>>
>>  3. The second application configuration dialogue is not updated to reflect that of the first.
>
>thanks for the explanation! Preventing this is not really trivial
>though. Moreover, the same issue happens already now when you open two
>Dolphin instances and open the settings dialog in both of them (and I
>guess that many apps have similar problems when you open their
>settings dialog twice at the same time). I'd say that this "race
>condition" probably happens rarely enough, and even if it does, it's
>unlikely to cause big problems like data loss. If a user opens two
>settings dialogs and disables the "delete confirmation" in one of
>them, he/she should know what might happen. Therefore, I think that
>investing hours or even days into this does not make much sense, given
>how little time we have to improve KDE and how many other unsolved
>issues there are.
>
>Cheers,
>Frank


More information about the kfm-devel mailing list