2012-08-02, 16:27
(2012-08-02, 13:48)Tolriq Wrote: I'm sorry but I must disagree on this one.You have to remember that xbmc is primarily developed to be used with a remote and not a full keyboard. The custom keymaps are there to allow users to map certain actions to specific keys and then map those keys to some key on their remote.
Users sets keymaps and use them afterwards so each user know perfectly what key does what action they do on his installation.
(2012-08-02, 13:48)Tolriq Wrote: I do agree that remote makers for show OSD or known commands must use the send action. But for advanced user (those same that to use personal keymaps) showing a keyboard for direct access to what they choose to do is much more logical.I would call myself an advanced user and I'd prefer a few customly defined buttons (ideally with a useful label) on a remote over a full keyboard where I have to remember which action is mapped to which key anytime. Much easier to remember that the button labelled "Show OSD" opens the OSD instead of having to remember that pressing "O" will open the OSD IMO. Sure those custom buttons require some work on the client side but IMO that would be much more user-friendly.
(2012-08-02, 13:48)Tolriq Wrote: A user that is tell to copy a custom keymap for a specific addon will do that but don't really understand what he do.Something like that example (Addon.OpenSettings(script.xbmc.boblight)) won't be possible over Input.ExecuteAction and I don't plan to add support for it either because there's no way to do some sanity check before executing such an action. What I meant by providing the user with a configurable interface was that you provide them with buttons that do not have any action applied and then they can choose from a list of available actions (which can be extracted from the introspect of Input.ExecuteAction) and apply those actions to the available buttons. That way there's no need for the user to type in some complex command or having to create a custom keymap.
Giving the user a very complex interface so that he type the command like : Addon.OpenSettings(script.xbmc.boblight) (don't even know if it does work in current implementation).
And I don't talk about the complexity of developing such interface to present a beautiful interface for end user.
(2012-08-02, 13:48)Tolriq Wrote: And of course you loose the use of physical phone keyboard (This one is also true for the SendText that can't do direct keyboard to dialog with backspace support).Yesterday I merged a PR which will provide you with the current value of the currently active input box in the Input.OnInputRequested notification. So there's no need for you to remember anything. When you receive the notification pop up the virtual keyboard (or let the user use the hardware keyboard) and let him alter the value of the input box. When he's done he presses Enter (or whatever) and you use Input.SendText to send the text to XBMC. If the user then realizes that he made a mistake he can focus the input box again and just change whatever was wrong with the first value.
This is more work for user to start a dialog to put a text send it. Then realize there's an error, and retype it completely. (Yes I can let the old text for next try but then if it's a new dialog the user have a manual action to clear text).