----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108802/#review27187 -----------------------------------------------------------
Thanks Dawit for working on this! Concerning your question: the state of the modifiers only matters when the context menu is open (or just about to be opened), right? Couldn't one move the m_keyInfo-related code from the constructor to slotOpenContextMenu() and disconnect from the signal again at the end of that function? - Frank Reininghaus On Feb. 6, 2013, 1:05 p.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108802/ > ----------------------------------------------------------- > > (Updated Feb. 6, 2013, 1:05 p.m.) > > > Review request for KDE Base Apps, David Faure and Frank Reininghaus. > > > Description > ------- > > This patch fixes DolphinPart such that the "Delete/Move To Trash" actions are > automatically toggled if the user presses the Shift key and allows > https://git.reviewboard.kde.org/r/107509/ to be applied. > > The code is completely based on what Dolphin's context menu does. Even though > this works as planned, I still have reservations about the use of > KModifierKeyInfo since every key press event from any application is sent to > the application that connects to its signals. In my code and unlike what is > done in Dolphin's context menu, I try to mitigate the impact of that by > ignoring the signal when the part does not have the focus. Still if there is > a better way to capture key press events at the part level I would like to > use that instead. Any ideas ? > > > Diffs > ----- > > dolphin/src/dolphinpart.h 7881ded > dolphin/src/dolphinpart.cpp 627ba79 > > Diff: http://git.reviewboard.kde.org/r/108802/diff/ > > > Testing > ------- > > > Thanks, > > Dawit Alemayehu > >
