Using the phantomjs scripts (or forking them)

[Coretool]

I think I know where to start working now: @piranna

1. Make changes to their preconfigure.sh script (add backends, etc) (here)
2. Make changes to their webkit config (they removed things like web audio)
3. Build the whole stuff and hope that we didn't break anything =)

[piranna]

I've updated the script mimicking how PhantonJS works and qtbase compiles without problem, but qtwebkit requires to install some programs (gperf bison ruby flex) and requires to have qtbase compiled with ICU support. I enabled it but require to also compile and add libicu... Don't know if it makes sense to go so long or if we should move directly to content_shell instead of QtWebkit. Maybe we could continue experimenting with QtWebkit to see if we manage to make it work and later see if it compensates to move to content_shell, what do you think? Do you want that I upload my modified script and try to add ICU support yourself, or do you prefer that I add ICU support first?

[Coretool]

Hm... I think content_shell would be extremly interesting to work and prototype with... I think for a first attemp it is to much work if there are better ways of achivinh the same :) I think we should leave it as it easy and look forward to the content-shell !

[Coretool]

However, I would say that we leave GUI related code in this repo no mather which way we take (?).

[piranna]

There were previous attempts with content_shell and seems @formula1 was able to compile and make it work, but only at default resolution of 800x600 and trying to change that it showed nothing... :-/ We could investigate it, I only agreed to experiment with QtWebkit since it seemed it would be easier to have a working prototype before to move to other things. Who knows, maybe ICU is just the only last one needed thing, at least by using qtbase instead of full qt it got to compile a lot faster... :-)

However, I would say that we leave GUI related code in this repo no mather which way we take (?).

I agree on that. Maybe we could do it on different branches before deciding what alternative to follow, isn't it?

[formula1]

@netlovers was the real hero when it came to content shell but I don't think he was able to finish it. My own attempts involved webkit.js, headless-gl and falsifying a bunch of browser objects. Didn't work out as planned though : / I am able to get it running without errors but it renders blank pngs. https://github.com/formula1/node-webkit-canvas

I saw @piranna (I see you everywhere man, you have no idea) at the servo repo which may be of interest to us. They implemented a CEF interface to hook into (https://github.com/servo/servo/tree/master/ports/cef). I'm aware it's probably a bad thing to add more language dependencies (as it stands, c compiler, python and now possibly rust) But they seem to be doing good work over there.

Heres a CEF sample if you didn't find one https://github.com/acristoffers/CEFSimpleSample

[piranna]

@netlovers was the real hero when it came to content shell but I don't
think he was able to finish it.

Sorry, I'm really bad with names...

My own attempts involved webkit.js, headless-gl and falsifying a bunch of
browser objects. Didn't work out as planned though : / I am able to get it
running without errors but it renders blank pngs.
https://github.com/formula1/node-webkit-canvas

At least it was a good idea :-) Probably there was sonething missing...

I saw @piranna (I see you everywhere man, you have no idea) at the servo
repo which may be of interest to us.

