> 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) > > 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 > > Thomas Pfeiffer wrote: > 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. > > Marco Martin wrote: > yes, I think so. > basically, since we can't really "undo", what would actually do is to > "fake" the removal of the theme or the thing in question and actually do it > on config apply (like for plasmoids at the moment, is "faking" removal as > well) > a similar trick should be employable in several places
@Marco Yes, I will work on it tomorrow. - Antonis ----------------------------------------------------------- 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
