[rkward-devel] Better keybindings for "Run"

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Tue Jan 17 16:14:28 UTC 2012


Hi,

On Monday 16 January 2012, Milan Bouchet-Valat wrote:
> Maybe there are historical reasons to this, but I find this choice
> weird, since all other R GUIs I know use Ctrl+R, which is much simpler.
> Function keys are far away on the keyboard and require you to press Fn
> on Macs and current HP laptops. With Shift, this makes three keys to
> press at the same time! (I've disabled this behavior on my laptop.)

well, Ctrl+R makes a lot of sense in the context of R GUIs. In our case it is 
taken by "Replace", already, which also makes a lot of sense, in general. 
There are two main problems with changing that. First, "Replace" is provided 
by the embedded kate part. It is not impossible to change the associated 
shortcut, but it's not really an intended usage of embedded KDE parts, either. 
Changing this keyboard shortcut would involve using a hack which is likely to 
break sooner or later, without prior warning. Second, "Replace" is a 
comparatively important task. Changing it's shortcut (which is a default 
shortcut, shared across KDE applications) to execute some R code, instead, 
definitely has potential for causing some unpleasant surprises.

So I think, Ctrl+R is a no-go. Which doesn't mean to say that the current 
shortcuts are the only / best option. But finding good shortcut combinations 
(esp. for a series of similar actions), which do not cause conflicts, is 
notoriously difficult.
 
> I suggest to change these keybindings. The natural solution seems to be
> Ctrl+R; this would run the current selection, if any, and the current
> line if there is no selection (this is what SAS does with F3). Since
> running the whole file is also useful, but used a little less often, I
> suggest Ctrl+Shift+R.

I think that's a good idea, in principle. Not sure, wether such a "combined" 
action would replace the others, entirely. Also, I tend to think that it may 
be more natural to combine the "run selection" behavior with "run file", in 
case no selection exists. Many existing actions already use similar semantics 
(also in other applications). In many cases (for simple top-level statements), 
"run line" can be used as a sort of step-by-step execution, and I think it 
will be useful to keep this separate.

How do others feel about this? Which actions could be merged this way? Should 
the single actions remain in addition to that? Should they continue to have a 
default keyboard shortcut?

> BTW, the buttons and menus could be changed accordingly. Merging "Run
> selection" and "Run line" would make some space available in the
> toolbar,

In fact, it would be possible to keep a bit of both in the toolbar: It is 
possible to create a tool-button with a dropdown, similar to the "back" 
buttons on many browsers. Simply clicking the button would execute the 
"combined" action, depending on whether or not there is a selection. Clicking 
a small arrow at the side would show the current specific actions in a 
dropdown.

> which would allow "Run block" and "CD to script directory" to
> fit on screen when translated (in French, I couldn't manage to get the
> whole bar to fit on my 1366px-wide screen, and for many languages other
> than English it will be the case).

Could it be you are using the "Text alongside icons" placement option (RMB 
click on the toolbar(s))? "Text below icons" can save a lot of horizontal 
space. That is also available as a global KDE setting, so if you run into 
similar problems in other KDE applications, consider checking your system 
settings.

> Anyway, reducing the visual noise on
> the main toolbar is always good for users.

Agreed.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20120117/b6a7c3c8/attachment.sig>


More information about the Rkward-devel mailing list