[ANN] starting project go-webkit

[mattn]

Hi, all

https://github.com/mattn/go-webkit/

I started new project 'go-webkit' that is embeding web browser on go-gtk's widget.

Currently, it only works few method for below' example.

https://github.com/mattn/go-webkit/blob/master/example/webview.go

However, I think this will be interesting. We will be able to make a application

 that is hosting web server and browsing on one's own. :)

Enjoy.

- Yasuhiro Matsumoto

[mattn]

below is a screenshot of example program:

https://github.com/mattn/go-webkit/raw/gh-pages/static/images/screenshot.png

[Guilherme Lino]

looks cool!

this is what im looking for, know any way to remove the window border?

[mattn]

On Saturday, February 2, 2013 7:15:29 AM UTC+9, Guilherme Lino wrote:

this is what im looking for, know any way to remove the window border?

I don't make sure but maybe possible. 

[Philipp Schumann]

Only very slightly off-topic -- while your project is really cool, I SO wish there was a Go package that CGO-binds a web rendering engine (Gecko or WebKit, almost doesn't matter), without requiring any other windowing toolkit bindings, allowing purely headless (background / in-memory to-bitmap) HTML+CSS (no JS here of course) rendering.

Then I could integrate that with the OpenGL and GLFW bindings and create all sorts of visuals and magical effects, combining hand-rolled GL rendering with whatever the HTML renderer blits to its in-memory bitmap...

I think there are some solid headless-rendering libs out there already, but not sure if they expose a pure C-API interface that CGO could target, and then *cough* someone out there would still go through the trouble of wiring up such a CGO binding. And then not sure about static vs. dynamic linking. Of course the renderer itself would be whatever is provided by the user's current Chrome or Safari or FF installation and thus probably dynamically linked to the headless-lib which itself dunno would be statically linked during CGO?

[mattn]

I guess, if developing headless rendering engine, we should write code with Qt from scratch, I guess. Most of things that you want is doing by phantomjs. Also phantomjs support websocket server to talk with external problem like RPC. :)

[Philipp Schumann]

> we should write code with Qt from scratch, I guess

Why, if I'm never using Qt for anything else anywhere in the project?

> Most of things that you want is doing by phantomjs.

Looks extremely promising but the final binary seems to end up in an executable, which I'd rather not launch-60x-per-second... Ideally, there'd be a C-API readily exposed by phantomjs that could be hooked into with CGO, but from first glance, doesn't look like it. Oh well.......

Btw. only just now realized this [ANN] thread originated in 2011...  :D

[mattn]

> > we should write code with Qt from scratch, I guess
> Why, if I'm never using Qt for anything else anywhere in the project?

go-webkit is depend on gtkwebkit. So this mean go-webkit depend on X.

> Btw. only just now realized this [ANN] thread originated in 2011... :D

haha.

[Robert Johnstone]

Hello,

You might be interested in WKA.  It is a similar idea, but the goal was to make a cross-platform application toolkit.  It never ran on more than GTK, and the handling of DOM from Go was limited, but it may provide an interesting reference.

https://bitbucket.org/rj/wka-go