> On Jan. 8, 2011, 11:43 a.m., Sergey Ivanov wrote: > > I think that It's a bad idea to apply any settings when user press Cancel, > > so storing Format Presets should stay in onAccept slot. > > Agree with second statement. > > > > And finally this patch has nothing in common with mentioned Bug Report. > > Philipp Schmidt wrote: > That's the thing. Pressing "Save preset" gives the impression that the > preset has indeed been saved. It has happened to me a couple of times that I > created a new Preset, checked the preview, found something wrong with my > tagging, pressed cancel, corrected the tags and then wanted to use the saved > preset again which was gone... The way I see it both ways are essentially > wrong from a certain Design perspective. > I am by no means a GUI or Usability expert (my expertise comes down to 3 > lectures regarding User Interface Design and Consistency in the user > interface and some small Project in University). But what I learned is that > you should make Dialogs as unambiguous as possible and with respect to that > the discrepancy between the *strong* implication of the preset being "Saved" > and then again not when pressing cancel is very hard to resolve. > > A solution to that would be to add a third button like "Do not move files > but save settings" (Better wording needed :D) or to remove the cancel button > altogether and remove it with something like "Close" that does not imply that > the settings are discarded and save them anyway... Of the two the first > option would probably be preferable as it doesn't remove the Deesktop > Paradigma that Dialogs should have a cancel button that aborts everything it > does. > > With respect to the bugreport: You're right, this review request has > nothing to do with it, but could you then please comment on the bug why you > reopened it? When I was checking in IRC with the person who apparently > initiated that I found all these inconsistencies but not that the bug was > still there.
Well, I still don't like idea to save settings before user pressed Ok. But I agree that "Save preset" button doesn't do what user can expect from It, so probably we should just rename It to "Add preset" or something? - Sergey ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100321/#review771 ----------------------------------------------------------- On Jan. 8, 2011, 12:12 p.m., Philipp Schmidt wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/100321/ > ----------------------------------------------------------- > > (Updated Jan. 8, 2011, 12:12 p.m.) > > > Review request for Amarok. > > > Summary > ------- > > Fixes two errors: > > First: Presets are being saved explicitely, meaning they should persist even > when the Dialog is aborted/canceled. > Second: The state of the Current Collection Directory is saved regardless of > whether the Dialog was accepted or canceled. IMO it should only be saved like > all other values when it is accepted. > > > Diffs > ----- > > ChangeLog 3c337d1 > src/dialogs/OrganizeCollectionDialog.cpp b7d7850 > > Diff: http://git.reviewboard.kde.org/r/100321/diff > > > Testing > ------- > > > Thanks, > > Philipp > >
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
