[RockerC]

I think that TV Browser from the MeeGo project (yes the MeeGo TV Browser project is still active) would be a very interesting candidate to embedding into XBMC because of its its Control API and framework.

http://wiki.meego.com/TV_Browser

MeeGo TV Browser is a WebKit derivative with framework for Control API and JavaScript API that was both designed for a 10-foot user interface and to accept alternative input methods.

http://wiki.meego.com/File:Meego_TV_Browser_V0.2.odt

The internet world has created browser for PC. Assuming not only a mouse and a keyboard, but also a 50 cm viewing with a multi windows presentation layer and a skilled human who drive the beast. Unfortunately, a TV has neither a keyboard or a mouse, the vision is done from 3m, there is no windowing concept and the Live TV presentation remains in control of the UI all the time. TV needs is a browser which address some critical issues. Controllable by an external application. Instant start Accept alternative input method Support HW accelerated Video

Might be a better idea though to embed the WebKit2 fork or Chromium's WebKit fork, and just rip out the Control API and the frameworks for it out of MeeGo TV Browser and integrate those into XBMC?


Other than being able to render existing HTML5, CE-HTML, and XHTML based apps as addons inside XBMC, most HTML layout engines can also playback DRM protected streams.

Many also integrate Adobe Flash support so that it would be possible to control Flash based apps such as Netflix, so XBMC could have Netflix in it similar to what Boxee does if you wanted.

Unfortunately I couldn't find any other open source HTML rendering engines, so unless anyone knows about some other, those two would have to do

WebKit should be best for XBMC since it is both designed for embedding, have a small footprint and few dependencies, and there is a very large number of developers working on it upstream.

http://en.wikipedia.org/wiki/WebKit#Components

WebKit2 could be a good alternative, but maybe not since it breaks API compatibility with upstream WebKit

http://arstechnica.com/apple/2010/04/web...-renderer/

or Chromium WebKit fork which has been abstracted WebKit in a similar way

http://trac.webkit.org/wiki/WebKit2

WebKit2's goal is to abstract the components that provide web rendering cleanly from their surrounding interface or application shell, creating a situation where, "web content (JavaScript, HTML, layout, etc) lives in a separate process from the application UI". This abstraction is intended to make WebKit2's reuse a more straightforward process than WebKit's. WebKit2 has "an incompatible API change from the original WebKit", which motivated its name change.

There are also many more WebKit forks and derivatives downstream, but most of them are probably overkill to consider as embedded HTML layout engine library for XBMC, but most contribute upstream.

http://en.wikipedia.org/wiki/List_of_web...bKit-based

[RockerC]

I could not find usage share statistics for HTML layout engine cores used, but Wikipedia has statistics via StatCounter for usage share of web browsers:

http://en.wikipedia.org/wiki/Usage_share...b_browsers
http://gs.statcounter.com/#browser-ww-mo...807-201206

It shows that WebKit based web browsers hold approx 50% of the market today and rising fast of the global market, with Google Chrome being largest.

Judging by that it would be smartest to go with a WebKit derivative such as Chromium if you want the gain the benefit of most upstream developers.

[topfs2]

a) meego is designed for PCs and for phones. Yes its a for small devices and the interface is big. but its not designed for key based input only, atleast afaik?

Secondly, the reason for finding an API is to find something which is actually used out in the wild, if it isn't we could just aswell invent something ourself (which we already have in python, voila). So stats on how many sites use a perticular 10foot interface through some form of API/Framework is MUCH more interesting than what engine used. THere is already code afaik which have a complete webkit in xbmc, although it may never be merged due to using qt is outside of the question. Focus on finding an API which is USED, and works with XBMC. If that exist we could start discussion how to get webengines in xbmc.

I still doubt there is a valid enough API/Framework which warrents the massive undertaking it is to get a web engine inside xbmc in a small enough way so its portable cross all platforms.

[itaibh]

Some APIs I found for remote controlling TVs using Javascript are:

Zinc - http://pc.zinc.tv/developers/javascript
Samsung - http://www.samsungdforum.com/upload_file...vents.html
DirecTV - http://whitlockjc.github.com/directv-remote-api/

