Chrome DevTools Protocol and Pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Chrome DevTools Protocol and Pharo

Torsten Bergmann
Hi,

I played around with remote controlling Google Chrome from
Pharo using Chrome DevTools Protocol [1] (based on WebSockets).

The video shows an example using latest Pharo 6 on Mac:
https://www.youtube.com/watch?v=9F5FrQTEJWY 

Initial Code is on GitHub [2] if someone is interested,
requires OSOSX and Zinc Websockets to be loaded.

Have fun
T.

[1] https://chromedevtools.github.io/devtools-protocol
[2] https://github.com/astares/Pharo-Chrome

Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

nacho
Excellent! I love it.



Lic. Ignacio Sniechowski, MBA
Prosavic SRL
  (5411) 4542-6712
📱 (54911) 6749-4721




















On Thu, May 18, 2017 at 4:08 PM, Torsten Bergmann [via Smalltalk] <[hidden email]> wrote:
Hi,

I played around with remote controlling Google Chrome from
Pharo using Chrome DevTools Protocol [1] (based on WebSockets).

The video shows an example using latest Pharo 6 on Mac:
https://www.youtube.com/watch?v=9F5FrQTEJWY 

Initial Code is on GitHub [2] if someone is interested,
requires OSOSX and Zinc Websockets to be loaded.

Have fun
T.

[1] https://chromedevtools.github.io/devtools-protocol
[2] https://github.com/astares/Pharo-Chrome




If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Chrome-DevTools-Protocol-and-Pharo-tp4947589.html
To start a new topic under Pharo Smalltalk Developers, email [hidden email]
To unsubscribe from Pharo Smalltalk Developers, click here.
NAML

Nacho Smalltalker apprentice. Buenos Aires, Argentina.
Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

alistairgrant
In reply to this post by Torsten Bergmann
Hi Torsten,

On Thu, May 18, 2017 at 09:20:14PM +0200, Torsten Bergmann wrote:

> Hi,
>
> I played around with remote controlling Google Chrome from
> Pharo using Chrome DevTools Protocol [1] (based on WebSockets).
>
> The video shows an example using latest Pharo 6 on Mac:
> https://www.youtube.com/watch?v=9F5FrQTEJWY 
>
> Initial Code is on GitHub [2] if someone is interested,
> requires OSOSX and Zinc Websockets to be loaded.
>
> Have fun
> T.
>
> [1] https://chromedevtools.github.io/devtools-protocol
> [2] https://github.com/astares/Pharo-Chrome


This looks really interesting, thanks for making it available.  I'm on
linux, so I guess it will need some porting.

Do you know how the DevTools protocol relates to headless chome, which
will be available in Chrome 59?
See https://developers.google.com/web/updates/2017/04/headless-chrome

In particular, is it possible to dump the DOM with your package?


Thanks,
Alistair

Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

askoh
Administrator
In reply to this post by Torsten Bergmann
Torsten:

Excellent. This is a great start towards the Smalltalk Internet Browser I had envisioned. Hopefully, this integration can be made standard in Pharo and other Smalltalks in many platforms. Perhaps, someone can connect all Smalltalk IDEs to a cloud where the different dialects can really work together in synergy - share and pool code from all sources, minimize duplications, integrate local and external search, etc. Smalltalk has pioneered many things in the past and there is no reason for it to stop. Smalltalk makes it easier to do so and we can live up to the quote by Bob Martin "Smalltalkers will, eventually, win. So says this old C++ programmer".

Thanks,
Aik-Siong Koh
Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

Ben Coman
In reply to this post by Torsten Bergmann


On Fri, May 19, 2017 at 3:20 AM, Torsten Bergmann <[hidden email]> wrote:
Hi,

I played around with remote controlling Google Chrome from
Pharo using Chrome DevTools Protocol [1] (based on WebSockets).

The video shows an example using latest Pharo 6 on Mac:
https://www.youtube.com/watch?v=9F5FrQTEJWY

Initial Code is on GitHub [2] if someone is interested,
requires OSOSX and Zinc Websockets to be loaded.

Have fun
T.

[1] https://chromedevtools.github.io/devtools-protocol
[2] https://github.com/astares/Pharo-Chrome

This is great Torsten.  Such videos have high potential to be marketable outside the Pharo community.
cheers -ben 

Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

Esteban A. Maringolo
In reply to this post by Torsten Bergmann
This is really cool!

Thank you for doing it!

El may. 18, 2017 4:21 PM, "Torsten Bergmann" <[hidden email]> escribió:
Hi,

I played around with remote controlling Google Chrome from
Pharo using Chrome DevTools Protocol [1] (based on WebSockets).

The video shows an example using latest Pharo 6 on Mac:
https://www.youtube.com/watch?v=9F5FrQTEJWY

