Silk GUI

[zodern]

I have started making a GUI in javascript named Silk. You can find the github repository here.

4 main goals:

• Fast and Lightweight
• Designed with developers in mind
• Experiment with new ideas for GUI's
• Client (window manager) can be accessed remotely

  What is Completed

I duplicated Meteor.methods since they make it very for the client and server to communicate.

The basics of window management are done. It is possible to open and minimize windows. It applies the correct z-index to windows.

It is possible to remotely access Silk by going to the url shown in the terminal.

Plans

The first version will have a very simple text editor and file explorer.

There is no security to prevent anyone from remotely accessing the computer, which needs to be fixed. We could look at logon.

Right now the window manager uses iframes to show the apps. Some websites don't allow themselves to display in iframes, including google.com, jw.org and github.com. If the expo browser is used in node os, maybe the window manager could create exoframes (I think that is what they are called) for each app.

To try it, past these commands into your terminal.

npm i -g silk-gui cd silk npm start

Screen Shots

Loading Screen

Desktop

Taskbar Hover

Notice that the taskbar background becomes solid on hover.

Current State of File Explorer

If you have a suggestion or idea, feel free to create an issue

[derhuerst]

This is pretty similar to #78.

I wrote:

NodeOS will be great as an efficient and hacking-friendly OS providing the absolute basics. Why does everyone (including @piranna) want to build ontop of web technologies? NodeOS is just supposed to be more than a web-based operating system, it is supposed to become a general-purpose node.js-only OS, right?

I think this is a general problems the node.js world has. While other environments are better at performance, node.js is an environment enabling incredible productivity when hacking all kind of things together. This potential (being cross-platform, high-level and with a vibrant and healthy package ecosystem) is too underrated; node.js isn't just the web anymore.

• Web technologies grew to what they are today, but in my opinion, they are one of the worst things, you can use on OS-level for graphcis! They are slow, badly designed, insecure and way too complicated to use them at this low level. That's why I am against a web-based authentication system.

[zodern]

You have some good points.

I am using web technologies for several reasons:

• It is easy to allow people to remotely connect to node os
• It is what I am most experienced with
• There are plans to add an html rendering engine in node os, and Silk will be able to use that.

Could you give me some specific examples on how they would be insecure?

[derhuerst]

It is easy to allow people to remotely connect to node os

I agree. I'm not sure, but i think Linux developers solved this problem with the display cllient server architecture, allowing a client from anywhere to connect to the display server and graphically control the machine. Unfortunately, this technique is quite unpopular in comparison to vnc-like products. If NodeOS supported a simeple display client server architecture, we could leave out the whole bloated and – this is the most important point – unsuitable web stack. I understand that you guys want a simple way to control the machine graphically, but in my opinion, that is not enough to justify the usage of the web stack.

It is what I am most experienced with

Me too. But this has no influence on what I think is the best for a lightweight, server-like operating system.

There are plans to add an HTML rendering engine in node os, and Silk will be able to use that.

Okay, so I should give my opinion elsewhere then.

Could you give me some specific examples on how they would be insecure?

I wanted to mention security in combination with the bad design of the web stack. To clarify: Since the web stack has been created (as simple linked HTTP files), it is always becoming more powerful. It gets several new features every month (!), influenced by the so-called web community, mainly developers from internet companies like Mozilla or Google. As with any new feature in software (of any kind), there are security issues getting fixed by time. The same happened to the web stack.

The web grew out of nothing else but plain HTML to full-fledged, desktop-like webapps, capable of things websites were never supposed to capable of. There has never been a point where a companies took all those lessons learned and designed a completely new stack, carefully shaped and a solid foundation for webapps.

Because that never happened, we have powerful webapps, which do still have to compromise on specific things. Developers still have to deal with weird things, such as the same origin policy, never-fixed bugs in browsers, the box model, the DOM, etc. Additonally, HTTP being stateless, the slow and bloated combination of JavaScript and the DOM, caching problems and all kinds of fallbacks and plugin/codec issues makes our life harder than necessary.

[derhuerst]

I wrote further thoughts about this at #68.

[Xarcell]

I for one am in favor of a web stack. I hope to see NodeOS work as server, desktop, laptop, tablet, and smartphone. Wouldn't HTML5/CSS/Javascript be the best GUI for this?

[derhuerst]

I hope to see NodeOS work as server, desktop, laptop, tablet, and smartphone.

I don't. :D

