Review Request 123211: Ask for confirmation before deleting a wallpaper.

[Marco Martin]

> On April 1, 2015, 4:44 p.m., Marco Martin wrote:
> > An undo feature can be done as following:
> > the wallpaper model would have a role like "pendingDeletion" that would be set by the remove button on the thumbnail. At that point the thumbnail can show an undo button based on the role.
> > Upon apply or ok, a "commitDeletion" method would be called on the model instance. this would go trough all the items and do the removeWallpaper on the ones that have the PendingDeletion role set.
> > Cancel would not delete anything.
> > 
> > Antonis, would you feel giving a try on it?
> 
> Thomas Pfeiffer wrote:
>     Interesting approach! All in all, I see three possible approaches here:
>     1. The one you described. 
>       Advantage: Users can make any modification to their decisions before they are committed
>       Disadvantage: If only one wallpaper is removed and nothing else is changed, it still adds another action which would otherwise not be needed
>     2. An undo function that only applies to the most recently removed wallpaper, so really just an "Oops, I didn't mean to do that, Ctrl-Z!" kind of thing, similar to the Plasmoid removal undo. As soon as another one is removed or the dialog is closed, it would not be possible to undo it anymore
>       Advantage: Adds no additional action in case one just removes one wallpaper (not by accident) and does nothing else
>       Disadvantage: Users could still lose their wallpapers if they realize their mistake too late
>     3. Establishing a Trash for wallpapers which contains both the file and the entry in the "database" of wallpapers, which stays until actively emptied by the user
>       Advantage: Adds no further action and it's possible to delete multiple wallpapers in a row and restore them all
>       Disadvantage: Probably the most complex one implementation wise, plus would need a way to show and empty the trash
>       
>     In the end, we should look at this in the context of other areas where undo functionality makes sense and choose the approach that can be applied (at least in a similar way from a user perspective) to the broadest range of cases. The problem this solves is not important enough to create a solution just for this situation alone. It's only worth doing if it can be a model for similar situations (and there are plenty of them)

talking from implementation standpoint 1) would be trivial, 2 and 3 more of a mess (not sure woth the bother doing it for such a minor use case)
as consistency, will always be for the situation in particular alone, every single case is completely different in implementation and i think in what could be shown to the user as well


- Marco


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123211/#review78359
-----------------------------------------------------------


On April 1, 2015, 3:27 p.m., Antonis Tsiapaliokas wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123211/
> -----------------------------------------------------------
> 
> (Updated April 1, 2015, 3:27 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 338729
>     https://bugs.kde.org/show_bug.cgi?id=338729
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> -------
> 
> This patch is adding a confirmation dialog which is being called before we remove a wallpaper.
> 
> 
> Diffs
> -----
> 
>   wallpapers/image/imagepackage/contents/ui/WallpaperDelegate.qml aee2d3f 
>   wallpapers/image/imagepackage/contents/ui/config.qml 2108082 
> 
> Diff: https://git.reviewboard.kde.org/r/123211/diff/
> 
> 
> Testing
> -------
> 
> 
> File Attachments
> ----------------
> 
> dialog
>   https://git.reviewboard.kde.org/media/uploaded/files/2015/04/01/5bfd2d7c-8baa-4b80-ad20-0844aafdb3a9__deletion_dialog.png
> 
> 
> Thanks,
> 
> Antonis Tsiapaliokas
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150401/52272984/attachment.html>