View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000114 | OpenMPT | Feature Request | public | 2011-04-13 21:37 | 2015-10-17 18:41 |
Reporter | harbinger | Assigned To | Saga Musix | ||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | resolved | Resolution | fixed | ||
Platform | x86 | OS | Windows | OS Version | XP |
Target Version | OpenMPT 1.25.01.00 / libopenmpt 0.2-beta13 (upgrade first) | Fixed in Version | OpenMPT 1.25.01.00 / libopenmpt 0.2-beta13 (upgrade first) | ||
Summary | 0000114: Keyboard Command Share | ||||
Description | I had this idea while configuring my WORD keyboard commands: it's too bad you can't apply one command to do two things. Then i thought, what we need is a Share toggle for each command. This would work great in MPT (yeah if it could be implemented)! Right now, some keyboard shortcuts can co-exist, and ModPlug will decide what to do based on the input context. For example, you can have Ctrl-V do "paste" in an editing situation, but, if the input focus is not in a text field or some other editing context, you can have Ctrl-V play the track from the start. If, however, you attempt to assign shortcuts that cannot co-exist, you're notified of the conflict, and the previous assignment is unlinked. (Really the conflict should be mentioned before assigning the keypress to the function...) In a future version, with a little programming wizardry, you can have shortcuts execute one after another by making use of a Share boolean. If you assign a shortcut to a keypress, you can check a Share checkbox, and the original assignment is not deleted. Instead, ModPlug will attempt to do both -- the original function first, then the second one you added (if it can). It may be possible to create a string of executions with one keypress, in many ways emulating or complementing future scripting capabilities. The MKB file will keep up with 1 new parameter; the next function to try to execute. For example, a part of the MKB listing might be: 0:1346:2:79:2:0000 //File/Open: Ctrl+O (KeyUp) In this example, there is an extra parameter, the 6th in each colon-delimited list. This value is the keypress function found in this list to execute (if it's "0000", shortcut-sharing was not assigned) AFTER executing the current one. So, in this example, pressing Ctrl-O will simply show the LoadFile dialog so the user can open a track. Pressing Ctrl-W will first close the current file (prompting for a save if necessary), then allow the user to open another file (function ID 1346). Pressing Ctrl-S will first save the file directly and immediately, then close it (1348), then open another (1346). Key Up/Hold/Down controls are ignored after the first command is executed. I imagine if this can be somehow implemented, that the power of this feature is so great that it will require testing APART from the working devleopment; IOW, it would need its own build to do testing with, as you can potentially really do a lot of damage, if not to existing tracks, then perhaps to the default cache files. One thing you don't want to accidentally do is end up with an Open File neverending loop, or a function that selects the next row in a track, deletes it, saves the file, and starts all over again. (If the user does it himself knowingly, that's one thing; but having it done because of a code glitch is quite another!) | ||||
Tags | No tags attached. | ||||
Has the bug occurred in previous versions? | |||||
Tested code revision (in case you know it) | |||||
Actually I don't think we need to alter the MKB format or anything for that. I have been playing with the though of not removing duplicate shortcuts for a while now, but I have not tested yet if it is technically feasible. That would for example allow to map "select all" and "delete" to the same shortcut, so you'd just have to press one key combination instead of two - though that will most likely require quite a rewrite of the keyboard code, as one keypress is just evaluated once at the moment. |
|
Oops, forgot to close this report. This was added as an optional feature in OpenMPT 1.25. http://forum.openmpt.org/index.php?topic=5491.msg42244#msg42244 |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2011-04-13 21:37 | harbinger | New Issue | |
2011-04-13 21:48 | Saga Musix | Note Added: 0000145 | |
2015-10-17 18:41 | Saga Musix | Note Added: 0002161 | |
2015-10-17 18:41 | Saga Musix | Assigned To | => Saga Musix |
2015-10-17 18:41 | Saga Musix | Status | new => resolved |
2015-10-17 18:41 | Saga Musix | Resolution | open => fixed |
2015-10-17 18:41 | Saga Musix | Fixed in Version | => OpenMPT 1.25.01.00 / libopenmpt 0.2-beta13 (upgrade first) |
2015-10-17 18:41 | Saga Musix | Target Version | => OpenMPT 1.25.01.00 / libopenmpt 0.2-beta13 (upgrade first) |