Re: Review Request 108995: FIX Pre-amplifier in equalizer doesn't work
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108995/ --- (Updated Feb. 18, 2013, 11:38 a.m.) Review request for Amarok. Description (updated) --- 1. Disabled Pre-amplifier in equalizer if it is not supported by phonon. 2. Fixed top and bottom labels of first slider. Earlier band name label was at the top and slider value label was at the bottom for first slider. 3. Removed an extra semicolon EqualizerDialog.h . Note : I have made an assumption that if at all preamp is present then it will the first element of Effect Parameter list. This addresses bug 301311. https://bugs.kde.org/show_bug.cgi?id=301311 Diffs - src/dialogs/EqualizerDialog.ui 43b0187 src/EngineController.cpp 3577acf src/dialogs/EqualizerDialog.h fd9032b src/dialogs/EqualizerDialog.cpp 63d8209 Diff: http://git.reviewboard.kde.org/r/108995/diff/ Testing --- All unit test cases passed. Note : I have tested it with gstreamer only. Xine phonon keep crashing on my PC. File Attachments Equalizer snapshot http://git.reviewboard.kde.org/media/uploaded/files/2013/02/17/equalizer.png Thanks, Harsh Gupta ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Review Request 105290: Make MusicBrainz tagger more accurate and easy to use
> On Nov. 8, 2012, 12:02 p.m., Matěj Laitl wrote: > > Hi Alberto, > > any news on this? I'd like to merge this when last changes are made for > > 2.7; don't hesitate to tell me that I've put too much work on your back, > > we'll be certainly able to handle that case. Still no updates, Alberto? If you don't have time working on this I think I will pick it up as it contains too much clean-ups and corrections to be missed. - Matěj --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105290/#review21625 --- On Sept. 26, 2012, 12:26 a.m., Alberto Villa wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105290/ > --- > > (Updated Sept. 26, 2012, 12:26 a.m.) > > > Review request for Amarok and Sergey Ivanov. > > > Description > --- > > The attached patch addresses several issues and brings some improvements, > listed below. > > Web service 2 is now being used in place of the deprecated version 1: disc > number and artist credit are now better defined. This alone required a > complete rewrite of MusicBrainzXmlParser.(cpp|h). > > Make track search query more complicated and let it handle some mistakes > (documented in code). > > As in web service 2 multiple artists (e.g., Hans Zimmer & James Newton > Howard) are returned splitted (i.e., they do not have one page, but each one > has its own), the "Go to Artist Page" menu button was changed to a > KActionMenu to support showing a sub list. > > Get track title from release information, as different releases can change > track title (e.g., adding (single edit) or similar). > > Instead of doing *release* requests to get album artist and year, do *release > group* requests. It often means fewer requests will be done (and each one > takes at least 1 second, so...). > See http://tickets.musicbrainz.org/browse/SEARCH-214 and > http://tickets.musicbrainz.org/browse/SEARCH-218 > > Reimplement Levenshtein distance algorithm using a more efficient version > (pirated from Wikibooks as well as the current one). > > Tracks without results are now listed and disabled, to let user know what > results are missing. Prior to this, you had to count them by hand. > > File name is shown in track tooltip. Helpful when existing tags are equivocal. > > Selected results are shown in bold font to be easily spotted. > > Track number, track count, disc number (when existing) and release year > (first release date from the release group, actually) are now shown to help > distinguish among results. This means that all the fetched information is now > shown to the user. > > Tracks are sorted by file name (fair choice). It's done after each insertion, > but since insertions are quite sparse, it doesn't cause any performance > problem. > > Toolbar features "Select Best Matches" and "Deselect", the latter being new, > and the former being moved here from the hidden header button. To keep it not > too wide, Expand and Collapse buttons were modified to be KActionMenu. They > now require two clicks, but are easier to distinguish (I always had to stop > and read them to distinguish between "Collapse All" and "Collapse Chosen", > for example), so the time needed to click them looks mostly the same as > before. > > The progress bar now gets to 100% even if MusicDNS search is disabled. > > All releases per track are processed instead of only the best one. I'll > explain better. Each track is associated to several releases. In current > code, all the releases are parsed, but only the one with the highest score is > returned to the dialog. This excludes lots of good results. Now, all of them > can be returned. This obviously can increase the number of returned resuts, > but that's acceptable given that, before, you were not able to tag a lot of > tracks. Also, two following paragraphs are about two features that mitigate > this "problem". > > Tracks with the same visible information are merged. There's no point in > showing several tracks with same title, artist, album name and artist, album > year, disc number, track count and track number, as the user will not be able > to distinguish among them. Just merge them into only one result, keeping a > list of artist, release and track IDs (they are and will be used). Also, the > score is updated to reflect the higher one. The "Go to ... Page" menu buttons > currently link to the top result (i.e., highest scoring) IDs, but in the > future I might add support for showing a list. > > A "Select Best Matches from This Album" menu button was added. It matches the > top result release ID in other *unselected* results, to make album tagging > much easier. Since a result m
Re: Review Request 108906: Add ability to drag titles to re-arrange them in queue manager
> On Feb. 12, 2013, 2:49 p.m., Matěj Laitl wrote: > > I don't think creating a custom subclass is the right way to implement drag > > & drop support. The right way should be implementing QAbstractItemModel for > > the queue (with drag&drop methods) and then the GUI would automatically > > support it with none or minimal changes. Similar to what Bart said, we > > prefer using the .ui files as much as possible. Also, when the > > QAbstractItemModel approach is used, there should be no need to split the > > patch into 2 review requests. > > Bart Cerneels wrote: > I didn't even consider what the patch is actually supposed to do. Not > completely sure that a QAIM subclass is the best option. D'n'D for moving is > a bit harder then regular dropMimeData. But a model for a list of simple list > of tracks that can be ordered like that could be reused a lot, even after the > big PlaylistQueue refactor. > Not completely sure that a QAIM subclass is the best option. D'n'D for moving > is a bit harder then regular dropMimeData. I still consider implementing QAIM much nicer than reinventing the wheel and implementing the drag & drop at the QWidget level. - Matěj --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108906/#review27302 --- On Feb. 11, 2013, 10:43 a.m., Bartosz Szreder wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108906/ > --- > > (Updated Feb. 11, 2013, 10:43 a.m.) > > > Review request for Amarok. > > > Description > --- > > The new ListWidget (PlaylistQueueEditorListWidget - feeling enterprisey > today) supports drag'n'drop of self-contained ListItems to itself. On > successful dropEvent a signal is emitted, which is intercepted by a new slot > reloadQueue() in PlaylistQueueEditor. This slot in turn recreates the queue > via The::playlistActions(). > > Things to consider in future: > - dragging from the playlist into the queue editor > - making the whole operation more efficient than clearing and recreating > whole queue on each dropEvent > - possibly less hacky way of implementing things? maybe some backend > interface would need to be added/exposed for the queue editor? any advice > from a seasoned Amarok developer would be very valuable > > If this isn't going to be accepted as-is into Amarok codebase then I'm > willing to put some time into reworking the solution. > > > This addresses bug 263563. > https://bugs.kde.org/show_bug.cgi?id=263563 > > > Diffs > - > > src/CMakeLists.txt 043dc64 > src/playlist/PlaylistQueueEditor.h 40b8cdf > src/playlist/PlaylistQueueEditor.cpp f647e37 > > Diff: http://git.reviewboard.kde.org/r/108906/diff/ > > > Testing > --- > > Tested on two different installations, no bugs, regressions or instabilities > noticed. > > > Thanks, > > Bartosz Szreder > > ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Review Request 108686: hidden items in context menu: usability question
> On Feb. 1, 2013, 2:58 a.m., Wyatt Epp wrote: > > "What would be the best approach here?" > > > > Frankly? Scrap it; this is not good interaction. Context menus are rarely > > modifier modal and that's being generous (I have never seen one before > > now). Excepting a very few special cases (e.g. vim), modality is something > > to be avoided. Neither is this sort of menu something Amarok trains users > > for: it only happens with this one of the eight context menu arrangements I > > was able to find in my current layout. > > > > Short term, revert to showing the options as before, with confirmation as > > you see fit. If you're concerned about accidental action, segregate them > > or even put them in a submenu for "permanent actions" or something to that > > effect. > > > > Long term, the aim should be that nothing is possible with a context entry > > that isn't reversible with a simple undo. If, for some reason, things > > cannot be undone, that should be very clear up-front. Is there a > > fundamental reason that move operations aren't able to be undone? On the > > topic of permanent deletion, though I've personally used it in the past, I > > question the necessity of having it in this list. It's not available > > anywhere else in the interface, so its inclusion is both dangerous and > > without precedent. Conversely, moving to trash can be undone quite easily. > > Is this not sufficient? > > > > Regards, > > Wyatt > > Bjoern Balazs wrote: > +1 > > Ralf Engels wrote: > I agree. > Hidden menu entries is a new UI concept that I have never seen before. > If that is used wider (e.g. in whole KDE) then I am cool with it. > Currently exactly two context menues are using it. So even we are not > consistent in it's use. > > Bart Cerneels wrote: > Shift for delete/move was implemented in kde's file browser already > before I added this to Amarok. It's not an uncommon feature. > > Matěj Laitl wrote: > Bart, this is not about "Shift to delete/move during drop", but "Shift to > show different context menu" - a very different thing. > > Bart Cerneels wrote: > That is what I was talking about. Can someone check dolphin's behavior? > > Ralf Engels wrote: > Bart, you are right. Dolphin has it and I never noticed it. > So, it's not without precedence. Then let's add it in all places where it > makes sense. > > Matěj Laitl wrote: > Bart, Ralf, I fear you are talking about something completely unrelated > with this review request. > > Ctrl to copy and Shift to move are standard Drag & *DROP* (I cannot > stress it enough) modifiers. And Shift is a standard modifier for Delete > *keyboard shortcut* meaning to bypass the trash. This review request has > nothing to do with Drag & drop or keyboard shortcuts. It is about *context > menus*. > > @Ralf, we already have "hold shift to move instead of copying" for > dropping items onto Collections pane. > > Edward Hades Toroshchin wrote: > > This review [...] is about *context menus*. > > Hiding context menu items until the user holds Shift is not uncommon. In > an operating system called Windows™ (which you might have heard of), a file > context menu would contain an "Open with..." item only if the Shift key was > being held. I think (but 'm not sure) it would also bypass "Trash™" if the > user held Shift while clicking "Delete". > @Bart "It's not an uncommon feature." Sorry, but it really is. Can you name more than the file browser and Amarok that have context menu entries that change depending on whether a modifier key is held? I'd be particularly interested in hearing about non-KDE applications that have this (so I also can take them to task for doing it; this is not a behaviour to emulate). Amarok isn't even consistent about applying it; hit ^o and try it in the "Play Media" window. I _will_ acknowledge that this behaviour is present in Dolphin, but I'm afraid I have some rather pointed questions for whoever signed off on it. Its discovery is dependent on a user opening a context menu AND having the shift key pressed before closing the menu AND noticing that the entry has changed (especially in Dolphin which, you'll note, doesn't appear to even have the tooltip!). It completely violates the user's expectation of transparency, and does so in a way that's unlikely to happen simply because of the mental acrobatics involved in mousing and keyboarding simultaneously. - Wyatt --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108686/#review26491 --- On Jan. 31, 2013, 8:09 p.m., Edward Hades Toroshchin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108686/ > ---
Re: Review Request 108686: hidden items in context menu: usability question
> On Feb. 1, 2013, 2:58 a.m., Wyatt Epp wrote: > > "What would be the best approach here?" > > > > Frankly? Scrap it; this is not good interaction. Context menus are rarely > > modifier modal and that's being generous (I have never seen one before > > now). Excepting a very few special cases (e.g. vim), modality is something > > to be avoided. Neither is this sort of menu something Amarok trains users > > for: it only happens with this one of the eight context menu arrangements I > > was able to find in my current layout. > > > > Short term, revert to showing the options as before, with confirmation as > > you see fit. If you're concerned about accidental action, segregate them > > or even put them in a submenu for "permanent actions" or something to that > > effect. > > > > Long term, the aim should be that nothing is possible with a context entry > > that isn't reversible with a simple undo. If, for some reason, things > > cannot be undone, that should be very clear up-front. Is there a > > fundamental reason that move operations aren't able to be undone? On the > > topic of permanent deletion, though I've personally used it in the past, I > > question the necessity of having it in this list. It's not available > > anywhere else in the interface, so its inclusion is both dangerous and > > without precedent. Conversely, moving to trash can be undone quite easily. > > Is this not sufficient? > > > > Regards, > > Wyatt > > Bjoern Balazs wrote: > +1 > > Ralf Engels wrote: > I agree. > Hidden menu entries is a new UI concept that I have never seen before. > If that is used wider (e.g. in whole KDE) then I am cool with it. > Currently exactly two context menues are using it. So even we are not > consistent in it's use. > > Bart Cerneels wrote: > Shift for delete/move was implemented in kde's file browser already > before I added this to Amarok. It's not an uncommon feature. > > Matěj Laitl wrote: > Bart, this is not about "Shift to delete/move during drop", but "Shift to > show different context menu" - a very different thing. > > Bart Cerneels wrote: > That is what I was talking about. Can someone check dolphin's behavior? > > Ralf Engels wrote: > Bart, you are right. Dolphin has it and I never noticed it. > So, it's not without precedence. Then let's add it in all places where it > makes sense. > > Matěj Laitl wrote: > Bart, Ralf, I fear you are talking about something completely unrelated > with this review request. > > Ctrl to copy and Shift to move are standard Drag & *DROP* (I cannot > stress it enough) modifiers. And Shift is a standard modifier for Delete > *keyboard shortcut* meaning to bypass the trash. This review request has > nothing to do with Drag & drop or keyboard shortcuts. It is about *context > menus*. > > @Ralf, we already have "hold shift to move instead of copying" for > dropping items onto Collections pane. > This review [...] is about *context menus*. Hiding context menu items until the user holds Shift is not uncommon. In an operating system called Windows™ (which you might have heard of), a file context menu would contain an "Open with..." item only if the Shift key was being held. I think (but 'm not sure) it would also bypass "Trash™" if the user held Shift while clicking "Delete". - Edward Hades --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108686/#review26491 --- On Jan. 31, 2013, 8:09 p.m., Edward Hades Toroshchin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108686/ > --- > > (Updated Jan. 31, 2013, 8:09 p.m.) > > > Review request for Amarok and KDE Usability. > > > Description > --- > > Some of the actions in context menu are shown only when the Shift key is > pressed. We were wondering, if this were okay at all, and if yes, which hint > would be better. > > To explain a bit more: > in Amarok 2.5, the context menu (of a track, album etc.) used to have all the > options (among others): > * Copy to Collection -> > * Move to Collection -> > * Move to Trash > * Delete > > With goal to (a) make accidental data-loss (or unwanted effect) harder for > novice users (b) make the context menu simpler, a fancy "hold Shift to swich > to move/dangerous operations" behaviour was implemented: > - without Shift held: > * Copy to Collection -> [with "Press Shift key for ..." tooltip] > * Move to Trash [with "Press Shift key for ..." tooltip] > - with Shift key held (updates itself immediately after pressing the key): > * Move to Collection -> > * Delete > > However, we discovered that dis
Review Request 108995: FIX Pre-amplifier in equalizer doesn't work
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108995/ --- Review request for Amarok. Description --- 1. Disabled Pre-amplifier in equalizer if it is not supported by phonon. 2. Fixed top and bottom labels of first slider. Earlier band name label was at the top and slider value label was at the bottom for first slider. 3. Removed an extra semicolon EqualizerDialog.h . This addresses bug 301311. https://bugs.kde.org/show_bug.cgi?id=301311 Diffs - src/dialogs/EqualizerDialog.ui 43b0187 src/EngineController.cpp 3577acf src/dialogs/EqualizerDialog.h fd9032b src/dialogs/EqualizerDialog.cpp 63d8209 Diff: http://git.reviewboard.kde.org/r/108995/diff/ Testing --- All unit test cases passed. Note : I have tested it with gstreamer only. Xine phonon keep crashing on my PC. File Attachments Equalizer snapshot http://git.reviewboard.kde.org/media/uploaded/files/2013/02/17/equalizer.png Thanks, Harsh Gupta ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Review Request 108686: hidden items in context menu: usability question
> On Feb. 1, 2013, 2:58 a.m., Wyatt Epp wrote: > > "What would be the best approach here?" > > > > Frankly? Scrap it; this is not good interaction. Context menus are rarely > > modifier modal and that's being generous (I have never seen one before > > now). Excepting a very few special cases (e.g. vim), modality is something > > to be avoided. Neither is this sort of menu something Amarok trains users > > for: it only happens with this one of the eight context menu arrangements I > > was able to find in my current layout. > > > > Short term, revert to showing the options as before, with confirmation as > > you see fit. If you're concerned about accidental action, segregate them > > or even put them in a submenu for "permanent actions" or something to that > > effect. > > > > Long term, the aim should be that nothing is possible with a context entry > > that isn't reversible with a simple undo. If, for some reason, things > > cannot be undone, that should be very clear up-front. Is there a > > fundamental reason that move operations aren't able to be undone? On the > > topic of permanent deletion, though I've personally used it in the past, I > > question the necessity of having it in this list. It's not available > > anywhere else in the interface, so its inclusion is both dangerous and > > without precedent. Conversely, moving to trash can be undone quite easily. > > Is this not sufficient? > > > > Regards, > > Wyatt > > Bjoern Balazs wrote: > +1 > > Ralf Engels wrote: > I agree. > Hidden menu entries is a new UI concept that I have never seen before. > If that is used wider (e.g. in whole KDE) then I am cool with it. > Currently exactly two context menues are using it. So even we are not > consistent in it's use. > > Bart Cerneels wrote: > Shift for delete/move was implemented in kde's file browser already > before I added this to Amarok. It's not an uncommon feature. > > Matěj Laitl wrote: > Bart, this is not about "Shift to delete/move during drop", but "Shift to > show different context menu" - a very different thing. > > Bart Cerneels wrote: > That is what I was talking about. Can someone check dolphin's behavior? > > Ralf Engels wrote: > Bart, you are right. Dolphin has it and I never noticed it. > So, it's not without precedence. Then let's add it in all places where it > makes sense. Bart, Ralf, I fear you are talking about something completely unrelated with this review request. Ctrl to copy and Shift to move are standard Drag & *DROP* (I cannot stress it enough) modifiers. And Shift is a standard modifier for Delete *keyboard shortcut* meaning to bypass the trash. This review request has nothing to do with Drag & drop or keyboard shortcuts. It is about *context menus*. @Ralf, we already have "hold shift to move instead of copying" for dropping items onto Collections pane. - Matěj --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108686/#review26491 --- On Jan. 31, 2013, 8:09 p.m., Edward Hades Toroshchin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108686/ > --- > > (Updated Jan. 31, 2013, 8:09 p.m.) > > > Review request for Amarok and KDE Usability. > > > Description > --- > > Some of the actions in context menu are shown only when the Shift key is > pressed. We were wondering, if this were okay at all, and if yes, which hint > would be better. > > To explain a bit more: > in Amarok 2.5, the context menu (of a track, album etc.) used to have all the > options (among others): > * Copy to Collection -> > * Move to Collection -> > * Move to Trash > * Delete > > With goal to (a) make accidental data-loss (or unwanted effect) harder for > novice users (b) make the context menu simpler, a fancy "hold Shift to swich > to move/dangerous operations" behaviour was implemented: > - without Shift held: > * Copy to Collection -> [with "Press Shift key for ..." tooltip] > * Move to Trash [with "Press Shift key for ..." tooltip] > - with Shift key held (updates itself immediately after pressing the key): > * Move to Collection -> > * Delete > > However, we discovered that discoverability (hehe) is really a problem when > even experienced long-term Amarok users didn't know about the way to trigger > Move/Delete. What would be the best approach here? > > > Diffs > - > > > Diff: http://git.reviewboard.kde.org/r/108686/diff/ > > > Testing > --- > > > File Attachments > > > Behaviour of Amaork 2.7 with Shift key held > > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hidden_actions.p
Re: Fwd: Another bug in equalizer
Thanks for noticing the error. I think the following patch should fix the problem: http://commits.kde.org/amarok/aef8f57124c39ad8df46e92333175ea7a850e7f4 We also have a bug tracker that we are usually using for this kind of request. Cheers, Ralf Am Sonntag, 17. Februar 2013, 12:11:27 schrieb Matěj Laitl: Hi Harsh, overlooks happen, such e-mails are best sent directly to amarok-devel with CC to patch author. Ralf, can you have a look at it? Matěj -- Forwarded Message -- Sir, The default value entry of 'manual' preset was deleted in a patch submitted on 2012-01-22 by Ralf Engels which seems to have caused some problem. Now equalizer shows (i+1)th preset on requesting i th present. For example, on requesting 'Classical' preset, the equalizer shows the values of 'Club' preset. So I request you to confirm the bug. Further, adding the removed entry seems to fix the bug. I didn't know where to post so I sent you a personal mail. Sorry for inconvenience. Patch that appears to be buggy : Link - ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Review Request 108686: hidden items in context menu: usability question
> On Feb. 1, 2013, 2:58 a.m., Wyatt Epp wrote: > > "What would be the best approach here?" > > > > Frankly? Scrap it; this is not good interaction. Context menus are rarely > > modifier modal and that's being generous (I have never seen one before > > now). Excepting a very few special cases (e.g. vim), modality is something > > to be avoided. Neither is this sort of menu something Amarok trains users > > for: it only happens with this one of the eight context menu arrangements I > > was able to find in my current layout. > > > > Short term, revert to showing the options as before, with confirmation as > > you see fit. If you're concerned about accidental action, segregate them > > or even put them in a submenu for "permanent actions" or something to that > > effect. > > > > Long term, the aim should be that nothing is possible with a context entry > > that isn't reversible with a simple undo. If, for some reason, things > > cannot be undone, that should be very clear up-front. Is there a > > fundamental reason that move operations aren't able to be undone? On the > > topic of permanent deletion, though I've personally used it in the past, I > > question the necessity of having it in this list. It's not available > > anywhere else in the interface, so its inclusion is both dangerous and > > without precedent. Conversely, moving to trash can be undone quite easily. > > Is this not sufficient? > > > > Regards, > > Wyatt > > Bjoern Balazs wrote: > +1 > > Ralf Engels wrote: > I agree. > Hidden menu entries is a new UI concept that I have never seen before. > If that is used wider (e.g. in whole KDE) then I am cool with it. > Currently exactly two context menues are using it. So even we are not > consistent in it's use. > > Bart Cerneels wrote: > Shift for delete/move was implemented in kde's file browser already > before I added this to Amarok. It's not an uncommon feature. > > Matěj Laitl wrote: > Bart, this is not about "Shift to delete/move during drop", but "Shift to > show different context menu" - a very different thing. > > Bart Cerneels wrote: > That is what I was talking about. Can someone check dolphin's behavior? Bart, you are right. Dolphin has it and I never noticed it. So, it's not without precedence. Then let's add it in all places where it makes sense. - Ralf --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108686/#review26491 --- On Jan. 31, 2013, 8:09 p.m., Edward Hades Toroshchin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108686/ > --- > > (Updated Jan. 31, 2013, 8:09 p.m.) > > > Review request for Amarok and KDE Usability. > > > Description > --- > > Some of the actions in context menu are shown only when the Shift key is > pressed. We were wondering, if this were okay at all, and if yes, which hint > would be better. > > To explain a bit more: > in Amarok 2.5, the context menu (of a track, album etc.) used to have all the > options (among others): > * Copy to Collection -> > * Move to Collection -> > * Move to Trash > * Delete > > With goal to (a) make accidental data-loss (or unwanted effect) harder for > novice users (b) make the context menu simpler, a fancy "hold Shift to swich > to move/dangerous operations" behaviour was implemented: > - without Shift held: > * Copy to Collection -> [with "Press Shift key for ..." tooltip] > * Move to Trash [with "Press Shift key for ..." tooltip] > - with Shift key held (updates itself immediately after pressing the key): > * Move to Collection -> > * Delete > > However, we discovered that discoverability (hehe) is really a problem when > even experienced long-term Amarok users didn't know about the way to trigger > Move/Delete. What would be the best approach here? > > > Diffs > - > > > Diff: http://git.reviewboard.kde.org/r/108686/diff/ > > > Testing > --- > > > File Attachments > > > Behaviour of Amaork 2.7 with Shift key held > > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hidden_actions.png > Suggestion to improve discoverability > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hint_1.png > Behaviour of Amarok 2.7 without any key held > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hint_2.png > > > Thanks, > > Edward Hades Toroshchin > > ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Review Request 108686: hidden items in context menu: usability question
> On Feb. 1, 2013, 2:58 a.m., Wyatt Epp wrote: > > "What would be the best approach here?" > > > > Frankly? Scrap it; this is not good interaction. Context menus are rarely > > modifier modal and that's being generous (I have never seen one before > > now). Excepting a very few special cases (e.g. vim), modality is something > > to be avoided. Neither is this sort of menu something Amarok trains users > > for: it only happens with this one of the eight context menu arrangements I > > was able to find in my current layout. > > > > Short term, revert to showing the options as before, with confirmation as > > you see fit. If you're concerned about accidental action, segregate them > > or even put them in a submenu for "permanent actions" or something to that > > effect. > > > > Long term, the aim should be that nothing is possible with a context entry > > that isn't reversible with a simple undo. If, for some reason, things > > cannot be undone, that should be very clear up-front. Is there a > > fundamental reason that move operations aren't able to be undone? On the > > topic of permanent deletion, though I've personally used it in the past, I > > question the necessity of having it in this list. It's not available > > anywhere else in the interface, so its inclusion is both dangerous and > > without precedent. Conversely, moving to trash can be undone quite easily. > > Is this not sufficient? > > > > Regards, > > Wyatt > > Bjoern Balazs wrote: > +1 > > Ralf Engels wrote: > I agree. > Hidden menu entries is a new UI concept that I have never seen before. > If that is used wider (e.g. in whole KDE) then I am cool with it. > Currently exactly two context menues are using it. So even we are not > consistent in it's use. > > Bart Cerneels wrote: > Shift for delete/move was implemented in kde's file browser already > before I added this to Amarok. It's not an uncommon feature. > > Matěj Laitl wrote: > Bart, this is not about "Shift to delete/move during drop", but "Shift to > show different context menu" - a very different thing. That is what I was talking about. Can someone check dolphin's behavior? - Bart --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108686/#review26491 --- On Jan. 31, 2013, 8:09 p.m., Edward Hades Toroshchin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108686/ > --- > > (Updated Jan. 31, 2013, 8:09 p.m.) > > > Review request for Amarok and KDE Usability. > > > Description > --- > > Some of the actions in context menu are shown only when the Shift key is > pressed. We were wondering, if this were okay at all, and if yes, which hint > would be better. > > To explain a bit more: > in Amarok 2.5, the context menu (of a track, album etc.) used to have all the > options (among others): > * Copy to Collection -> > * Move to Collection -> > * Move to Trash > * Delete > > With goal to (a) make accidental data-loss (or unwanted effect) harder for > novice users (b) make the context menu simpler, a fancy "hold Shift to swich > to move/dangerous operations" behaviour was implemented: > - without Shift held: > * Copy to Collection -> [with "Press Shift key for ..." tooltip] > * Move to Trash [with "Press Shift key for ..." tooltip] > - with Shift key held (updates itself immediately after pressing the key): > * Move to Collection -> > * Delete > > However, we discovered that discoverability (hehe) is really a problem when > even experienced long-term Amarok users didn't know about the way to trigger > Move/Delete. What would be the best approach here? > > > Diffs > - > > > Diff: http://git.reviewboard.kde.org/r/108686/diff/ > > > Testing > --- > > > File Attachments > > > Behaviour of Amaork 2.7 with Shift key held > > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hidden_actions.png > Suggestion to improve discoverability > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hint_1.png > Behaviour of Amarok 2.7 without any key held > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hint_2.png > > > Thanks, > > Edward Hades Toroshchin > > ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Review Request 108686: hidden items in context menu: usability question
> On Feb. 1, 2013, 2:58 a.m., Wyatt Epp wrote: > > "What would be the best approach here?" > > > > Frankly? Scrap it; this is not good interaction. Context menus are rarely > > modifier modal and that's being generous (I have never seen one before > > now). Excepting a very few special cases (e.g. vim), modality is something > > to be avoided. Neither is this sort of menu something Amarok trains users > > for: it only happens with this one of the eight context menu arrangements I > > was able to find in my current layout. > > > > Short term, revert to showing the options as before, with confirmation as > > you see fit. If you're concerned about accidental action, segregate them > > or even put them in a submenu for "permanent actions" or something to that > > effect. > > > > Long term, the aim should be that nothing is possible with a context entry > > that isn't reversible with a simple undo. If, for some reason, things > > cannot be undone, that should be very clear up-front. Is there a > > fundamental reason that move operations aren't able to be undone? On the > > topic of permanent deletion, though I've personally used it in the past, I > > question the necessity of having it in this list. It's not available > > anywhere else in the interface, so its inclusion is both dangerous and > > without precedent. Conversely, moving to trash can be undone quite easily. > > Is this not sufficient? > > > > Regards, > > Wyatt > > Bjoern Balazs wrote: > +1 > > Ralf Engels wrote: > I agree. > Hidden menu entries is a new UI concept that I have never seen before. > If that is used wider (e.g. in whole KDE) then I am cool with it. > Currently exactly two context menues are using it. So even we are not > consistent in it's use. > > Bart Cerneels wrote: > Shift for delete/move was implemented in kde's file browser already > before I added this to Amarok. It's not an uncommon feature. Bart, this is not about "Shift to delete/move during drop", but "Shift to show different context menu" - a very different thing. - Matěj --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108686/#review26491 --- On Jan. 31, 2013, 8:09 p.m., Edward Hades Toroshchin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108686/ > --- > > (Updated Jan. 31, 2013, 8:09 p.m.) > > > Review request for Amarok and KDE Usability. > > > Description > --- > > Some of the actions in context menu are shown only when the Shift key is > pressed. We were wondering, if this were okay at all, and if yes, which hint > would be better. > > To explain a bit more: > in Amarok 2.5, the context menu (of a track, album etc.) used to have all the > options (among others): > * Copy to Collection -> > * Move to Collection -> > * Move to Trash > * Delete > > With goal to (a) make accidental data-loss (or unwanted effect) harder for > novice users (b) make the context menu simpler, a fancy "hold Shift to swich > to move/dangerous operations" behaviour was implemented: > - without Shift held: > * Copy to Collection -> [with "Press Shift key for ..." tooltip] > * Move to Trash [with "Press Shift key for ..." tooltip] > - with Shift key held (updates itself immediately after pressing the key): > * Move to Collection -> > * Delete > > However, we discovered that discoverability (hehe) is really a problem when > even experienced long-term Amarok users didn't know about the way to trigger > Move/Delete. What would be the best approach here? > > > Diffs > - > > > Diff: http://git.reviewboard.kde.org/r/108686/diff/ > > > Testing > --- > > > File Attachments > > > Behaviour of Amaork 2.7 with Shift key held > > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hidden_actions.png > Suggestion to improve discoverability > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hint_1.png > Behaviour of Amarok 2.7 without any key held > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hint_2.png > > > Thanks, > > Edward Hades Toroshchin > > ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Review Request 108686: hidden items in context menu: usability question
> On Feb. 1, 2013, 2:58 a.m., Wyatt Epp wrote: > > "What would be the best approach here?" > > > > Frankly? Scrap it; this is not good interaction. Context menus are rarely > > modifier modal and that's being generous (I have never seen one before > > now). Excepting a very few special cases (e.g. vim), modality is something > > to be avoided. Neither is this sort of menu something Amarok trains users > > for: it only happens with this one of the eight context menu arrangements I > > was able to find in my current layout. > > > > Short term, revert to showing the options as before, with confirmation as > > you see fit. If you're concerned about accidental action, segregate them > > or even put them in a submenu for "permanent actions" or something to that > > effect. > > > > Long term, the aim should be that nothing is possible with a context entry > > that isn't reversible with a simple undo. If, for some reason, things > > cannot be undone, that should be very clear up-front. Is there a > > fundamental reason that move operations aren't able to be undone? On the > > topic of permanent deletion, though I've personally used it in the past, I > > question the necessity of having it in this list. It's not available > > anywhere else in the interface, so its inclusion is both dangerous and > > without precedent. Conversely, moving to trash can be undone quite easily. > > Is this not sufficient? > > > > Regards, > > Wyatt > > Bjoern Balazs wrote: > +1 > > Ralf Engels wrote: > I agree. > Hidden menu entries is a new UI concept that I have never seen before. > If that is used wider (e.g. in whole KDE) then I am cool with it. > Currently exactly two context menues are using it. So even we are not > consistent in it's use. Shift for delete/move was implemented in kde's file browser already before I added this to Amarok. It's not an uncommon feature. - Bart --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108686/#review26491 --- On Jan. 31, 2013, 8:09 p.m., Edward Hades Toroshchin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108686/ > --- > > (Updated Jan. 31, 2013, 8:09 p.m.) > > > Review request for Amarok and KDE Usability. > > > Description > --- > > Some of the actions in context menu are shown only when the Shift key is > pressed. We were wondering, if this were okay at all, and if yes, which hint > would be better. > > To explain a bit more: > in Amarok 2.5, the context menu (of a track, album etc.) used to have all the > options (among others): > * Copy to Collection -> > * Move to Collection -> > * Move to Trash > * Delete > > With goal to (a) make accidental data-loss (or unwanted effect) harder for > novice users (b) make the context menu simpler, a fancy "hold Shift to swich > to move/dangerous operations" behaviour was implemented: > - without Shift held: > * Copy to Collection -> [with "Press Shift key for ..." tooltip] > * Move to Trash [with "Press Shift key for ..." tooltip] > - with Shift key held (updates itself immediately after pressing the key): > * Move to Collection -> > * Delete > > However, we discovered that discoverability (hehe) is really a problem when > even experienced long-term Amarok users didn't know about the way to trigger > Move/Delete. What would be the best approach here? > > > Diffs > - > > > Diff: http://git.reviewboard.kde.org/r/108686/diff/ > > > Testing > --- > > > File Attachments > > > Behaviour of Amaork 2.7 with Shift key held > > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hidden_actions.png > Suggestion to improve discoverability > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hint_1.png > Behaviour of Amarok 2.7 without any key held > http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hint_2.png > > > Thanks, > > Edward Hades Toroshchin > > ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Fwd: Another bug in equalizer
Hi Harsh, overlooks happen, such e-mails are best sent directly to amarok-devel with CC to patch author. Ralf, can you have a look at it? Matěj -- Forwarded Message -- Sir, The default value entry of 'manual' preset was deleted in a patch submitted on 2012-01-22 by Ralf Engels which seems to have caused some problem. Now equalizer shows (i+1)th preset on requesting i th present. For example, on requesting 'Classical' preset, the equalizer shows the values of 'Club' preset. So I request you to confirm the bug. Further, adding the removed entry seems to fix the bug. I didn't know where to post so I sent you a personal mail. Sorry for inconvenience. Patch that appears to be buggy : Link -___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