I think that there should be a clear separation of concerns, implemented by a strict client server architecture.

Wouldn't HTML5/CSS/Javascript be the best GUI for this?

It depends.

If you don't have much time or resources, then the web stack offers an efficient way to support all devices. But to me, no webapp matches the performance, memory efficiency, beauty and user experience of a native app.

I propose to design a general (not web-like) standard and develop several clients. Maybe a web client is a good thing too, but I wouldn't design my protocol to focus on the web stack.

[davidyxu]

I agree with @derhuerst that a common standard for a GUI clients to interface with NodeOS is an important first step. I wouldn't be surprised if web clients ended up being the norm due to the convenience factor, but NodeOS shouldn't be tied to the web stack specifically. It would be great to see multiple GUIs for NodeOS designed with different purposes in mind, used interchangeably or even in conjunction.

[derhuerst]

@davidyxu

Good to hear that my remarks are understandable.

I would go even further: Create a convenient CLI API for NodeOS and everyone will be happy.

• A good CLI API is – and this has been proved many times – way more productive than a GUI.
• Any GUI client can still translate GUI actions into CLI commands, making both CLI and GUI possible.

[piranna]

I think that there should be a clear separation of concerns, implemented by a strict client server architecture.

Me too, it's the best way to have a minimal core and being easily extensible. This way the client using a web stack or a native one is an implementation detail and can there be several of them for a single server, another discussion is if we'll adopt a web based one for an hypotetical NodeOS GUI, I'm for it but being isolated the server from their clients and all of them as independent projects, any one can use what he wants :-)

[serapath]

maybe var nodeOS = require('nodeOS-cli'); in order to be able to use the exact same interface that is available through the command line, when translating "GUI actions" into commands as suggested by @derhuerst

[formula1]

One of the biggest problems with the GUI when it comes to web technologies is the need to render the HTML/CSS as well as ensure that node modules and/or web javascript libraries are available

https://github.com/rogerwang/node-webkit

This project is extremely relevent

When it comes to implementation of a file explorer or methods available, the method is a bit irrelevent. Web programmers are a dime a dozen, I would know. And the best libraries will likely rise to the top.

---

I do want to point out though, most anything can be done through "child_process"

[piranna]

node-webkit is awesome, the problem is that applications are webpages with logic written in Node.js, not browser javascript. This is not portable, and more specially, this is Node.js-centric, so you lost the "by free" remote execution. AppKit has a better dessign since it creates a HTTP server with an API and makes clear the separation of interface (client-side) and logic (server-side) code, but seems it's abandoned and it's still a single executable.

The best is to have two projects per program, one a server for the logic written in Node.js, and one or more of them in html and browser side javascript (or other technologies) that communicate over a JSON-RPC protocol via HTTP requests or WebSockets, for example with my library rpc-builder, that's designed with a P2P architecture although JSON-RPC 2.0 is client-server, so events and requests can be send in both directions, and if you want to exec that graphic apps "locally", use a web renderer like Chrome Embebed Framework that's the basis of node-webkit, or said other way, it's node-webkit without the node part :-) It's only a question of porting it to EGL or DirectFB so it can run directly on a Linux terminal without needing X11.

Some could argue about the "excesive" usage of web technologies (http, websockets, json-rpc...) of this architecture I propose, but I think it's an intelligent and adeduate way to use them, and probably the easier, more elegant and most portable way of doing the things in this context, and most important all the client-server applications that currently are available for Node.js will run as native ones on NodeOS without needing to change their code at all.

[piranna]

An example of how applications should be done for NodeOS:

https://github.com/benkaiser/node-music-player

A webserver that read the music files stored on the hard disk that stream the audio data to a webpage running in a browser. I want this f_cking awesome app running on NodeOS like h_ll }:-)

[sidorares]

You can still run node-webkit app from remote box by forwarding X11 session to your local server, so your argument is similar to "wayland is worse than X because it does not allow remote execution" (solution: use VNC) But in general I don't think having webkit as requirement for all applications is a good idea

[formula1]

I believe we're on the same page

Node Webkit is doing something superflueous. Attempting to integrate node heavilly in the browser is not really exactly necessary though it would perform better since the messages wouldn't need to be sent and parsed whether it be post/get/websocket messages

That music player is damn sexy

[piranna]

NodeOS is minimalistic with no extra layers that bloat the system, so no X11 here, specially for only running a web renderer. You want node-webkit, then port webkit to EGL, but by having webkit available, who want to use node-webkit? :*)