Initial Code is on GitHub [2] if someone is interested,
requires OSOSX and Zinc Websockets to be loaded.

Have fun
T.

[1] https://chromedevtools.github.io/devtools-protocol
[2] https://github.com/astares/Pharo-Chrome

Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

funone
In reply to this post by Torsten Bergmann
Very cool. Thanks for sharing.

Graham

Torsten Bergmann wrote:

> Hi,
>
> I played around with remote controlling Google Chrome from
> Pharo using Chrome DevTools Protocol [1] (based on WebSockets).
>
> The video shows an example using latest Pharo 6 on Mac:
> https://www.youtube.com/watch?v=9F5FrQTEJWY
>
> Initial Code is on GitHub [2] if someone is interested,
> requires OSOSX and Zinc Websockets to be loaded.
>
> Have fun
> T.
>
> [1] https://chromedevtools.github.io/devtools-protocol
> [2] https://github.com/astares/Pharo-Chrome
>
>


graham.vcf (484 bytes) Download Attachment
Graham McLeod
graham@inspired.org
www.inspired.org
Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

Torsten Bergmann
In reply to this post by alistairgrant
Alistair Grant wrote

> This looks really interesting, thanks for making it available.  I'm on
> linux, so I guess it will need some porting.

I added support for Linux and tried on Ubuntu with Chromium. Works - see screenshot

You need to load my OSLinux package (instead of OSOSX) from catalog. Or start
Chrom manually in debug mode.

In the Pharo settings browser you can set the path to the chrome executable
and the debug port to use.

Will add Windows support as well (using my OSWindows package)

> Do you know how the DevTools protocol relates to headless chome, which
> will be available in Chrome 59?
> See https://developers.google.com/web/updates/2017/04/headless-chrome

Dont know - just try it.

> In particular, is it possible to dump the DOM with your package?

I've seen that Brackets editor as well as Netbeans open Chrome to
display webpages when editing and refresh when typing. Wanted
to find out how it was done.

I have not implemented the full protocol. Only what was needed to show
that it is possible and to do things like grabbing screenshots from websites
using Pharo.

There is a DOM domain that one could wrap - basically it is just
sending JSON around, see
https://chromedevtools.github.io/devtools-protocol

With

 chrome := GoogleChrome open.
 chrome jsProtocolJSON.
 chrome browseProtocolJSON

you can now even retrieve the Protocol as JSON for the specific browser.
With a little bit more work it should be possible to even generate
the wrapper classes/methods from such a protocol spec.

Thanks
Torsten


