Ideas | Plans | Roadmap

[Coretool]

I think we have to define a clear plan of what we want to do here.

My idea is to try to copy the way they built the gui on Chrome(ium)OS to NodeOS. To do so, I suggest, thaz we "study" the code they used in chromeOS and port it to NodeOS. What do you think ?!

[Coretool]

@joshgarde Any results yet ?

[joshgarde]

First compile failed because it was compiled with X dependencies. I'm doing a second compile now, but it's taking more than an hour. The final compiled binary is about 1.4GB with about 700MB of libraries and other files.

EDIT: Final binary & support files without X deps is only 1GB.

[joshgarde]

Still the same error I'm afraid -

libEGL warning: DRI3: xcb_connect failed
libEGL warning: DRI2: xcb_connect failed
eglInitalize Default failed with error EGL_NOT_INITALIZED

[joshgarde]

content_shell.txt ^ Full debug log

I've forced EGL to render to drm which makes libEGL warning: DRI2: xcb_connect failed disappear, but that's about it.

Going to attempt a second run on my older (and fresher) Debian box.

[Coretool]

Xcb... Always those Xs :/ Nothing new from the chromium guys either !

[Coretool]

@joshgarde Could you push your Code ? I might have the solution !!

[piranna]

Any update on this guys? Seems a nice work! :-)

[joshgarde]

Chromium's codebase is a mammoth. It takes a while just to compile. Last summer's efforts were halted when I managed to screw up the display server on my laptop and wasn't able to fix it because I was going on a vacation the next day.

I still want to use Chromium OS' display system because (once it's done compiling), it's pretty lightweight. I might pick this back up later.

[piranna]

Just to clarify: Aurora is the graphic system / web rendered (like X11 or noGUI) and ash is the window manager, isn't it? Maybe both should be splitted in two independent projects... Have you tried to make ash to run on a regular web browser to a remote NodeOS machine?

OffTopic: my ex-girlfriend's name was Aurora... that's ironic :-P

[joshgarde]

Aura is the low-level display system for Chromium OS. Chromium OS uses Ash on top of Aura for Chromium UI stuff like window management, desktop environment, etc.

Aurora is the name I chose for my NodeOS gui project although I am considering changing it to noDesktop

[Coretool]

...and chromium itself is used to render the UI afaik

[joshgarde]

Just picked up a VPS and started compiling Chromium (With Aura, Ash, and Ozone-GBM support). It's been running for almost 12 hours now, but I have a feeling that's because I got a 1vCPU, 4GB RAM VPS.

[joshgarde]

Look's like the Chromium team is helping us out here though - https://www.chromium.org/developers/mus-ash

a project to separate the window management and shell functionality of ash from the chrome browser process

[Coretool]

But we will need ash and toolkit_views first since mus+ash depends on them

[piranna]

I start to get a bit lost here... Does Chromium run directly on top of EGL and have a HTML5+JS window manager and/or desktop (Ash)? Or on the other hand, is Ash a regular window manager and/or desktop like metacity/gnome that can only be able render Chromium browser windows, and Aura is like Wayland / X11? If that's the point, then we'll have a problem for portability...

My idea for the GUI is to use a web renderer (Chromium, Gecko, regular web browser on a desktop computer) as graphic system (like X11), and run on it a HTML5+JS window manager and desktop, and the application windows being iframes. I think this path will be fairly easier to achieve (we can start working on it right now, and probably we could port current ones like OS.js or ember-shell) and would have portability warranted.

[joshgarde]

Chromium has it's own renderer (Aura) which it can use to talk directly to video devices though the kernel's DRM api. Ash is the window manager (Which uses chromium to render it's content) that runs on top of Aura.

My main concern with going the iFrame route is that there's no separation between the process that runs the desktop and the process that runs the applications. They're the same process. A bad script executed in an application can crash the entire desktop environment.

As a side note - I just got my i7 box loaded up with Ubuntu and the chromium src tree. 😄 Builds have never felt so fast.

[piranna]

My main concern with going the iFrame route is that there's no separation between the process that runs the desktop and the process that runs the applications. They're the same process. A bad script executed in an application can crash the entire desktop environment.

I don't know if it would crash just the bad iframe or the full desktop... I know that there was work on making each iframe to run optionally in their own process. Probably this is what Gecko did with the <browser> tag (an extension of iframe) on FirefoxOS.

As a side note - I just got my i7 box loaded up with Ubuntu and the chromium src tree. Builds have never felt so fast.

Nice! :-D

[Coretool]

We could borrow the webview implementation from electron which provides a "more than usual" grade of isolation ...

[piranna]

Don't know how much complicate would be to create something new than using things off-the-shelf...