+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+---- Forum: JSON-RPC (https://forum.kodi.tv/forumdisplay.php?fid=174)
+---- Thread: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC (/showthread.php?tid=68263)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-12-01
Yeah there's no real naming rule. That's why you should always look at the actual definitions and not just guess based on the name
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-12-01
TBH I work directly with https://github.com/xbmc/xbmc/blob/master/xbmc/interfaces/json-rpc/methods.json and not using the Introspect
And I did not see a way to get the difference between the single string and an array but this is also my fault :p (Before reading the .cpp :p)
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-12-01
Well you also need to check types.json to get the information on the referenced types. There you'll see if a type is defined with "type": "array" or "type": "string".
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Tolriq - 2012-12-01
That what I did but I've just figured out that I missed a little detail
The array type is defined in "Item.Fields.Base" for Addon.Fields so not directly visible
Won't do the same mistake next time thanks for helping me figuring out where my laziness was :p
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - claymic - 2012-12-02
Hi
I just start to migrate to JSON V5. for now everything its fine, but i need a little help with some commands (old http)
- Container.NextViewMode and previous view mode
- simulate SendClick(14) to hide or show watched files
There is anyway to make this using JSON RPC V5 ? I tried to found similar actions in Input.ExecuteAction, but dont found, maybe i am missing something.
Another question, where i can find the parameters for GUI.ActivateWindow ?
Thanks for your help
Clayton
p.s maybe i understand now how to use the GUI.ActivateWindow , if i want to open the window movie sets i just have to use MovieSets like a parameter, i will test.
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-12-02
(2012-12-02, 18:46)claymic Wrote: - Container.NextViewMode and previous view modeAre those info labels or an action? If they are info labels you can use XBMC.GetInfoLabels.
(2012-12-02, 18:46)claymic Wrote: - simulate SendClick(14) to hide or show watched filesHm is 14 the ID of the show/hide watched button in the skin you are using? Because I don't know of any action that does this in XBMC. If it's skin specific JSON-RPC doesn't support it.
(2012-12-02, 18:46)claymic Wrote: Another question, where i can find the parameters for GUI.ActivateWindow ?
p.s maybe i understand now how to use the GUI.ActivateWindow , if i want to open the window movie sets i just have to use MovieSets like a parameter, i will test.
Yeah those are not very well documented AFAIK. Basically you need to open the video window and e.g. pass in MovieSets or MovieGenres etc. The video-related parameters can be found in xbmc/video/windows/GUIWindowVideoNav.cpp.
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - claymic - 2012-12-02
(2012-12-02, 20:44)Montellese Wrote: Are those info labels or an action? If they are info labels you can use XBMC.GetInfoLabels.I use this like a http command To change view modes in the skin.
Quote:CF.send("Xbmc", "/xbmcCmds/xbmcHttp?command=ExecBuiltIn(Container.NextViewMode)");
(2012-12-02, 20:44)Montellese Wrote: Hm is 14 the ID of the show/hide watched button in the skin you are using? Because I don't know of any action that does this in XBMC. If it's skin specific JSON-RPC doesn't support it.I just search in this page https://github.com/xbmc/xbmc/blob/master/xbmc/guilib/Key.h , tried in my xbmc and works very well, hide or show the watched movies or tvshows in xbmc, but i send this like a http command too:
Quote:CF.send("Xbmc", "/xbmcCmds/xbmcHttp?command=ExecBuiltIn(SendClick(14))");maybe its specific for the skin, i will try to find another way to do this, there is anyway to simulate SendClick with JSON ?
(2012-12-02, 20:44)Montellese Wrote: Yeah those are not very well documented AFAIK. Basically you need to open the video window and e.g. pass in MovieSets or MovieGenres etc. The video-related parameters can be found in xbmc/video/windows/GUIWindowVideoNav.cpp.I found the windows here http://wiki.xbmc.org/index.php?title=Opening_Windows_and_Dialogs, works nice for me.
Thanks Montellese for all your help. Congrats, i test the V5 several times today, its amazing and fast, i will only use V5.
Clayton
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - claymic - 2012-12-02
I am sorry Montellese, i post wrong, to change the watched i map the skin, i maked this several months ago for hide or show watched videos and play the trailer without have to show the info window or the menu.
I think the only way to make this with the Frodo Beta 2 will be creating a script to do the job or am i wrong ?
Thanks
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - gertjanzwartjes - 2012-12-02
I'm in the process of replacing HTTP API stuff with pure JSON for the upcoming Frodo release; actually the main purpose I was still using the HTTP API was for sending keys (like many others) to emulate keyboard presses. I understand that for the JSON API you want to only expose functionality to input text into text boxes, I've been following the discussions closely and I fully agree with the arguments to keep the API simple and just revert to the event server for full control. So I wanted to restrict keyboard emulation to just using SendText for input boxes in the XBMC GUI; for all the other stuff there's now plenty of functionality in the JSON API, thanks for that!
One thing I do find particularly important is to be able to have the user edit text that's already in an input box; so I like the OnInputRequested notification.
However, there are a quirks with the new SendText and OnInputRequested. First of all, you don't get an input requested when you move onto an input box, without actually pulling up the virtual keyboard in XBMC. For example try the username/password setting in the Webserver settings pane. You can edit this box without going into the virtual keyboard window, but there's no OnInputRequested notification when moving onto that input. Is there a way to get and OnInputRequested notification here too? Or is not getting the notification by design?
Also, when you do send a SendText method while in that particular screen, it will fill out _all_ text boxes (i.e. port, username and password). It works that way for all screens that have multiple input boxes. I guess that's a bug?
I can think of workarounds to these issues, however, I was wondering what the thoughts on the XBMC development side of things about this are before working around it on the client side.
Thanks!
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-12-03
(2012-12-02, 23:00)gertjanzwartjes Wrote: However, there are a quirks with the new SendText and OnInputRequested. First of all, you don't get an input requested when you move onto an input box, without actually pulling up the virtual keyboard in XBMC. For example try the username/password setting in the Webserver settings pane. You can edit this box without going into the virtual keyboard window, but there's no OnInputRequested notification when moving onto that input. Is there a way to get and OnInputRequested notification here too? Or is not getting the notification by design?Thanks for the report, I'll look into how feasible this is for normal controls (i.e. not keyboard dialogs).
(2012-12-02, 23:00)gertjanzwartjes Wrote: Also, when you do send a SendText method while in that particular screen, it will fill out _all_ text boxes (i.e. port, username and password). It works that way for all screens that have multiple input boxes. I guess that's a bug?Yup it is and it should be fixed with https://github.com/xbmc/xbmc/commit/2efa3c0c1b56dd44d33606c5676ff1872f531ab0. Thanks for mentioning it.
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-12-03
(2012-12-02, 23:00)gertjanzwartjes Wrote: However, there are a quirks with the new SendText and OnInputRequested. First of all, you don't get an input requested when you move onto an input box, without actually pulling up the virtual keyboard in XBMC. For example try the username/password setting in the Webserver settings pane. You can edit this box without going into the virtual keyboard window, but there's no OnInputRequested notification when moving onto that input. Is there a way to get and OnInputRequested notification here too? Or is not getting the notification by design?
OK I've had a quick look at this and here is the problem: Let's say xbmc sends a OnInputRequested notification everytime a user focuses an edit control and an OnInputFinished notification when the user unfocuses the edit control. Here is what can happen:
- User focuses edit control -> OnInputRequested notification
- User presses enter -> virtual keyboard dialog opens -> another OnInputRequested notification
- User enters some text and then closes the dialog -> OnInputFinished notification
- User is still focused on the edit control
- User leaves the edit control -> OnInputFinished notification
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - gertjanzwartjes - 2012-12-03
(2012-12-03, 01:09)Montellese Wrote: Yup it is and it should be fixed with https://github.com/xbmc/xbmc/commit/2efa3c0c1b56dd44d33606c5676ff1872f531ab0. Thanks for mentioning it.No prob, and thanks for fixing it!
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - gertjanzwartjes - 2012-12-03
(2012-12-03, 09:36)Montellese Wrote: OK I've had a quick look at this and here is the problem: Let's say xbmc sends a OnInputRequested notification everytime a user focuses an edit control and an OnInputFinished notification when the user unfocuses the edit control. Here is what can happen:It's indeed not trivial. What about this flow:
IMO that's not very intuitive behaviour as you get two OnInputRequested notification and you get an OnInputFinished notification even though you are still in a control that accepts text input. I'm not sure what the best solution would be.
- User focuses edit control -> OnInputRequested notification
- User presses enter -> virtual keyboard dialog opens -> another OnInputRequested notification
- User enters some text and then closes the dialog -> OnInputFinished notification
- User is still focused on the edit control
- User leaves the edit control -> OnInputFinished notification
- User focuses edit control -> OnInputRequested notification
- User presses enter -> virtual keyboard dialog opens -> first send an OnInputFinished because the input control loses focus in favor of the virtual keyboard, and then send an OnInputRequested notification
- User enters some text and then closes the dialog -> OnInputFinished notification
- User is still focused on the edit control; actually the control gets focus again, it was defocused by the virtual keyboard, so send a new OnInputRequested
- User leaves the edit control -> OnInputFinished notification
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Montellese - 2012-12-03
I don't develop any client but what I don't like about this approach is that it probably results in a flickering of the keyboard being presented because it's most likely hidden when the OnInputFinished is received and then immediatelly shown again when the OnInputRequested is received. An idea would be to use this behaviour but to add an additional parameter to the notifications letting clients know whether the input is a virtual keyboard dialog (in which case the user of the client will most likely want to see the keyboard on the client as well) or not (in which case the user might not want to see the keyboard on the client as he may just be navigating around and had to go through an edit control).
Another approach might be to not send an OnInputRequested/OnInputFinished notification when going from an edit control to the virtual keyboard dialog. That way the client will be able to show the virtual keyboard from the moment the edit control is focused, throughout the time where the virtual keyboard dialog is opened and closed until the user leaves the edit control. The problem with this approach is, is that the "done" parameter of Input.SendText becomes a bit unintuitive as focus will still be on the edit control.
RE: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - gertjanzwartjes - 2012-12-03
Yeah, I wasn't planning on showing the keyboard on OnInputRequested anyway, because I don't want to pop up the keyboard over the whole UI whenever a user is just browsing over input controls, so I think an additional property makes sense indeed.
Another possibility is to add a method to request the text of the current control or virtual keyboard if there is any text to be retrieved (something like Input.GetText), possibly adding an additional boolean return value whether an input control was focused or virtual keyboard was active for a client to know whether it would make sense to send text. That would allow clients to implement keyboard interaction even without depending on notifications. Don't know if that would make sense on the server side?