PharoChromeUbuntu.png (680K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

Torsten Bergmann
In reply to this post by askoh
If you are up to a Smalltalk internet browser then check the old
Scamper from Squeak and H. Hirzels post + screenshot on squeak-dev from this month:

   http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-May/194481.html

If you want a simple morphic based internet browser I guess this could
be ported to Pharo.

There was also "WithStyle" in VisualWorks Smalltalk, an XML based
UI browser built back in the days by an (australian?) company. I guess
it is still included in the commercial VisualWorks distribution.
Dont know about the license http://forum.world.st/VW-7-5-and-WithStyle-td1408557.html

Building a webbrowser in Smalltalk would be cool - but lots of work
(HTML + CSS parsing, JavaScript layer, drawing, ...) that would require time.

Thx
T.


> Gesendet: Freitag, 19. Mai 2017 um 03:30 Uhr
> Von: askoh <[hidden email]>
> An: [hidden email]
> Betreff: Re: [Pharo-dev] Chrome DevTools Protocol and Pharo
>
> Torsten:
>
> Excellent. This is a great start towards the Smalltalk Internet Browser I
> had envisioned. Hopefully, this integration can be made standard in Pharo
> and other Smalltalks in many platforms. Perhaps, someone can connect all
> Smalltalk IDEs to a cloud where the different dialects can really work
> together in synergy - share and pool code from all sources, minimize
> duplications, integrate local and external search, etc. Smalltalk has
> pioneered many things in the past and there is no reason for it to stop.
> Smalltalk makes it easier to do so and we can live up to the quote by Bob
> Martin "Smalltalkers will, eventually, win. So says this old C++
> programmer".
>
> Thanks,
> Aik-Siong Koh
>
>
>
> --
> View this message in context: http://forum.world.st/Chrome-DevTools-Protocol-and-Pharo-tp4947589p4947609.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

Torsten Bergmann
In reply to this post by Ben Coman

Yes - we should just redo what others do and show that if one uses Pharo for it
it is easier, cleaner and usually done with less effort
 

Gesendet: Freitag, 19. Mai 2017 um 03:48 Uhr
Von: "Ben Coman" <[hidden email]>
An: "Pharo Development List" <[hidden email]>
Betreff: Re: [Pharo-dev] Chrome DevTools Protocol and Pharo

 
 
On Fri, May 19, 2017 at 3:20 AM, Torsten Bergmann <[hidden email][mailto:[hidden email]]> wrote:Hi,

I played around with remote controlling Google Chrome from
Pharo using Chrome DevTools Protocol [1] (based on WebSockets).

The video shows an example using latest Pharo 6 on Mac:
https://www.youtube.com/watch?v=9F5FrQTEJWY[https://www.youtube.com/watch?v=9F5FrQTEJWY]

Initial Code is on GitHub [2] if someone is interested,
requires OSOSX and Zinc Websockets to be loaded.

Have fun
T.

[1] https://chromedevtools.github.io/devtools-protocol[https://chromedevtools.github.io/devtools-protocol]
[2] https://github.com/astares/Pharo-Chrome[https://github.com/astares/Pharo-Chrome]
 
This is great Torsten.  Such videos have high potential to be marketable outside the Pharo community.
cheers -ben 

Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

Pharo Smalltalk Developers mailing list
In reply to this post by Torsten Bergmann
Willow Lucas-Smith worked on the WithStyle project.

She is now working at Cincom.


> On 19 May2017, at 8:03 AM, Torsten Bergmann <[hidden email]> wrote:
>
> If you are up to a Smalltalk internet browser then check the old
> Scamper from Squeak and H. Hirzels post + screenshot on squeak-dev from this month:
>
>   http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-May/194481.html
>
> If you want a simple morphic based internet browser I guess this could
> be ported to Pharo.
>
> There was also "WithStyle" in VisualWorks Smalltalk, an XML based
> UI browser built back in the days by an (australian?) company. I guess
> it is still included in the commercial VisualWorks distribution.
> Dont know about the license http://forum.world.st/VW-7-5-and-WithStyle-td1408557.html
>
> Building a webbrowser in Smalltalk would be cool - but lots of work
> (HTML + CSS parsing, JavaScript layer, drawing, ...) that would require time.
>
> Thx
> T.
>
>
>> Gesendet: Freitag, 19. Mai 2017 um 03:30 Uhr
>> Von: askoh <[hidden email]>
>> An: [hidden email]
>> Betreff: Re: [Pharo-dev] Chrome DevTools Protocol and Pharo
>>
>> Torsten:
>>
>> Excellent. This is a great start towards the Smalltalk Internet Browser I
>> had envisioned. Hopefully, this integration can be made standard in Pharo
>> and other Smalltalks in many platforms. Perhaps, someone can connect all
>> Smalltalk IDEs to a cloud where the different dialects can really work
>> together in synergy - share and pool code from all sources, minimize
>> duplications, integrate local and external search, etc. Smalltalk has
>> pioneered many things in the past and there is no reason for it to stop.
>> Smalltalk makes it easier to do so and we can live up to the quote by Bob
>> Martin "Smalltalkers will, eventually, win. So says this old C++
>> programmer".
>>
>> Thanks,
>> Aik-Siong Koh
>>
>>
>>
>> --
>> View this message in context: http://forum.world.st/Chrome-DevTools-Protocol-and-Pharo-tp4947589p4947609.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

alistairgrant
In reply to this post by Torsten Bergmann
On Fri, May 19, 2017 at 01:50:28PM +0200, Torsten Bergmann wrote:
> Alistair Grant wrote
>
> > This looks really interesting, thanks for making it available.  I'm on
> > linux, so I guess it will need some porting.
>
> I added support for Linux and tried on Ubuntu with Chromium. Works - see screenshot

Fantastic, thanks!

I did have to change your script for it to work on my laptop:

1. isInDebugMode is false by default, which meant that chrome wasn't
launched with remote debugging enabled.

2. Retrieving the remotes in GoogleChrome class>>tabPages failed because
the browser hadn't had time to start up.  I'll submit a pull request
which adds a retry with delay.

3. I initially got a white image.  This appears to be because the script
doesn't wait for the navigation to complete before taking the
screenshot.  I just added an ugly delay, but I'm not yet sure what the best
solution here is.


| chrome page |

chrome := GoogleChrome new
                debugOn;
                open;
                yourself.
page := chrome tabPages first.
page navigateTo: 'http://www.pharo.org'.
(Delay forSeconds: 5) wait.
page captureScreenshot scaledToSize: 200@300.


> You need to load my OSLinux package (instead of OSOSX) from catalog. Or start
> Chrom manually in debug mode.
>
> In the Pharo settings browser you can set the path to the chrome executable
> and the debug port to use.

I doubt that the chrome executable is in that many different places.
Would you be open accepting a pull request which adds (what I assume is)
the Ubuntu 16.04 default location?


> Will add Windows support as well (using my OSWindows package)
>
> > Do you know how the DevTools protocol relates to headless chome, which
> > will be available in Chrome 59?
> > See https://developers.google.com/web/updates/2017/04/headless-chrome
>
> Dont know - just try it.
>
> > In particular, is it possible to dump the DOM with your package?
>
> I've seen that Brackets editor as well as Netbeans open Chrome to
> display webpages when editing and refresh when typing. Wanted
> to find out how it was done.
>
> I have not implemented the full protocol. Only what was needed to show
> that it is possible and to do things like grabbing screenshots from websites
> using Pharo.

I've found a page that describes accessing the DOM, so it looks like it
should be possible.  I'll see what I can do...

> There is a DOM domain that one could wrap - basically it is just
> sending JSON around, see
> https://chromedevtools.github.io/devtools-protocol
>
> With
>
>  chrome := GoogleChrome open.
>  chrome jsProtocolJSON.
>  chrome browseProtocolJSON
>
> you can now even retrieve the Protocol as JSON for the specific browser.
> With a little bit more work it should be possible to even generate
> the wrapper classes/methods from such a protocol spec.

Thanks again,
Alistair



Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

Ben Coman
In reply to this post by Torsten Bergmann
Would you be interested in trying it with BSD Licensed Chromium...
which could be packaged with a Pharo distribution.

cheers -ben

P.S. on the idea of an in-Image browser, this looks interesting...


On Fri, May 19, 2017 at 3:20 AM, Torsten Bergmann <[hidden email]> wrote:
Hi,

I played around with remote controlling Google Chrome from
Pharo using Chrome DevTools Protocol [1] (based on WebSockets).

The video shows an example using latest Pharo 6 on Mac:
https://www.youtube.com/watch?v=9F5FrQTEJWY

Initial Code is on GitHub [2] if someone is interested,
requires OSOSX and Zinc Websockets to be loaded.

Have fun
T.

[1] https://chromedevtools.github.io/devtools-protocol
[2] https://github.com/astares/Pharo-Chrome


Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

Torsten Bergmann
In reply to this post by alistairgrant
Hi Alistair,

cant look right now but two things:

  - there are also events in the protocol - if we could hook Pharo into them
    this would solve the problem without abusing delay (because then you will
    get informed when the page loading is finished)

  - you can write "5 seconds wait" in Pharo

Bye
T.


> Gesendet: Freitag, 19. Mai 2017 um 17:51 Uhr
> Von: "Alistair Grant" <[hidden email]>
> An: [hidden email]
> Betreff: Re: [Pharo-dev] Chrome DevTools Protocol and Pharo
>
> On Fri, May 19, 2017 at 01:50:28PM +0200, Torsten Bergmann wrote:
> > Alistair Grant wrote
> >
> > > This looks really interesting, thanks for making it available.  I'm on
> > > linux, so I guess it will need some porting.
> >
> > I added support for Linux and tried on Ubuntu with Chromium. Works - see screenshot
>
> Fantastic, thanks!
>
> I did have to change your script for it to work on my laptop:
>
> 1. isInDebugMode is false by default, which meant that chrome wasn't
> launched with remote debugging enabled.
>
> 2. Retrieving the remotes in GoogleChrome class>>tabPages failed because
> the browser hadn't had time to start up.  I'll submit a pull request
> which adds a retry with delay.
>
> 3. I initially got a white image.  This appears to be because the script
> doesn't wait for the navigation to complete before taking the
> screenshot.  I just added an ugly delay, but I'm not yet sure what the best
> solution here is.
>
>
> | chrome page |
>
> chrome := GoogleChrome new
> debugOn;
> open;
> yourself.
> page := chrome tabPages first.
> page navigateTo: 'http://www.pharo.org'.
> (Delay forSeconds: 5) wait.
> page captureScreenshot scaledToSize: 200@300.
>
>
> > You need to load my OSLinux package (instead of OSOSX) from catalog. Or start
> > Chrom manually in debug mode.
> >
> > In the Pharo settings browser you can set the path to the chrome executable
> > and the debug port to use.
>
> I doubt that the chrome executable is in that many different places.
> Would you be open accepting a pull request which adds (what I assume is)
> the Ubuntu 16.04 default location?
>
>
> > Will add Windows support as well (using my OSWindows package)
> >
> > > Do you know how the DevTools protocol relates to headless chome, which
> > > will be available in Chrome 59?
> > > See https://developers.google.com/web/updates/2017/04/headless-chrome
> >
> > Dont know - just try it.
> >
> > > In particular, is it possible to dump the DOM with your package?
> >
> > I've seen that Brackets editor as well as Netbeans open Chrome to
> > display webpages when editing and refresh when typing. Wanted
> > to find out how it was done.
> >
> > I have not implemented the full protocol. Only what was needed to show
> > that it is possible and to do things like grabbing screenshots from websites
> > using Pharo.
>
> I've found a page that describes accessing the DOM, so it looks like it
> should be possible.  I'll see what I can do...
>
> > There is a DOM domain that one could wrap - basically it is just
> > sending JSON around, see
> > https://chromedevtools.github.io/devtools-protocol
> >
> > With
> >
> >  chrome := GoogleChrome open.
> >  chrome jsProtocolJSON.
> >  chrome browseProtocolJSON
> >
> > you can now even retrieve the Protocol as JSON for the specific browser.
> > With a little bit more work it should be possible to even generate
> > the wrapper classes/methods from such a protocol spec.
>
> Thanks again,
> Alistair
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

alistairgrant
Hi Torsten,

On Fri, May 19, 2017 at 10:50:41PM +0200, Torsten Bergmann wrote:
> Hi Alistair,
>
> cant look right now but two things:
>
>   - there are also events in the protocol - if we could hook Pharo into them
>     this would solve the problem without abusing delay (because then you will
>     get informed when the page loading is finished)

That would be great.  It will be a while before I get a chance to look
at this (I want to finish some proposed changes to the FileSystem
packages first), but I'll try and include it then.


>   - you can write "5 seconds wait" in Pharo

Thanks for the tip (I'm still transitioning from VW 2.5 :-)).


>
> Bye
> T.
>
>
> > Gesendet: Freitag, 19. Mai 2017 um 17:51 Uhr
> > Von: "Alistair Grant" <[hidden email]>
> > An: [hidden email]
> > Betreff: Re: [Pharo-dev] Chrome DevTools Protocol and Pharo
> >
> > On Fri, May 19, 2017 at 01:50:28PM +0200, Torsten Bergmann wrote:
> > > Alistair Grant wrote
> > >
> > > > This looks really interesting, thanks for making it available.  I'm on
> > > > linux, so I guess it will need some porting.
> > >
> > > I added support for Linux and tried on Ubuntu with Chromium. Works - see screenshot
> >
> > Fantastic, thanks!
> >
> > I did have to change your script for it to work on my laptop:
> >
> > 1. isInDebugMode is false by default, which meant that chrome wasn't
> > launched with remote debugging enabled.
> >
> > 2. Retrieving the remotes in GoogleChrome class>>tabPages failed because
> > the browser hadn't had time to start up.  I'll submit a pull request
> > which adds a retry with delay.

I've submitted the PR to ping the browser while it starts up, and add
/opt/google/chrome/chrome as a known location.

Thanks again,
Alistair


> > 3. I initially got a white image.  This appears to be because the script
> > doesn't wait for the navigation to complete before taking the
> > screenshot.  I just added an ugly delay, but I'm not yet sure what the best
> > solution here is.
> >
> >
> > | chrome page |
> >
> > chrome := GoogleChrome new
> > debugOn;
> > open;
> > yourself.
> > page := chrome tabPages first.
> > page navigateTo: 'http://www.pharo.org'.
> > (Delay forSeconds: 5) wait.
> > page captureScreenshot scaledToSize: 200@300.
> >
> >
> > > You need to load my OSLinux package (instead of OSOSX) from catalog. Or start
> > > Chrom manually in debug mode.
> > >
> > > In the Pharo settings browser you can set the path to the chrome executable
> > > and the debug port to use.
> >
> > I doubt that the chrome executable is in that many different places.
> > Would you be open accepting a pull request which adds (what I assume is)
> > the Ubuntu 16.04 default location?
> >
> >
> > > Will add Windows support as well (using my OSWindows package)
> > >
> > > > Do you know how the DevTools protocol relates to headless chome, which
> > > > will be available in Chrome 59?
> > > > See https://developers.google.com/web/updates/2017/04/headless-chrome
> > >
> > > Dont know - just try it.
> > >
> > > > In particular, is it possible to dump the DOM with your package?
> > >
> > > I've seen that Brackets editor as well as Netbeans open Chrome to
> > > display webpages when editing and refresh when typing. Wanted
> > > to find out how it was done.
> > >
> > > I have not implemented the full protocol. Only what was needed to show
> > > that it is possible and to do things like grabbing screenshots from websites
> > > using Pharo.
> >
> > I've found a page that describes accessing the DOM, so it looks like it
> > should be possible.  I'll see what I can do...
> >
> > > There is a DOM domain that one could wrap - basically it is just
> > > sending JSON around, see
> > > https://chromedevtools.github.io/devtools-protocol
> > >
> > > With
> > >
> > >  chrome := GoogleChrome open.
> > >  chrome jsProtocolJSON.
> > >  chrome browseProtocolJSON
> > >
> > > you can now even retrieve the Protocol as JSON for the specific browser.
> > > With a little bit more work it should be possible to even generate
> > > the wrapper classes/methods from such a protocol spec.

Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

alistairgrant
Hi Torsten,

On Fri, May 19, 2017 at 09:20:48PM +0000, Alistair Grant wrote:

>
> On Fri, May 19, 2017 at 10:50:41PM +0200, Torsten Bergmann wrote:
> > Hi Alistair,
> >
> > cant look right now but two things:
> >
> >   - there are also events in the protocol - if we could hook Pharo into them
> >     this would solve the problem without abusing delay (because then you will
> >     get informed when the page loading is finished)
>
> That would be great.  It will be a while before I get a chance to look
> at this (I want to finish some proposed changes to the FileSystem
> packages first), but I'll try and include it then.

I've got basic event listening working.  It requires that all messages
are read asynchronously, so I'll need to change the interface to handle
that.

Knowing when a page has finished loading isn't quite as simple as
looking for an event - a page can consist of multiple frames, and
notifications are delivered for each frame.  The page I'm interested in
has around 25 frames.

If anyone has a good design pattern for writing an asynchronous
WebSocket client please let me know, I don't have anything concrete in
mind.

Thanks,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

alistairgrant
Hi Torsten and All,

Quick Introduction for those not familiar with Pharo-Chrome:

Pharo-Chrome enables Pharo to control and query Chrome / Chromium, in
particular to retrieve the DOM of a page.  This is useful as many modern
pages are just a template which then loads some javascript to
asynchronously build the DOM, meaning that the ZnEasy / Soap combination
doesn't get the bulk of the information on a page.



Pharo-Chrome is now mostly working, i.e. it is possible to open
a connection to Chrome, navigate to a requested URL, wait for it to
load, retrieve the DOM and then navigate the DOM using a subset of the
Soap API, e.g. #findAllStrings:, #findAllTags:, attributeAt:, etc..

GoogleChrome class>>exampleNavigation has been updated to retrieve the
DOM from http://pharo.org.

GoogleChrome class>>get: is analogous to ZnEasy class>>get:, although it
returns a ChromeNode, not an html string.

I wasn't able to get rid of the delay while waiting for the page to
finish loading.   This actually makes sense, since, as mentioned above,
many modern pages build the DOM asynchronously, so there's no clear
indication of when it is complete.  The default delay is currently 2000
milliseconds, which is about twice the maximum I saw needed (983ms), but
this can be changed (ChromeTabPage>>pageLoadDelay:).

I had three use cases for this library: one which works with
ZnEasy+Soap, one that used to work with ZnEasy+Soap, but doesn't due to
a page redesign, and one which I hadn't got working before.  All three
are working now.

Unlike Soap, I've currently modelled the nodes as a single class, and
have only implemented a subset of Soap's methods, but is enough for what
I need.

I've introduced a dependency on the Beacon logging framework.  I find it
useful, but can remove it if you don't want the additional dependency.
(I'm planning to add some GoogleChrome specific logging classes and use
those to better understand what pageLoadDelay should be).

I was focussed on trying to understand the events that Chrome generates,
so documentation is still lacking (read "missing" :-)).

I'll generate a pull request after some more testing, tweaking and
documenting, but if you would like to take a look, the code is available
at:

https://github.com/akgrant43/Pharo-Chrome/tree/development

I haven't yet updated BaselineOfChrome with the Beacon dependency.  I
did merge in your two commits from May 23.

If you, or anyone else, finds this useful, I welcome any feedback.

P.S.  I've just realised that I need to tidy up #sendMessage:,
#sendMessageDictionary and #sendMessageDictionary:wait:.  I'll do that
as part of the genral tidy up.

Cheers,
Alistair


# vim: tw=72
On Sun, May 21, 2017 at 09:37:56PM +0000, Alistair Grant wrote:

> Hi Torsten,
>
> On Fri, May 19, 2017 at 09:20:48PM +0000, Alistair Grant wrote:
> >
> > On Fri, May 19, 2017 at 10:50:41PM +0200, Torsten Bergmann wrote:
> > > Hi Alistair,
> > >
> > > cant look right now but two things:
> > >
> > >   - there are also events in the protocol - if we could hook Pharo into them
> > >     this would solve the problem without abusing delay (because then you will
> > >     get informed when the page loading is finished)
> >
> > That would be great.  It will be a while before I get a chance to look
> > at this (I want to finish some proposed changes to the FileSystem
> > packages first), but I'll try and include it then.
>
> I've got basic event listening working.  It requires that all messages
> are read asynchronously, so I'll need to change the interface to handle
> that.
>
> Knowing when a page has finished loading isn't quite as simple as
> looking for an event - a page can consist of multiple frames, and
> notifications are delivered for each frame.  The page I'm interested in
> has around 25 frames.
>
> If anyone has a good design pattern for writing an asynchronous
> WebSocket client please let me know, I don't have anything concrete in
> mind.
>
> Thanks,
> Alistair
>

Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

askoh
Administrator
Wonderful contribution. Having full control of an internet browser will give Smalltalk more freedom to innovate. 

Now, can we make Pharo be a web server on demand? Then we can give anyone a URL and they can see the app or info we want to present. Pharo can communicate with anyone using a browser either automatically or under developer control. 

All the best,
Aik-Siong Koh

On May 27, 2017, at 3:23 PM, Alistair Grant [via Smalltalk] <[hidden email]> wrote:

Hi Torsten and All,

Quick Introduction for those not familiar with Pharo-Chrome:

Pharo-Chrome enables Pharo to control and query Chrome / Chromium, in
particular to retrieve the DOM of a page.  This is useful as many modern
pages are just a template which then loads some javascript to
asynchronously build the DOM, meaning that the ZnEasy / Soap combination
doesn't get the bulk of the information on a page.



Pharo-Chrome is now mostly working, i.e. it is possible to open
a connection to Chrome, navigate to a requested URL, wait for it to
load, retrieve the DOM and then navigate the DOM using a subset of the
Soap API, e.g. #findAllStrings:, #findAllTags:, attributeAt:, etc..

GoogleChrome class>>exampleNavigation has been updated to retrieve the
DOM from http://pharo.org.

GoogleChrome class>>get: is analogous to ZnEasy class>>get:, although it
returns a ChromeNode, not an html string.

I wasn't able to get rid of the delay while waiting for the page to
finish loading.   This actually makes sense, since, as mentioned above,
many modern pages build the DOM asynchronously, so there's no clear
indication of when it is complete.  The default delay is currently 2000
milliseconds, which is about twice the maximum I saw needed (983ms), but
this can be changed (ChromeTabPage>>pageLoadDelay:).

I had three use cases for this library: one which works with
ZnEasy+Soap, one that used to work with ZnEasy+Soap, but doesn't due to
a page redesign, and one which I hadn't got working before.  All three
are working now.

Unlike Soap, I've currently modelled the nodes as a single class, and
have only implemented a subset of Soap's methods, but is enough for what
I need.

I've introduced a dependency on the Beacon logging framework.  I find it
useful, but can remove it if you don't want the additional dependency.
(I'm planning to add some GoogleChrome specific logging classes and use
those to better understand what pageLoadDelay should be).

I was focussed on trying to understand the events that Chrome generates,
so documentation is still lacking (read "missing" :-)).

