jtackaberry / reaticulate

An articulation management system for REAPER
Other
101 stars 46 forks source link

Allow customization of key to close Reaticulate #140

Open X-Raym opened 3 years ago

X-Raym commented 3 years ago

Hi !

In most GFX scripts, the Esc key to simply kill the script.

char = gfx.char
if char ~= 27 or char < 0 then reaper.defer(run) else gfx.quit() end

Maybe this could also be expected for reaticulate, and the framework which power it ? :)

Best,

jtackaberry commented 3 years ago

I don't think rtk should be opinionated about this. And it's easy enough for scripts to explicitly handle this:

    window.onkeypresspost = function(self, event)
        if not event.handled and event.keycode == rtk.keycodes.ESCAPE then
            self:close()
        end
    end

(I think I'll add that recipe to the tutorial.)

But nor do I think Reaticulate should close specifically on escape, because this key is used in other contexts (e.g. to clear the articulation search filter). Perhaps making it customizable. I think many people would want to use the key they've bound to launch Reaticulate as the key to close it, especially because this gives consistent behavior whether the focus is in the Reaticulate window or not. (Otherwise the user would have the cognitive overhead to think: ok, is Reaticulate focused? I need to press escape. Is the arrange view focused? Now I need to press the key I've assigned to the action to start it.)

X-Raym commented 3 years ago

I think many people would want to use the key they've bound to launch Reaticulate as the key to close it, `

Valid concerns, though it doesn't count the case where it would not be run via a keyboard shortcut - for eg, via action list or toolbar button; that is why a generic Close focused window key is used all other reaper already (Esc kills Action list, Media item properties, mixer window etc) - in addition to the Close via same custom keyboard shortcut (which is not by default BTW, as by default reaper propose to run a second instance).

Otherwise the user would have the cognitive overhead to think: ok, is Reaticulate focused?

This is definitely minor. The concept of "Focus" is on every apps and windows on all OS since the beginning of GUI. It is just a click 😆

Having a generic Kill key is, n the contrary, the best way to reduce cognitive overload by reducing the need to memorize any keyboard shortcuts; toolbars is a great way to make actions accessible while not having to learn any keyboard shortcut. And especially because all other window already behave like that, having to think "This window close this escape like the other one, this window need the custom keyboard shortcut i made, this Reaticulate window with another keyboard shortcut etc..." iswhat bring overload.

Esc key can still be used to erase some field, but for kill if none of this field is focus. This wouldn't be a surprising behavior. 👍

For the framework it will not be an issue with the code snippet you had, but wanted to test the framework I tried reaticulate and as a newbie in it I was surprised by the Esc key not killing the window.

Just my two cents! 😁

jtackaberry commented 3 years ago

Esc key can still be used to erase some field, but for kill if none of this field is focus. This wouldn't be a surprising behavior. 👍

Keys can of course behave differently depending on which widget is focused, but when a behavioral difference is as drastic as "clear field" vs "exit application" then I argue it is surprising to have the window vanish when you think a text input field was focused but it actually wasn't.

The other argument here is Reaticulate isn't meant to be a one-and-done, in-and-out script, but rather a long running docked interface. Most users work this way. So I don't actually want it to be that easy to kill it OOTB, which is why I think it's best for it to be user-configurable.

Maybe "escape quits by default" is enough of an established idiom, and most scripts actually are meant to be transient in-and-out activities, to argue this ought to be rtk's default behavior, even if it isn't Reaticulate's. I'd love to hear from other scripters on that topic -- I could definitely be convinced.

but wanted to test the framework I tried reaticulate and as a newbie in it I was surprised by the Esc key not killing the window.

Sadly current release of Reaticulate is using very, very, very old rtk code. Like almost two years old. I did major work on rtk since Christmas that isn't reflected in the current stable release of Reaticulate. So it'll give you a flavor for sure, but rtk has gotten quite a lot more sophisticated.

rtk has been a diversion, and now that it's released, I need to get back to working on Reaticulate. :)

X-Raym commented 3 years ago

Keys can of course behave differently depending on which widget is focused, but when a behavioral difference is as drastic as "clear field" vs "exit application" then I argue it is surprising to have the window vanish when you think a text input field was focused but it actually wasn't.

Definitely. I think the issue is with Esc for clear cause I don't think I have seen that somewhere :P I would assume DEL key for that. But Esc may make sense in this reaticulate context of course... But if users are used to it, then a change should have configuration in option window for sure.

long running docked interface.

Note that reaper default windows doesn't close at ESC if dock. This is a floating window behavior in most case.

I'd love to hear from other scripters

You can consider most other scripts as pro-Esc-Kill arguments cause it is quite common, even for other scripts which are meant to to stay in front all the time (region clock, waveform vizualizers, etc). But for sure, other people comments can bring some weight on either side. Let's hear about others 😃


Note that I know that I am niptcking over small details, the work you made for rtk or reaticulate is of course amazing and shouldn't be dimissed by a simple ESC key issue 😄 This is often the case with UX, the tiny details lead to the most longest list of pro and cons, precisely because of their subtility, but in the end, as long as it doesn't the work to be done...

I need to get back to working on Reaticulate. :)

Haha, sure, rtk had to be a real piece of work. Though now it is released, you can expect users asking questions about it 😋

jtackaberry commented 3 years ago

I think the issue is with Esc for clear cause I don't think I have seen that somewhere :P I would assume DEL key for that.

Standard behavior for text entry boxes is that the del key deletes the character to the right of the caret, not that it clears the contents of the field. Admittedly clearing contents isn't something commonly needed (and to be clear, this isn't an rtk behavior, but a Reaticulate one, and for only one specific text entry widget on the main screen), but when it's a field used to filter the results in a list, hitting escape to clear the filter isn't entirely without precedence.

But you make a fair point that I am arguing against what may be a reasonable default behavior in rtk on the basis of a fairly specific behavior needed by Reaticulate, which isn't great reasoning.

Note that reaper default windows doesn't close at ESC if dock. This is a floating window behavior in most case.

Ok, yes, I think this is the best argument: hitting escape in every other floating window in Reaper closes it. The floating distinction is key.

Note that I know that I am niptcking over small details, the work you made for rtk or reaticulate is of course amazing and shouldn't be dimissed by a simple ESC key issue 😄

No I completely agree, I'm all for sweating the details. I want to think carefully about what is maximally ergonomic and least likely to violate the Principle of Least Astonishment. (And copying Reaper's behavior isn't automatically a winning argument because Reaper is not itself entirely unimpeachable in the area of UX.)

Haha, sure, rtk had to be a real piece of work. Though now it is released, you can expect users asking questions about it 😋

For sure, I'm happy to support users. (The thread on the forum has been disconcertingly quiet though.)

jtackaberry commented 3 years ago

FWIW escape now closes floating windows by default in rtk.Window but for Reaticulate I'll still want things to be more customizable, and will need to think more about whether escape-closes-window is the right default behavior for Reaticulate (but I'm leaning toward no for the arguments made earlier).

X-Raym commented 3 years ago

Thanks for your consideration and your arguments :)

For rtk thread quietness, well, it is vacation so maybe people go less on forum. Maybe some screenshots catch their attention 😊

Anyway, thx for your support ! Cheers !