Re: Review Request 124315: Change keyboard shortcut to avoid conflict with next tab
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124315/ --- (Updated Aug. 25, 2015, 3 a.m.) Status -- This change has been marked as submitted. Review request for Kate and KDE Frameworks. Changes --- Submitted with commit 0374231f43fe9924ddbbbe1edb1ee3110fd7e802 by Simon Persson to branch master. Bugs: 350025 https://bugs.kde.org/show_bug.cgi?id=350025 Repository: ktexteditor Description --- Change default keyboard shortcut for go to previous editing line as it is in conflict with default shortcut for next tab action. The katepart is likely to be used in an application that has tabs, so having a conflict with one of the default shortcuts for changing tabs is not so good. This turns up in Krusader, bug 350025. Currently Kate uses the wrong default shortcuts for next/prev tab, so currently there is no conflict there. I will also make a review request for Kate to use correct shortcuts and if accepted the same conflict will appear there. The choice of using ctrl+E, ctrl+shift+E, was just motivated by e as in edit and that it was available in katepart and kate. There is a standard shortcut called text completion which has ctrl+E as default. This is not used by katepart and seems unlikely to cause conflict. Diffs - src/view/kateview.cpp 4e8054f Diff: https://git.reviewboard.kde.org/r/124315/diff/ Testing --- Tested with Kate and Krusader, compiled from master. Only small issue is a new conflict in Krusader (ctrl+shift+E, used for switching to Editor... but then if you are using this katepart you already are in the editor.. so no biggie). Thanks, Simon Persson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124315: Change keyboard shortcut to avoid conflict with next tab
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124315/#review84210 --- Ship it! I think this patch makes sense. And Ctrl+e is currently unused in Kate/Kile/KDevelop it seems, to should be a good choice. The feature itself is fairly new still and hence probably rather unknown, so changing the shortcut now is fine. Please commit. - Dominik Haumann On July 10, 2015, 7:56 a.m., Simon Persson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124315/ --- (Updated July 10, 2015, 7:56 a.m.) Review request for Kate and KDE Frameworks. Bugs: 350025 https://bugs.kde.org/show_bug.cgi?id=350025 Repository: ktexteditor Description --- Change default keyboard shortcut for go to previous editing line as it is in conflict with default shortcut for next tab action. The katepart is likely to be used in an application that has tabs, so having a conflict with one of the default shortcuts for changing tabs is not so good. This turns up in Krusader, bug 350025. Currently Kate uses the wrong default shortcuts for next/prev tab, so currently there is no conflict there. I will also make a review request for Kate to use correct shortcuts and if accepted the same conflict will appear there. The choice of using ctrl+E, ctrl+shift+E, was just motivated by e as in edit and that it was available in katepart and kate. There is a standard shortcut called text completion which has ctrl+E as default. This is not used by katepart and seems unlikely to cause conflict. Diffs - src/view/kateview.cpp 4e8054f Diff: https://git.reviewboard.kde.org/r/124315/diff/ Testing --- Tested with Kate and Krusader, compiled from master. Only small issue is a new conflict in Krusader (ctrl+shift+E, used for switching to Editor... but then if you are using this katepart you already are in the editor.. so no biggie). Thanks, Simon Persson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124315: Change keyboard shortcut to avoid conflict with next tab
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124315/#review82305 --- Changing shortcuts is never a good idea. I'd prefer fixing it some other way. - Albert Astals Cid On jul. 10, 2015, 7:56 a.m., Simon Persson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124315/ --- (Updated jul. 10, 2015, 7:56 a.m.) Review request for Kate and KDE Frameworks. Bugs: 350025 https://bugs.kde.org/show_bug.cgi?id=350025 Repository: ktexteditor Description --- Change default keyboard shortcut for go to previous editing line as it is in conflict with default shortcut for next tab action. The katepart is likely to be used in an application that has tabs, so having a conflict with one of the default shortcuts for changing tabs is not so good. This turns up in Krusader, bug 350025. Currently Kate uses the wrong default shortcuts for next/prev tab, so currently there is no conflict there. I will also make a review request for Kate to use correct shortcuts and if accepted the same conflict will appear there. The choice of using ctrl+E, ctrl+shift+E, was just motivated by e as in edit and that it was available in katepart and kate. There is a standard shortcut called text completion which has ctrl+E as default. This is not used by katepart and seems unlikely to cause conflict. Diffs - src/view/kateview.cpp 4e8054f Diff: https://git.reviewboard.kde.org/r/124315/diff/ Testing --- Tested with Kate and Krusader, compiled from master. Only small issue is a new conflict in Krusader (ctrl+shift+E, used for switching to Editor... but then if you are using this katepart you already are in the editor.. so no biggie). Thanks, Simon Persson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124315: Change keyboard shortcut to avoid conflict with next tab
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124315/#review82320 --- If two shortcuts are the same (the shortcut of go to previous editing line of katepart and the shortcut of next tab of KDE Plasma)... Having conflicting shortcuts is not a good idea. I understand that KDE Plasma developers have an upper vision and that they must choose the shortcuts that fit better in the workflow of their users; katepart developers must not hold shortcuts that are used by KDE Plasma, as we know. - Toni Asensi Esteve On July 10, 2015, 9:56 a.m., Simon Persson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124315/ --- (Updated July 10, 2015, 9:56 a.m.) Review request for Kate and KDE Frameworks. Bugs: 350025 https://bugs.kde.org/show_bug.cgi?id=350025 Repository: ktexteditor Description --- Change default keyboard shortcut for go to previous editing line as it is in conflict with default shortcut for next tab action. The katepart is likely to be used in an application that has tabs, so having a conflict with one of the default shortcuts for changing tabs is not so good. This turns up in Krusader, bug 350025. Currently Kate uses the wrong default shortcuts for next/prev tab, so currently there is no conflict there. I will also make a review request for Kate to use correct shortcuts and if accepted the same conflict will appear there. The choice of using ctrl+E, ctrl+shift+E, was just motivated by e as in edit and that it was available in katepart and kate. There is a standard shortcut called text completion which has ctrl+E as default. This is not used by katepart and seems unlikely to cause conflict. Diffs - src/view/kateview.cpp 4e8054f Diff: https://git.reviewboard.kde.org/r/124315/diff/ Testing --- Tested with Kate and Krusader, compiled from master. Only small issue is a new conflict in Krusader (ctrl+shift+E, used for switching to Editor... but then if you are using this katepart you already are in the editor.. so no biggie). Thanks, Simon Persson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