While the Zinc approach is more intuitive at first, it is unscalable, as it requires the user to register each and every key. The other two approaches are very similar as they both allows you to register one function and then test which key was pressed, much like the current APIs for keyboard.

Still, there is no standard, nor anything that becomes a "standard de facto". I guess it is because there is not much demand currently for TV web-browsing (and for the same reason there are no many sites that are also designed for TV, and you can't find much about how to design a website for TV in design forums).

I think that the best way to make such thing happen is to enable it in media centers. As more and more users are starting to use media centers and HTPCs as their main entertainment system, more sites will be available once people will have to option to browse the web from their couch :-)

[da-anda]

@browser engine - I'd prefer webkit over gecko because it's way closer to the HTML standards and actually the nicest engine to create websites on.

@APIs. I'm really not sure if there is really one widely used API around or if it's really needed at all. I mean, JavaScript already has it's methods to detect key presses, touch gestures and mouse events - so we don't have to reinvent the wheel and just passthru the native cursor movement from XBMC. If we really liked, we could add enhanced events for better touch support - but this is IMO not needed, because there are most likely native apps for things like netflix on touch devices (iOS/droid). So there isn't much needed besides of XBMC events, player controls and probably a interface to the DB, but this could actually also be done using our JSON interface (so also no additional work needed IMO). The only thing that would have to be implemented is some kind of hw-accelerated wrapper for the audio/video HTML-tag and have it support the HTML commands to play/pause/seek etc.

@phoneGap
The API reference is here: http://docs.phonegap.com/en/2.0.0/ And all it does it providing access to system variables/functions from which we probably only need "device", "events", "media", "notification" and "storage"

Maybe just compare it with the Windows8 API and implement methods available in both and we're good to go.

[topfs2]

@APIs. I'm really not sure if there is really one widely used API around or if it's really needed at all. I mean, JavaScript already has it's methods to detect key presses, touch gestures and mouse events - so we don't have to reinvent the wheel and just passthru the native cursor movement from XBMC. If we really liked, we could add enhanced events for better touch support - but this is IMO not needed, because there are most likely native apps for things like netflix on touch devices (iOS/droid). So there isn't much needed besides of XBMC events, player controls and probably a interface to the DB, but this could actually also be done using our JSON interface (so also no additional work needed IMO). The only thing that would have to be implemented is some kind of hw-accelerated wrapper for the audio/video HTML-tag and have it support the HTML commands to play/pause/seek etc.

You will need additions of onLeft, onRight etc to be able to navigate with a remote. Android tries to do it without any additional APIs and while it does work to some extent its far from nice.

Anyways, if someone creates a patch with webkit integration which is portable across all our platforms (which is a major undertaking) then perhaps that will be accepted into mainline. The reason I mention APIs is that I was interested to know if there would be a way to only support that API and xhtml, without webkit. But I suspect it will not.

If you want to navigate the web on a HTPC I'd suggest going for an Android HTPC, you have the ability to launch the webbrowser just fine from there.

[RockerC]

meego is designed for PCs and for phones. Yes its a for small devices and the interface is big. but its not designed for key based input only, atleast afaik?

That is a common misunderstanding; MeeGo (and Tizen) was actually just designed as a OS for embedded systems, just like Android, so it not an OS only made for phones.


MeeGo Smart TV project is specifically designed as 10-foot GUI set-top boxes and television sets, and it actually uses a ported version of XBMC PVR as their reference UI.

http://wiki.meego.com/Smart_TV

MeeGo TV Browser that I mentioned is a separate sub-project of the MeeGo Smart TV project, and it too is specifically designed as 10-foot GUI set-top boxes and TV sets.

http://wiki.meego.com/TV_Browser

MeeGo TV Browser has that is made for the TV, 10-foot GUI to be viewed from 3-meter distance, and interface has been made to use a remote control as input, just like XBMC.



Both MeeGo Smart TV and MeeGo TV Browser can be found in the wild, unfortunate they just don't advertise it, even though their aim is to make it into a framework standard.