I'll generate a pull request after some more testing, tweaking and
documenting, but if you would like to take a look, the code is available
at:

https://github.com/akgrant43/Pharo-Chrome/tree/development

I haven't yet updated BaselineOfChrome with the Beacon dependency.  I
did merge in your two commits from May 23.

If you, or anyone else, finds this useful, I welcome any feedback.

P.S.  I've just realised that I need to tidy up #sendMessage:,
#sendMessageDictionary and #sendMessageDictionary:wait:.  I'll do that
as part of the genral tidy up.

Cheers,
Alistair


# vim: tw=72
On Sun, May 21, 2017 at 09:37:56PM +0000, Alistair Grant wrote:

> Hi Torsten,
>
> On Fri, May 19, 2017 at 09:20:48PM +0000, Alistair Grant wrote:
> >
> > On Fri, May 19, 2017 at 10:50:41PM +0200, Torsten Bergmann wrote:
> > > Hi Alistair,
> > >
> > > cant look right now but two things:
> > >
> > >   - there are also events in the protocol - if we could hook Pharo into them
> > >     this would solve the problem without abusing delay (because then you will
> > >     get informed when the page loading is finished)
> >
> > That would be great.  It will be a while before I get a chance to look
> > at this (I want to finish some proposed changes to the FileSystem
> > packages first), but I'll try and include it then.
>
> I've got basic event listening working.  It requires that all messages
> are read asynchronously, so I'll need to change the interface to handle
> that.
>
> Knowing when a page has finished loading isn't quite as simple as
> looking for an event - a page can consist of multiple frames, and
> notifications are delivered for each frame.  The page I'm interested in
> has around 25 frames.
>
> If anyone has a good design pattern for writing an asynchronous
> WebSocket client please let me know, I don't have anything concrete in
> mind.
>
> Thanks,
> Alistair
>