Sorry, no X11 or Wayland here, and if asked, I would say no VNC too at least as a general solution (if you can be able to render the client in your web browser, why you would want to do it remotely?). El 09/11/2014 10:41, "Andrey Sidorov" notifications@github.com escribió:

You can still run node-webkit app from remote box by forwarding X11 session to your local server, so your argument is similar to "wayland is worse than X because it does not allow remote execution" (solution: use VNC) But in general I don't think having webkit as requirement for all applications is a good idea

— Reply to this email directly or view it on GitHub https://github.com/NodeOS/NodeOS/issues/79#issuecomment-62297419.

[sidorares]

You are describing ChromeOS :)

[piranna]

You are describing ChromeOS :)

Yes, somewhat :-) The main diference is that ChomeOS offer access to low level OS internals using custom Javascript objects that are only available to ChromeOS making ChromeOS apps not portables to other platforms/browsers/OSes, that is somewhat similar to what you could get by using node-webkit. FirefoxOS has a similar aproach, but at least they are proposing their own FirefoxOS-only APIs as W3C standards, that's an improvement over ChromeOS way, but in any case they are focused on browser-based apps, not server-based ones.

What I'm proposing instead is, at least on a first stage, to don't offer any mechanism to access to those low level things to GUI apps, so this access is done by Node.js apps thenselves, and later they use their own mechanism and protocol to interconnect with their GUI written in html running on a web browser or what they want, so that GUI can run locally or on another machine. Later if people demand it we could think about define an homogeneos protocol or transport, but that's a huge task that don't make sense to think about at this moment. I'm open to retake it later, but not before the alpha has been released.

[ghost]

@piranna and how about atom-shell or thrust? I would definitely use a NodeOS-like OS as a desktop OS.

[piranna]

@piranna and how about atom-shell or thrust?

Didn't know of thrust, seems interesting. As they say, both node-webkit and atom-shell embed a Node.js runtime and you program your app in Node.js based Javascript, so they are out of place if you are interested on making your app accesible remotely. Thust has an architecture more similar to what I was saying, but you are still managing the Chrome-based windows from Node.js in a similar way to what you would be doing with Selenium, so it could still be a little bit bloated for NodeOS. It seems a good aproach to how to write apps, but it's still focused on desktops environment, while I believe a NodeOS GUI would be better by using an architecture more similar to ChromeOS or FirefoxOS (it's said, standard browser webapps) but accesing to the Node.js priviledged APIs by using a REST API to a localhost or remote server.

I'll try to write an entry in the wiki since it seems there's a lot of interest on this topic.

I would definitelly use a NodeOS-like OS as a desktop OS.

Well, definitely it would be a cool thing to hack and tinker and as development platform... :-)

[piranna]

I've created a page on the wiki showing my ideas and some of the conclusions talked here about the GUI issue, please comment your points about it:

https://github.com/NodeOS/NodeOS/wiki/GUI

[ghost]

Is there really a difference between the web renderer and the canvas? I mean the web renderer should be able to render a canvas element, so it's basically two birds with one stone. The only thing I can think of when the native canvas would be better solution where speed is essential and memory usage should be minimal (you don't have to spin up a new web renderer to draw something).

[piranna]

Is there really a difference between the web renderer and the canvas? I mean the web renderer should be able to render a canvas element, so it's basically two birds with one stone. The only thing I can think of when the native canvas would be better solution where speed is essential and memory usage should be minimal (you don't have to spin up a new web renderer to draw something).

You have answered yourself :-) Also, EGL will probably needed for CEF too, so its two birds with one stone too :-D

Canvas can be used for simple, full screen applications, but for some more complex environments like a Desktop Environment with taskbar, window manager and so, I think is better to build it by using CEF and html, and in fact there are already several of them build yet.

[piranna]

I've updated and improved the wiki page about GUI programming.

[ghost]

Do you know if DirectFB is up to the task? While I like the idea behind DFB, the only thing I could find about EGL is that they will support it in the future: http://directfb.org/wiki/index.php/DirectFB_2.0:_Enabling_Khronos_APIs That wiki article is 6 years old... But I'm not sure yet how this all could work together, so it's possible that I missed something important here.

[piranna]

DirectFB is an example, I'm not willingly to use it for canvas object on terminal. Both Cairo (used by node-canvas) and OpenVG (used by node-openvg-canvas) has support for EGL, there are less layer involved and we can get better performance.

