thefourthdoctor Wrote:You're right - I have no idea how easy/hard it is. I was thinking along the lines of just adapting something like webkit and figured it probably wouldn't be too different than using the webbrowser control in Windows. But maybe it isn't that simple. If it's too hard, it's too hard.
I was looking into this. The main problem is that you need a widget library (something that draws buttons, checkboxes, input fields, etc.) which is plattform independent. Of course there are some libraries like i.e. Qt, but these libraries have a lot of dependencies, which always is a bad thing.
As the XBMC developers probably won't accept anything that pulls in a lot of dependencies, I was looking into the rendering engine
Berkelium, which is based on Google Chrome. This seems like a very nice solution at the first look, but it has some shortcomings which need to be addressed. First of all it is very slow. Rendering the browser into a texture and then displaying the texture gives you a delay for all your inputs which is at the least very annoying.
Still I thought it would be worth a try, so I made some local tests with non-XBMC code to see how the whole thing could work out when rendered directly into a OpenGL window. Overall it seems possible to implement a browser on that engine but still there are lots of things that need to be implemented. As the main goal should be to be able to navigate webpages with your remote, you have to find a way to jump from one widget (input field, button,...) to the next one and also be able to navigate the page when there are no widgets. I thought about implementing it like the Android web browser where you can navigate the page with your scroll wheel by jumping from one widget to the next one.
Navigating the page when there are no widgets at all is actually the easy part, as you can just send normal mouse-scroll-wheel events. Navigating the page by jumping from one widget to the next one is hard, as it requires Javascript code with hooks that link back to your C++ source. Implementing and testing this could take a long time.
However the first version of the browser could just require a mouse, so that there is at least a browser available. So I started looking at the XBMC code to find the optimal solution to implement a widget which can load its texture from memory (the browser window). I got kind of stuck and
asked for some advice on the forums but did not get any answer. Since then I didn't have the time to do my own experiments.
Quote:I was more reacting to the comment that a browser didn't belong in a media player. I'm not entirely sure that's true.
I totally agree with you, a browser would be a great thing to have. The Firefox solution is not very nice at all.