RFC: Web browsing and HTML in OE-Core
We've slowly been shaking out the definition of OE-Core and as part of that we removed web and web-gtk which were the only browsers in there and were admittedly a bit limited/broken.
There is no doubt that web technology has an increasingly important role in the future and in embedded devices (e.g. kiosk type devices, digital signs and so on).
With that in mind, I think some kind of HTML support in OE-Core is important going forward. Equally, I dislike having things there which we cannot test. I know some people have looked into this and it appears midori is the best option for something with a small number of additional dependencies. I therefore currently think this is something we should make a decision to include since it gives us significantly better coverage of things like webkit which are a already in the core yet totally untested at present.
I'm open to opinions, equally we do need to make a decision on this soon since we're nearly at the feature freeze point. Thoughts?
Cheers,
Richard
Quoted 8 lines · Richard Purdie
With that in mind, I think some kind of HTML support in OE-Core is important going forward. Equally, I dislike having things there which we cannot test. I know some people have looked into this and it appears midori is the best option for something with a small number of additional dependencies. I therefore currently think this is something we should make a decision to include since it gives us significantly better coverage of things like webkit which are a already in the core yet totally untested at present.
WebKit itself comes with a bunch of test wrappers (and tests!) for different platforms and if the aim of the exercise is to test webkit then it seems like maybe we should just be installing and using those. Midori would be fine for testing the parts of webkit that it uses, but obviously it doesn't exercise anything other than the Gtk port which still leaves you with a bit of a hole in your coverage.
p.
2013/8/22 Richard Purdie <[email protected]>:
Quoted 17 lines
We've slowly been shaking out the definition of OE-Core and as part of that we removed web and web-gtk which were the only browsers in there and were admittedly a bit limited/broken.
There is no doubt that web technology has an increasingly important role in the future and in embedded devices (e.g. kiosk type devices, digital signs and so on).
With that in mind, I think some kind of HTML support in OE-Core is important going forward. Equally, I dislike having things there which we cannot test. I know some people have looked into this and it appears midori is the best option for something with a small number of additional dependencies. I therefore currently think this is something we should make a decision to include since it gives us significantly better coverage of things like webkit which are a already in the core yet totally untested at present.
Quoted 2 lines
I'm open to opinions, equally we do need to make a decision on this soon since we're nearly at the feature freeze point. Thoughts?
Hi,
just some thoughts: Qt provides an example application that uses webkit called "fancybrowser"
This demo it is located at the package qt4-examples (/usr/bin/qt4/examples/webkit/fancybrowser/ in the target sysroot).
Signature · 2 lines
Regards Samuel
Quoted 17 lines · Richard Purdie
We've slowly been shaking out the definition of OE-Core and as part of that we removed web and web-gtk which were the only browsers in there and were admittedly a bit limited/broken.
There is no doubt that web technology has an increasingly important role in the future and in embedded devices (e.g. kiosk type devices, digital signs and so on).
With that in mind, I think some kind of HTML support in OE-Core is important going forward. Equally, I dislike having things there which we cannot test. I know some people have looked into this and it appears midori is the best option for something with a small number of additional dependencies. I therefore currently think this is something we should make a decision to include since it gives us significantly better coverage of things like webkit which are a already in the core yet totally untested at present.
Quoted 2 lines
I'm open to opinions, equally we do need to make a decision on this soon since we're nearly at the feature freeze point. Thoughts?
Qt demos has a browser which might do the work.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Quoted 22 lines · Samuel Stirtzel
2013/8/22 Richard Purdie <[email protected]>:
Quoted 17 lines
We've slowly been shaking out the definition of OE-Core and as part of that we removed web and web-gtk which were the only browsers in there and were admittedly a bit limited/broken.
There is no doubt that web technology has an increasingly important role in the future and in embedded devices (e.g. kiosk type devices, digital signs and so on).
With that in mind, I think some kind of HTML support in OE-Core is important going forward. Equally, I dislike having things there which we cannot test. I know some people have looked into this and it appears midori is the best option for something with a small number of additional dependencies. I therefore currently think this is something we should make a decision to include since it gives us significantly better coverage of things like webkit which are a already in the core yet totally untested at present.
Quoted 2 lines
I'm open to opinions, equally we do need to make a decision on this soon since we're nearly at the feature freeze point. Thoughts?
Quoted 6 lines
Hi,
just some thoughts: Qt provides an example application that uses webkit called "fancybrowser"
This demo it is located at the package qt4-examples (/usr/bin/qt4/examples/webkit/fancybrowser/in the target sysroot).
The webkit with qt is a bit different from the standalone webkit and would just test the qt version. Certainly something to think about but I'm not sure its quite what we need...
Cheers,
Richard
Quoted 10 lines · Phil Blundell
Quoted 8 lines · Richard Purdie
With that in mind, I think some kind of HTML support in OE-Core is important going forward. Equally, I dislike having things there which we cannot test. I know some people have looked into this and it appears midori is the best option for something with a small number of additional dependencies. I therefore currently think this is something we should make a decision to include since it gives us significantly better coverage of things like webkit which are a already in the core yet totally untested at present.
Quoted 6 lines
WebKit itself comes with a bunch of test wrappers (and tests!) for different platforms and if the aim of the exercise is to test webkit then it seems like maybe we should just be installing and using those. Midori would be fine for testing the parts of webkit that it uses, but obviously it doesn't exercise anything other than the Gtk port which still leaves you with a bit of a hole in your coverage.
I think ultimately we need both, a real world user of webkit and also a webkit-ptest type package too. They both let us test different things, one probably more quickly than the other, with the other being more complete.
Cheers,
Richard
Quoted 4 lines · Richard Purdie
I think ultimately we need both, a real world user of webkit and also a webkit-ptest type package too. They both let us test different things, one probably more quickly than the other, with the other being more complete.
Well, logically that would mean that we'd need a real-world user of webkit for every port (or at least, for the three ports that are currently supportable within oe-core). It's not obvious that this would scale very well.
What are the things that you think would be tested better with midori than with the standalone launcher and test wrappers?
p.
Quoted 6 lines · Phil Blundell
Quoted 4 lines · Richard Purdie
I think ultimately we need both, a real world user of webkit and also a webkit-ptest type package too. They both let us test different things, one probably more quickly than the other, with the other being more complete.
Quoted 7 lines
Well, logically that would mean that we'd need a real-world user of webkit for every port (or at least, for the three ports that are currently supportable within oe-core). It's not obvious that this would scale very well.
What are the things that you think would be tested better with midori than with the standalone launcher and test wrappers?
What does the standalone launcher give you?
What I'm thinking is that having a browser interface QA can click on from the desktop and enter say 5 urls into is fast yet tests a significant amount of the system, much like booting X on a system doesn't test everything but it does test a fair amount of simple things like whether the binaries work.
Cheers,
Richard
Quoted 1 line · Richard Purdie
What does the standalone launcher give you?
Basically a very simple browser-type application that you can launch with a URL from the command line and see the resulting page in a window. Generally you also get some rudimentary UI controls, back/forward buttons and an address bar, that sort of thing.
The Qt port actually seems to have a slightly more sophisticated thing in the form of QtTestBrowser, but I've never used that myself. Anyway, I guess the key thing is that every port has at least something, and these ship with (and are maintained as part of) webkit itself.
p.