2014-11-10 14:20 GMT+01:00 Csaba Szabo notifications@github.com:

Do you know if DirectFB is up to the task? While I like the idea behind DFB, the only thing I could find about EGL is that they will support it in the future: http://directfb.org/wiki/index.php/DirectFB_2.0:_Enabling_Khronos_APIs That wiki article is 6 years old... But I'm not sure yet how this all could work together, so it's possible that I missed something important here.

— Reply to this email directly or view it on GitHub https://github.com/NodeOS/NodeOS/issues/79#issuecomment-62382885.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux

[ghost]

It sounds like node should handle all the inputs too. Is that right? So something like this: https://gist.github.com/rhiokim/2034229 I'm asking this, because if I'll have some time, then in the coming weeks I'd like to hack together a proof-of-concept stuff. But I'm not sure about all that is necessary for this, and how much actual work would it take. I know that none of you want to rush this, so this is just for me to play around in my free time.

[piranna]

It sounds like node should handle all the inputs too. Is that right?

On the terminal and by using a canvas object yes, Node.js will handle all the inputs.

So something like this: https://gist.github.com/rhiokim/2034229

Ey, I was already investigating on mouse support! :-P You are welcome to work on it :-)

I'm asking this, because if I'll have some time, then in the coming weeks I'd like to hack together a proof-of-concept stuff. But I'm not sure about all that is necessary for this, and how much actual work would it take. I know that none of you want to rush this, so this is just for me to play around in my free time.

Well, at this moment we are all working on this on our spare time... :-)

[ghost]

Now that you mention the mouse support, I remember reading about it. But it was a long time ago. :)

Anyway, I already hate CEF, and any Chromium related project that requires GTK to build it and run it. Not even the --off-screen-rendering-enabled seems to work, which is weird.

[piranna]

Now that you mention the mouse support, I remember reading about it. But it was a long time ago. :)

Maybe about september :-)

Anyway, I already hate CEF, and any Chromium related project that requires GTK to build it and run it. Not even the --off-screen-rendering-enabled seems to work, which is weird.

Why? GTK is not mandatory anymore, with ChromeOS they changed Chrome to be fully based on Skia and don't depend on native graphic libraries or widgets, that's why now it has the configuration as web pages... And by using EGL we don't need X11...

[ghost]

Yeah, I thought so too, but when I downloaded the Branch 2171 version of CEF (which sould be Chromium v39 - and I don't think the dev channel would've made any difference), and run make on it, it asked for a bunch of missing gtk+ dependencies. And when I try to run the cefclient it gives the Gtk: cannot open display: error message. So at this point I'm not even sure if I run it the correct way.

[piranna]

It must be the default config for Linux, type "./configure --help" to see what are the available flags, there should be something to disable GTK+ and enable EGL instead. El 10/11/2014 21:57, "Csaba Szabo" notifications@github.com escribió:

Yeah, I thought so too, but when I downloaded the Branch 2171 version of CEF (which sould be Chromium v39 - and I don't think the dev channel would've made any difference), and run make on it, it asked for a bunch of missing gtk+ dependencies. And when I try to run the cefclient it gives the Gtk: cannot open display: error message. So at this point I'm not even sure if I run it the correct way.

— Reply to this email directly or view it on GitHub https://github.com/NodeOS/NodeOS/issues/79#issuecomment-62453664.

[ghost]

There is no configure just a Makefile, and a bunch of .gypi and .target.mk files. And as I can see the Linux version uses GTK:

    'cefclient_sources_linux': [
      'cefclient/cefclient_gtk.cpp',
      ...
    ],

And there is a cefsimple app that is uses X, so maybe it is possible to write our own version of these. And I downloaded the sample apps for Windows, so at least I now know what should it look like. But I'll do more digging some other time.

[piranna]

I'm downloading the CEF code to take a look, on the tutorial page of their wiki seems you cab write your own loader function, with examples for Windows, Linux and Mac. Maybe GTK+ is only needed for the app window? They could have used SDL instead... :-/ El 10/11/2014 22:46, "Csaba Szabo" notifications@github.com escribió:

There is no configure just a Makefile, a bunch of .gypi and .target.mk. And as I can see the Linux version uses GTK:

'cefclient_sources_linux': [
  'cefclient/cefclient_gtk.cpp',
  ...
],

