This suggestion ties together with "Grant scripts in browsers access to skin data."
Browsers already provide a means of processing data on the client. I feel much potential has come from the ability of the server to execute code in a client's browser, but why stop there?
I propose that macros, buttons, inputs, and any other control that can execute verbs be given a means to execute functions in a browser. The script may then interpret the input, adjust it, throttle it, send instructions to the server, or perform some magic as proposed in the suggestion linked above.
The major benefit in this is having lagless interface controls. Currently, in order for a button to intelligently modify the interface, (such as appending text to an input control, or performing an action based on the state of other controls) it must execute a verb on the server, which must query the client's controls with winget, and then apply changes with winset. A script in a browser can perform such complex manipulations of the interface instantly, and with no hit on the server.
Bonus points if the browser could hook into and listen for events such as mouse up/down, and resizing.
Resolved
| |||||||
Yeah, I'm aware of these things. I realise now in hindsight that the second paragraph is a bit ambiguous, but I was actually referring to that feature being added to output(). I cried tears of joy when I saw that change log back then, by the way. =D
I'm hoping for a way to trigger functions in a browser script instantly from skin controls, without waiting for the server to respond. As for .winset, the downside is that their decision making abilities are very limited. Take Chatters for instance. It has buttons on the interface to append preset strings of text to the input box. (Emoticons, color codes, etc) When one of these are pressed, it take about a second for the input box to update. Anything the user types after the server makes its winget() call is lost. The formatting buttons also need to be intelligent enough to know if they should add a closing tag instead, and they must be reset each time the user sends a message. All of these over-the-wire winset/get calls could be removed if a browser script were to handle the button and input controls. Most of all, the UI would be incredibly responsive. Though of course, everything I just mentioned would require the other suggestion to be implemented. Was I correct to split the two? | |
Ter13 resolved issue with message:
Feature was addressed in 504.1228 and 504.1229. | |
The other thing to note is that BYOND does have a concept of local interface verbs, via the .winset call. That call does not go through the server at all and directly executes the equivalent winset() on the client. Although I don't think there is a way for the browser to directly call a .winset at the moment (the normal usage is to have .winset used as the command for a button click or checkbox).
I don't think this really addresses what you're getting at in these two requests, but you might play with these things. We can see what we can do to provide better client-side hooks.