I have an idea about it, what I don't have it's a life :-(

They implemented a CEF interface to hook into (
https://github.com/servo/servo/tree/master/ports/cef). I'm aware it's
probably a bad thing to add more language dependencies (as it stands, c
compiler, python and now possibly rust) But they seem to be doing good work
over there.

Yeah, it's written in Rust. Being this a independent project from NodeOS
don't matter too much as far as it does what we need, since probably we'll
distribute precompiled builds.

Heres a CEF sample if you didn't find one
https://github.com/acristoffers/CEFSimpleSample

CEF is somewhat deprecated in benefict of content_shell since it has less
dependencies and lower requeriments. Anyway, it's better
https://github.com/acristoffers/CEF3SimpleSample since it uses CEF3 ;-)

[Coretool]

Yeah... I agree with trying it once again with ICU (fingers crossed ) Both CEF and content shell will require a bunch of work to make them run as we want (as far as I know)

[piranna]

Ok, not sure how or why, but I managed to compile it using ICU :-P There are some problems though:

• it last forever to compile, I've left it all the night compiling in a dual core machine, so we need to publish prebuild images or people will kill themselves after killing us due to anger :-P
• qtwebket tests for ICU only works for dynamic one instead of static one, so I enabled to build both of them. This has the problem is using the dynamic one by default, so we need to find a way to tell qmake to use the static one on the final build or better also on the tests
• qmake is a sh*t, it does too much magic to my taste and there's no way to discover the configuration flags, old ./configure scrips are better by far (and gyp is as bad in this aspect...).
• I was not able to test it because I compiled it without support for XBC and my machine seems don't have enabled framebuffer, so this need to be check later. Could you be able to download and test this yourselves?
• Final build are 55mb without ICU (and the ICU database are 24mb more...), so we definitely needs to publish prebuilds images :-P

Since it's using ICU as a dynamic library I've added a run.sh script. The ldd seems to be fairly small...

[piranna@SquaredHead:~/Proyectos/noGUI]
 (master) > LD_LIBRARY_PATH=build/icu/lib ldd build/nogui/noGui 
    linux-vdso.so.1 =>  (0x00007ffdf1155000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3a77942000)
    libicui18n.so.56 => build/icu/lib/libicui18n.so.56 (0x00007f3a774c4000)
    libicuuc.so.56 => build/icu/lib/libicuuc.so.56 (0x00007f3a7712b000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3a76f27000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3a76d1f000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3a76b00000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3a7677e000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3a76476000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3a7625e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3a75e94000)
    /lib64/ld-linux-x86-64.so.2 (0x000056256ab56000)
    libicudata.so.56 => build/icu/lib/libicudata.so.56 (0x00007f3a744b1000)

Problems is it have been compiled by using Ubuntu glibc and worst than that, glibc is not able to create purely statically linked binaries as musl does, so we'll need to find a way to compile it. I think the best option would be to convert the NodeOS cross-compiler as an independent project.

[Coretool]

WOW ! Good job ! Could you push your scripts ? I think most of these problems should be "solveable". Sure, I'll test it ;)

[piranna]

I've already pushed them. I have tested it and done some minor tune-ups but
still didn't work, seems plugins doesn't work when statically linked so
linuxfb plugin don't get loaded. It seems it needs to be used a macro on
the code to load it Do you want I push these changes?
El 18/2/2016 9:43, "John Green" notifications@github.com escribió:

WOW ! Good job ! Could you push your scripts ? I think most of these
problems should be "solveable". Sure, I'll test it ;)

—
Reply to this email directly or view it on GitHub
#6 (comment).

[Coretool]

There's a 'special' method/function/lib/whatever-qt-calls-that to include static plugins ... I will push an updated version of noGui in the next days :) (Totally forgot to tell you about that ) I think that's what is missing !

[piranna]

Seems I was able to include the linuxfb plugin, or at least now I get an
error about not having permissions to open /dev/fb0! :-D Could you be able
to look hos make it to use linuxfb by default (no -platform argument)
instead of xcb?
El 18/2/2016 14:15, "John Green" notifications@github.com escribió:

There's a 'special' method/function/lib/whatever-qt-calls-that to include
static plugins ... I will push an updated version of noGui in the next days
:) (Totally forgot to tell you about that ) I think that's what is missing !

—
Reply to this email directly or view it on GitHub
#6 (comment).

[piranna]

Yay! :-D I've managed to include the linuxfb plugin inside the static binary. I'm not able to see anything but seems is a network error in my part. Good thing is, the mouse support and icon comes by free, and the reload button clicking the mouse secondary button is a plus... ;-)

Things to do now:

• make ICU static
• use musl to generate purely static binaries
• use full-screen framebuffer and adapt to framebuffer resizes
• add option to exit - it captures all the keyboard inputs and it's not possible to go out
• use linuxfb platform by default

[Coretool]

Yeah! That's cool !

For exiting and co. I thought about keyboard shortcuts (something like ctrl + q or so )
As @lite20 said, it is possible to change the fb size (-> I'll add code to get the screen size )

To use the fb by default... What about a js script (or even wrapper) for that ?

[piranna]

For exiting and co. I thought about keyboard shortcuts (something like
ctrl + q or so )

Ok, although well need to find a good one not used by anyone...
Ctrl+Alt+Sup?

As @lite20 said, it is possible to change the fb size (-> I'll add code
to get the screen size )

Ok.

To use the fb by default... What about a js script (or even wrapper) for
that ?

It's currently being used a bash script, but I want it native.