RFC: Web browsing and HTML in OE-Core

RFC: Web browsing and HTML in OE-Core

[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.

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

Re: RFC: Web browsing and HTML in OE-Core

[Phil Blundell]

On Thu, 2013-08-22 at 15:04 +0100, Richard Purdie wrote:
> 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.

Re: RFC: Web browsing and HTML in OE-Core

[Samuel Stirtzel]

2013/8/22 Richard Purdie <richard.purdie@linuxfoundation.org>:
> 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?


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).


-- 
Regards
Samuel

Re: RFC: Web browsing and HTML in OE-Core

[Otavio Salvador]

On Thu, Aug 22, 2013 at 11:04 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> 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?

Qt demos has a browser which might do the work.

-- 
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

Re: RFC: Web browsing and HTML in OE-Core

[Richard Purdie]

On Thu, 2013-08-22 at 16:24 +0200, Samuel Stirtzel wrote:
> 2013/8/22 Richard Purdie <richard.purdie@linuxfoundation.org>:
> > 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?
> 
> 
> 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

Re: RFC: Web browsing and HTML in OE-Core

[Richard Purdie]

On Thu, 2013-08-22 at 15:18 +0100, Phil Blundell wrote:
> On Thu, 2013-08-22 at 15:04 +0100, Richard Purdie wrote:
> > 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.

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

Re: RFC: Web browsing and HTML in OE-Core

[Phil Blundell]

On Fri, 2013-08-23 at 12:17 +0100, Richard Purdie wrote:
> 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.

Re: RFC: Web browsing and HTML in OE-Core

[Richard Purdie]

On Fri, 2013-08-23 at 16:56 +0100, Phil Blundell wrote:
> On Fri, 2013-08-23 at 12:17 +0100, Richard Purdie wrote:
> > 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?

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

Re: RFC: Web browsing and HTML in OE-Core

[Phil Blundell]

On Fri, 2013-08-23 at 17:14 +0100, Richard Purdie wrote:
> 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.