If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Chrome-DevTools-Protocol-and-Pharo-tp4947589p4948458.html
To unsubscribe from Chrome DevTools Protocol and Pharo, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Chrome DevTools Protocol and Pharo

SergeStinckwich
Thank you guys for your contributions, but I think that this kind of discussions should be done on pharo-users mailing-list, not here.

pharo-dev should be use only if you contribute to core-pharo.

Thank you

Envoyé de mon iPhone

Le 28 mai 2017 à 10:22, askoh <[hidden email]> a écrit :

Wonderful contribution. Having full control of an internet browser will give Smalltalk more freedom to innovate. 

Now, can we make Pharo be a web server on demand? Then we can give anyone a URL and they can see the app or info we want to present. Pharo can communicate with anyone using a browser either automatically or under developer control. 

All the best,
Aik-Siong Koh

On May 27, 2017, at 3:23 PM, Alistair Grant [via Smalltalk] <[hidden email]> wrote:

Hi Torsten and All,

Quick Introduction for those not familiar with Pharo-Chrome:

Pharo-Chrome enables Pharo to control and query Chrome / Chromium, in
particular to retrieve the DOM of a page.  This is useful as many modern
pages are just a template which then loads some javascript to
asynchronously build the DOM, meaning that the ZnEasy / Soap combination
doesn't get the bulk of the information on a page.



