• 1
  • 5
  • 6
  • 7
  • 8
  • 9(current)
Time for a new or improved WebRemote interface?
I would assume, they 're all on porting to linux.

I did not read the whole thread with all technical details, but if I understand you all correctly, I already had another thought long ago concerning this topic:

I personally need no fancy client side GUI and animation. What I really would like to see is really useful and presumably much easier and less work Big Grin than the stuff discussed in this thread till now:

Simply
* generate a jpeg and/or other alternative picture formats on the XBox/server of the current screen
* send it to and display it on the client browser
* accept "clicks" on the picture, send them back to the server and execute them there
* loop Wink

This approach has several advantages:
* the whole XBMC can be controlled
* all current XBMC features are available immediately
* every skin is available
* every new and future feature is available immediately
* if you want new fancy interfaces: develop skins on XBMC and have it for all: client and server
* Nearly all functions/features needed for this approach are already almost present in http-api.
* No big development necessary
* No big runtime burden for XBMC
* No special memory foot print
* What do you want more ...? Cool

As far as I can see, jpeg is send only base64 encoded till now. Why? Huh Send it native and embed it into html. Nerd Allow for resolution selection at the start of the session. Then it can be used on my computer with 1400x1050 or on my PocketPC (with WLAN) with VGA or on other PocketPCs with 320x240 or something else.

My PocketPC even has a real keyboard. Allow for keyboard input additionally. Nod
Reply
Would you explain what you mean by "Send it native and embed it into html".

Reply
Usually, if you open a html page with embedded pictures or click onto a link for a picture, the pictures are viewable immediately with the browser (it's a direct link to a binary format, it's not base64 encoded and unviewable without conversion). This is meant with native. Perhaps not the best word to describe it.

A direct link/URL to a jpeg (the current screenshot) does not contain any logic that allows to click on any relative coordinate on that jpeg and send that click with its coordinates to the XBox. Therefore it should be embedded into a html page with some minimal client side logic.
Reply
In which case the image is not actually "sent" but is in fact "pulled" by the browser. The only standard way of sending an image that I know of is by base64 encoding the image into an html page.

Probably what you after is a bit of clever Ajax code.

Reply
Nad, yes, you are right and I am a bit "sloppy" (since english is not my native language) :o. But I am also surprised about your statements about "standard way".

Usually, you can send a GET or a POST via http and you can get any binary file, not only html, e.g. the following link directly leads to a jpeg:

http://upload.wikimedia.org/wikipedia/co...icture.jpg

You can download and save it (try it and you get a binary file like every usual download of zip and exe files) or you can view it directly with your browser.

You can embedd such a link into html in the following way:

<img border="0" alt="Bild:Sunflower as JPEG picture.jpg" src="http://upload.wikimedia.org/wikipedia/commons/b/b9/Sunflower_as_JPEG_picture.jpg" width="332" height="389" />

For an example see:
http://de.wikipedia.org/wiki/JPEG
and its html source.

Such a html-tag loads the image from the link immediately after the html with the link has been loaded.

The Xbox command:
http://xbox/xbmcCmds/xbmcHttp?command=ta...rue;imgtag

Should not return base64 within html tags, but simply a binary jpeg file without any html stuff. O.k. for backwards compatibility an additional parameter could be used, e.g. "binary":
http://xbox/xbmcCmds/xbmcHttp?command=ta...rue;binary
(flash=false, since this remote access may happen very often and may disturb; imgtag works with firefox but not with other browsers!(?))

So access to the WebRemote interface could simply return a html with an appropriate img-link like above. The html page should contain some JavaScript, that recognizes clicks on the jpeg and converts them to a XBMC-http-api sendkey command.

In detail:

1. The browser requests the start page of the webremote interface
2. XBMC returns a html page with screenshot link embedded into an img-tag
3. Immediately the browser subsequently requests the screenshot link (automatic 2nd request)
4. XBMC returns the current screenshot jpeg binary
5. The browser shows the picture and the user points and clicks onto the picture with the mouse
6. The JavaScript calculates the position on the screenshot and constructs an appropriate link for an XBMC-http-api mouse click sendkey command and submits it
7. XBMC receives and executes the mouse click, e.g. to change the current window
8. With some defer the JavaScript points the browser to the start page of step 1 again (loop)

Additionally the start page could contain a refresh button, to load the current screen again at any time and/or a "timeout/refresh time", when the timeout is reached, the page is reloaded with a new current screenshot.

The start page could also contain a selection box for different resolutions of the jpeg for different client plattforms (PC, PocketPC VGA and Pocket PC standard) and additionally two form fields for a custom resolution.

And last but not least, JavaScript could recognize every keyboard input into another form field and send any keystroke as request to Xbox.

That's all!

What do you think of it?
Reply
nate12o6, notice this http://forum.xbmc.org/showthread.php?tid=18680

Seems to be the continuation of this old thread. Saw it not until today before.

It may have big advantages over what I am suggesting here, but it may have big disadvantages, too, as LiquidIce629 himself says: "please use the firefox browser, ie does not like my css or scripts".

My suggestion is very powerful, small and easy and could work on most browsers and so may have its own big advantages. Call it: "simple web remote interface".
Reply
Unless I have missed something, the jpeg is not actually embedded within the html, only the link to the image is embedded within the html. As the html is rendered the browser requests the image from the xbmc web server.

When you say "XBMC returns a html page with screenshot link embedded into an img-tag" it sounds just like an html page being served from the xbmc web server. The httpapi wouldn't return the html of the entire page.

The thread that you refer to describes a "non-standard" (i.e. doesn't work with IE) method of embedding images. LiquidIce then requests additions to the api that will return paths to specific images which I think would provide you with what you are after (with some clever Ajax code). I have been meaning to work on LiquidIce's request for some time. Maybe soon...

Reply
You missed nothing Big Grin Now, we understand us.

In the perspective of an user the jpeg is embedded into an html regardless of the internal html details/implementation. I'm no expert of XBMC and all its internal stuff (web-server, http-API, webremote-interface, ...). I only know a little bit of it, so I am arguing from the perspective of an user Wink with some technical background and an idea. Cool

"Soon ...", sounds great Nod But a solution with 2 requests from browser to xbox for one screenshot:
1. screenshot request: saving a screenshot to a path on the xbox and
2. download request: accessing the path from the xbox
would make things a little bit more complicated for this purpose described here. So for this purpose additional parameter for shoot and download screen at once seems easier. (I don't know what the purpose of LiquidIce is!)

Why are you "insisting" on ajax? I don't now exactly again, but I worry that ajax premises much more than a simple JavaScript and too much to be able to run on nearly every browser, e.g. pocket pc (with only JavaScript Version 1.1 , IE 3.02 DOM, no VBScript, only one window).

If such a real simple solution is possible, it reaches most of the people!? Smile
Reply
THe advantage of something like Ajax is that processing can be done asynchronously on your browser rather than the usual: user action; call for new page; user action; call for new page...process. So for example an Ajax script could, in the background, periodically request a new screen grab, download and display, without effecting the user experience.

Reply
  • 1
  • 5
  • 6
  • 7
  • 8
  • 9(current)

Logout Mark Read Team Forum Stats Members Help
Time for a new or improved WebRemote interface?0