They sell Intel CE4100, CE4200 and CE5300 development set-top box platforms for MeeGo TV suite on http://shop.cc-e.eu with their XBMC fork as part of the Software Developers Kit

http://shop.cc-e.eu/SDK



MeeGo TV 1.2.2 on Cocom Intel CE hardware video (note that this is not the MeeGo TV Browser but only a demo of the XBMC PVR fork for MeeGo just to prove it's for TV too)

http://www.madeo.co.uk/?p=947

You will need additions of onLeft, onRight etc to be able to navigate with a remote.

Again, MeeGo TV Browser does have the Control API to specifically handle that, but it uses a set of DBus APIs instead of WebSockets which be a better for cross-platform support

http://wiki.meego.com/TV_Browser_Control_API

http://wiki.meego.com/TV_Browser_Javascript_API


Please just follow these links and look at the information provided, it though not take long to read though that to get a good overview, I promise that you will be pleasantly surprised!

More information is hidden away on the MeeGo TV mailing-list http://lists.meego.com/listinfo/meego-tv



MeeGo TV projects API in this case tries to follow the Open IPTV Forum standards specification DAE (Declarative Application Environment) v2.1

http://www.oipf.tv/docs/Release2/V2.1/OI...-06-21.pdf

[MassIV]

Did you guys catch this?
http://www.youtube.com/watch?v=uVYbwin_2...age#t=320s

[itaibh]

@MassIV - It's a nice idea, but I personally don't like it.
It can be an optional navigation mode in addition to a moving cursor, and only for sites that have not been adapted to TV browsing.

CSS have many media types defined, including (in addition to "screen") "handheld", "projection" and "tv".
I don't know of any website that are using "tv" ("projection" is probably used in websites that display slides in fullscreen) and unfortunately I cannot (well, haven't yet found a way) to test such websites on my PC (at least using chrome), and since my TV is nothing but a 42" screen connected to a Linux PC, I can't test it there either, so all I can do is create mock-ups of how I think websites should look and behave when presented on TV.

But, this is besides the point of this thread, since once some HTML rendering ability is integrated into XBMC, it should support those features, in addition to "regular" navigation methods fallback including moving cursor (though remote control or the mouse, if mouse is enabled in XBMC), moving the site in the background while keeping constant selection point in the middle like in the video MassIV posted, or any other fallback method that comes to mind.

---

You will need additions of onLeft, onRight etc to be able to navigate with a remote. Android tries to do it without any additional APIs and while it does work to some extent its far from nice.

I don't think that events like onLeft and onRight should be exposed, for the same reason there are no onAPressed, onBPressed ... onZPressed etc.

I see no reason why the remote control keys are not given a corresponding key code for the onKey events, or at least have one new event called onRemoteKey (or something similar) that tells you which key was pressed.

[topfs2]

I don't think that events like onLeft and onRight should be exposed, for the same reason there are no onAPressed, onBPressed ... onZPressed etc.

I see no reason why the remote control keys are not given a corresponding key code for the onKey events, or at least have one new event called onRemoteKey (or something similar) that tells you which key was pressed.

You don't need to have that method explicitely no but you do need some way of knowing when left, right, up, down is pressed so you can navigate with a dpad more integrated, rather than the way done in big picture (which is still a somewhat nice fallback but rather unpleasent as properly integrated plugins, which this thread is about).
I mostly stated it as afaik there is no onKey in ECMA or is there? (I'm not the best web dev )

[itaibh]

@topfs2 - there are onKey events in JavaScript (aka EcmaScript) if that is what you meant.

[itaibh]

I've found some details regarding the Google TV, more likely IMO to become a standard de-facto regarding navigation:

https://developers.google.com/tv/web/doc...v#keyboard

They also have design guidelines and checklists for TV Enabled websites.

[mikepixie]

I am new to this forum and signed up to add my 2 cents to this thread. It would be great to have the ability to run HTML5 apps from XBMC. I make the odd game using Scirra Construct 2 and I also develop with Javascript. One of the best and most recent features for gaming is that the chromium browser can now accept input from an xbox 360 controller out the box, almost any controller will work with some tweaking. The ability to run HTML5 games would be quite a pleasent bonus imho.