> 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? > > 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) > > Marco Martin wrote: > 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
Do you think it would be theoretically possible at least to apply 1) to other KCMs where themes etc. can be installed or removed (at least from an interaction perspective, even if the underlying implememtation would differ)? Accidentally removing e.g. a Plasma theme would be exactly as good or bad as accidentally removing a wallpaper which was downloaded thorugh GHNS, after all. - 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