Pharo-Chrome is now mostly working, i.e. it is possible to open
a connection to Chrome, navigate to a requested URL, wait for it to
load, retrieve the DOM and then navigate the DOM using a subset of the
Soap API, e.g. #findAllStrings:, #findAllTags:, attributeAt:, etc..

GoogleChrome class>>exampleNavigation has been updated to retrieve the
DOM from http://pharo.org.

GoogleChrome class>>get: is analogous to ZnEasy class>>get:, although it
returns a ChromeNode, not an html string.

I wasn't able to get rid of the delay while waiting for the page to
finish loading.   This actually makes sense, since, as mentioned above,
many modern pages build the DOM asynchronously, so there's no clear
indication of when it is complete.  The default delay is currently 2000
milliseconds, which is about twice the maximum I saw needed (983ms), but
this can be changed (ChromeTabPage>>pageLoadDelay:).

I had three use cases for this library: one which works with
ZnEasy+Soap, one that used to work with ZnEasy+Soap, but doesn't due to
a page redesign, and one which I hadn't got working before.  All three
are working now.

Unlike Soap, I've currently modelled the nodes as a single class, and
have only implemented a subset of Soap's methods, but is enough for what
I need.

I've introduced a dependency on the Beacon logging framework.  I find it
useful, but can remove it if you don't want the additional dependency.
(I'm planning to add some GoogleChrome specific logging classes and use
those to better understand what pageLoadDelay should be).