And there is a cefsimple app that is uses X, so maybe it is possible to write our own version of these. And I downloaded the sample apps for Windows, so at least I now know what should it look like. But I'll do more digging some other time.

— Reply to this email directly or view it on GitHub https://github.com/NodeOS/NodeOS/issues/79#issuecomment-62461145.

[ghost]

I think a simple "Hello world" app that could print it's results to whatever I want it to would've been a better demo. However the GUI is not the most important thing to work on right now, so don't spend too much time on it. :)

[piranna]

Yeah, the build docs are a little bit cryptic and difficult to follow, so better left it to later. For the record, seems there are intention for this thing also at the Chromium core...

http://www.chromium.org/developers/design-documents/ozone

2014-11-10 22:58 GMT+01:00 Csaba Szabo notifications@github.com:

I think a simple "Hello world" app that could print it's results to whatever I want it to would've been a better demo. However the GUI is not the most important thing to work on right now, so don't spend too much time on it. :)

— Reply to this email directly or view it on GitHub https://github.com/NodeOS/NodeOS/issues/79#issuecomment-62463157.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux

[piranna]

Ok, definitely it's possible to run CEF over EGL :-)

https://software.intel.com/en-us/blogs/2014/10/23/chromium-ozone-gbm-explained https://codereview.chromium.org/356083002 https://github.com/kuscsik/ozone-egl

2014-11-10 23:23 GMT+01:00 piranna@gmail.com piranna@gmail.com:

Yeah, the build docs are a little bit cryptic and difficult to follow, so better left it to later. For the record, seems there are intention for this thing also at the Chromium core...

http://www.chromium.org/developers/design-documents/ozone

2014-11-10 22:58 GMT+01:00 Csaba Szabo notifications@github.com:

I think a simple "Hello world" app that could print it's results to whatever I want it to would've been a better demo. However the GUI is not the most important thing to work on right now, so don't spend too much time on it. :)

— Reply to this email directly or view it on GitHub https://github.com/NodeOS/NodeOS/issues/79#issuecomment-62463157.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux

[piranna]

@netlovers, I've been thinking about your "hello world" app and though it would be useful if you could investigate about how to enable EGL on NodeOS and build a minimal demo directly using it, since EGL will be needed both for canvas and CEF. There are some bindings of EGL for Node.js (https://github.com/tmpvar/node-egl and https://github.com/tmpvar/node-rpi-egl, the last one more focused on Raspberry Pi but has a little bit more documentation... ;-) ), so probably it would be just a matter of compile the libEGL.so libraries... :-) Seems they are specific for each graphic card to have hardware acceleration (for example, the one for Rasperry Pi is available at https://github.com/raspberrypi/firmware/blob/master/hardfp/opt/vc/lib/libEGL.so), but for a simple demo it would be enought to use a dummy software renderer from libMesa :-)

[ghost]

Thanks for the plus info. I'll try to make something work in the coming days. There is a lot to take in right now. :)

[piranna]

You are welcome ;-)

2014-11-11 10:44 GMT+01:00 Csaba Szabo notifications@github.com:

Thanks for the plus info. I'll try to make something work in the coming days. There is a lot to take in right now. :)

— Reply to this email directly or view it on GitHub https://github.com/NodeOS/NodeOS/issues/79#issuecomment-62523853.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux

[ghost]

Yess! Finally I was able to make EGL work. About gazillion numbers of rebuilds for Mesa, I think I finally understand how things work together. I just hope that the Mesa EGL demos don't use X in some unexpected ways. I used VMware and and Ubuntu server edition to build, install and try everything, because I'm not sure if Qemu supports EGL (based on this). There are things that still don't work, but at least I was able to run a few demos.

What would be the best way to move the necessary libs and stuff to the NodeOS project when everything is fixed? Because Mesa won't really let me build anything useful without a bunch of X header files. Every time I tried to build Mesa without those something else went wrong.

[piranna]

That's awesome @netlovers! :-D Please doc it somewhere so we can have it as reference :-)

QEmu emulates hardware, so I think that paragraph means not that QEmu don't have support for EGL (it doesn't makes sense in the emulated environment since its agnostic) but instead that there's no EGL support for the emulated graphic card, so it will render in software inside the virtual machine, so if you was able to make it run on VmWare it should work on QEmu too. Anyway, it's just a question of trying :-)

To compile Mesa for NodeOS, first of all I would review the compilation and configuration flags, since probably you would be able to remove a lot of garbage (like the requeriment of the X header files), and trying to make it automatic. Currently I'm having the same problems by self-compiling the NodeOS shared libraries. Do you have your test uploaded somewhere so we can be able to review them?

