> On April 1, 2015, 4:44 nachm., 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?
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) - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123211/#review78359 ----------------------------------------------------------- On April 1, 2015, 3:27 nachm., 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 nachm.) > > > 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