I was focussed on trying to understand the events that Chrome generates,
so documentation is still lacking (read "missing" :-)).

I'll generate a pull request after some more testing, tweaking and
documenting, but if you would like to take a look, the code is available
at:

https://github.com/akgrant43/Pharo-Chrome/tree/development

I haven't yet updated BaselineOfChrome with the Beacon dependency.  I
did merge in your two commits from May 23.

If you, or anyone else, finds this useful, I welcome any feedback.

P.S.  I've just realised that I need to tidy up #sendMessage:,
#sendMessageDictionary and #sendMessageDictionary:wait:.  I'll do that
as part of the genral tidy up.

Cheers,
Alistair


# vim: tw=72
On Sun, May 21, 2017 at 09:37:56PM +0000, Alistair Grant wrote:

> Hi Torsten,
>
> On Fri, May 19, 2017 at 09:20:48PM +0000, Alistair Grant wrote:
> >
> > On Fri, May 19, 2017 at 10:50:41PM +0200, Torsten Bergmann wrote:
> > > Hi Alistair,
> > >
> > > cant look right now but two things:
> > >
> > >   - there are also events in the protocol - if we could hook Pharo into them
> > >     this would solve the problem without abusing delay (because then you will
> > >     get informed when the page loading is finished)
> >
> > That would be great.  It will be a while before I get a chance to look
> > at this (I want to finish some proposed changes to the FileSystem
> > packages first), but I'll try and include it then.
>
> I've got basic event listening working.  It requires that all messages
> are read asynchronously, so I'll need to change the interface to handle
> that.
>
> Knowing when a page has finished loading isn't quite as simple as
> looking for an event - a page can consist of multiple frames, and
> notifications are delivered for each frame.  The page I'm interested in
> has around 25 frames.
>
> If anyone has a good design pattern for writing an asynchronous
> WebSocket client please let me know, I don't have anything concrete in
> mind.
>
> Thanks,
> Alistair
>


If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Chrome-DevTools-Protocol-and-Pharo-tp4947589p4948458.html
To unsubscribe from Chrome DevTools Protocol and Pharo, click here.
NAML


View this message in context: Re: Chrome DevTools Protocol and Pharo
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.