[ghost]

I don't have any test uploaded yet, but I was planning on making a bash script that can do all the hard work. I'll create a gist for that over the weekend (maybe tomorrow).

By the way I think the Gallium drivers need the X header files, but when I left that flag out something else broke. But I guess I'll make a script, and then somebody smarter than me will make it shorter and better. That would be awesome.

[piranna]

Ok, good idea. Just a question: why you talk about the Gallium drivers? Is EGL dependent of the drivers of each graphic card? I though it runned just on top of the kernel... :-(

[ghost]

I'm not a Mesa pro by any means. But the first problem I had when I played around with the demos that without a proper vmwgfx (VMware) driver nothing ever worked. So I basically poked it until it showed some results. Maybe there is no need for Gallium, but at this point I'm not sure about that.

[ghost]

Okay, so here it is: https://gist.github.com/netlovers/0bfc342f5320f35ab601 The last step breaks, I think because glew installs a bunch of stuff, but you can try out the src/egl/opengl/demo1,2 and 3 programs anyway. There is a commented out line for the Mesa build which does not require any X stuff to be installed, but none of the demos build that way, so I'm afraid that somehow it uses X in the background. I used a completely fresh Ubuntu 14.04.1 LTS 64 bit (didn't try 32 bit, yet) to run this script, so hopefully it works everywhere. I hope someone finds this useful, and can remove all the unnecessary stuff, so we can have an amazing GUI. :)

[piranna]

Good job @netlovers ;-) I couldn't be able to test your script because I don't have a virtual machine here (and with exams in one month I probably will not have time :-( ), but I've review your script code, it's really clean (thank you! :-) ). Only points are, I would use --prefix=... config flag so sudo it's not necesary, and also I don't understand why you need to install the X.org driver of VmWare... :-/

I've seen the Mesa autoconf options and seems probably is failiing when you remove that X11 libraries due to DRI-GLX, I would give a try to disable it and do it all in software, probably we are missing DRM in the kernel and GLX is doing auto fallback to software rendering, so we should try to force it always with --disable-driglx-direct. Also, by doing a quick search there's a lot of info of Mesa without X11, so maybe it can help you :-) Another alternative is to use FbDev or DirectFB, but probably it would be a move backward... :-/

Regarding to the distro, I would test it on Ubuntu Core, just to have a more minimal system where to test and clean-up previously to move to NodeOS. It's something curious there's no info on LinuxFromScratch about this topic... :-/

[ghost]

Actually I made some progress since then, although I don't have an updated script, yet. The X dependency is needed for libGL.so (clicking on your links almost every link on those pages are purple/visited, so I did my homework): http://lists.freedesktop.org/archives/mesa-users/2014-February/000770.html But I think we don't really need OpenGL anyway, because WebGL is GLES2, so it should be enough for our purposes. But it would be nice if there would be a demo app with no libGL dependency which I can run, and play around with. And I was able to run demos without the extra vmwgfx driver install.

I had to re-learn a bunch of stuff, like compiling C code by hand, and linking. It was a long time ago that I touched any C code... :D And now I can say, that finally I'm closer to understanding how this all works together.

[formula1]

NetLovers,

your awesome.

[piranna]

Actually I made some progress since then, although I don't have and updated script, yet. The X dependency is needed for libGL.so (clicking on your links almost every link on those pages are purple/visited, so I did my homework): http://lists.freedesktop.org/archives/mesa-users/2014-February/000770.html

Cool, good job! :-)

But I think we don't really need OpenGL anyway, because WebGL is GLES2, so it should be enough for our purposes. But it would be nice if there would be a demo app with no libGL dependency which I can run, and play around with.

Yes, GLES2 is just enough for WebGL. [node-webgl(https://github.com/mikeseven/node-webgl) is based instead on OpenGL (that I find it an error), but I believe it would be adapted easily. We should offer only WebGL to allow compatibility with browser apps in both ways.

And I was able to run demos without the extra vmwgfx driver install.

Oh, cool, that's great :-)

I had to re-learn a bunch of stuff, like compiling C code by hand, and linking. It was a long time ago that I touched any C code... :D And now I can say, that finally I'm closer to understanding how this all works together.

I haven't written C/C++ in a serious, intensive way since 4 years ago, so we are on the same boat... :-P

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux