Silk GUI #79
Comments
|
This is pretty similar to #78.
|
|
You have some good points. I am using web technologies for several reasons:
Could you give me some specific examples on how they would be insecure? |
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.
Me too. But this has no influence on what I think is the best for a lightweight, server-like operating system.
Okay, so I should give my opinion elsewhere then.
I wanted to mention security in combination with the bad design of the web stack. To clarify: 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. |
|
I wrote further thoughts about this at #68. |
|
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? |
I don't. :D I think that there should be a clear separation of concerns, implemented by a strict client server architecture.
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. |
|
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. |
|
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.
|
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 :-) |
|
maybe |
|
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" |
|
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. |
|
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 }:-) |
|
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 |
|
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 |
|
NodeOS is minimalistic with no extra layers that bloat the system, so no Sorry, no X11 or Wayland here, and if asked, I would say no VNC too at
|
|
You are describing ChromeOS :) |
Yes, somewhat :-) The main diference is that ChomeOS offer access to low What I'm proposing instead is, at least on a first stage, to don't offer |
|
@piranna and how about atom-shell or thrust? I would definitely use a NodeOS-like OS as a desktop OS. |
Didn't know of thrust, seems interesting. As they say, both node-webkit and I'll try to write an entry in the wiki since it seems there's a lot of
Well, definitely it would be a cool thing to hack and tinker and as |
|
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: |
|
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. |
You have answered yourself :-) Also, EGL will probably needed for CEF too, Canvas can be used for simple, full screen applications, but for some more |
|
I've updated and improved the wiki page about GUI programming. |
|
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 |
|
DirectFB is an example, I'm not willingly to use it for canvas object on 2014-11-10 14:20 GMT+01:00 Csaba Szabo notifications@github.com:
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton |
|
It sounds like node should handle all the inputs too. Is that right? So something like this: |
On the terminal and by using a canvas object yes, Node.js will handle all the inputs.
Ey, I was already investigating on mouse support! :-P You are welcome to work on it :-)
Well, at this moment we are all working on this on our spare time... :-) |
Ah okay. I was just having issues connecting to oneshoot running on QEMU. Does ifconfig in NodeOS return the correct IP or is that a default of sorts? |
Inside QEmu it will always get the |
Let me get it working, and then we can discuss this. Basically there needs to be a way to pass which port to use to the app (maybe as an argument when spawning) or allow the app to share the port with the desktop, and then allow calling the api across processes. Would your "voidspace" help with that?
Interacting with windows and opening a file is what first comes to my mind as being part of a standard api. Should we also have a standard app.json for apps? I will create the issue next week when I get back from my trip (I won't have internet for the rest of the week). @piranna That is exciting! I got it to work. It would be nice if it would let you try again after getting the password wrong 😄 . I switched to private browsing to get around that. Also, I am confused if oneshoot is a GUI or if it will be used by GUIs because of this line. I got silk remote to work while running in NodeOS, though only some of the apps started within the allotted 5 seconds. |
At this moment
Interacting with windows is more a task of the Windows Manager, on the client side. Do you propose to have here a common API to do common tasks (maximize, minimize, close, move...)? I think OpenDesktop has something similar, maybe we could take a look there. Regarding files access, the simple and obvious thing is use directly HTTP methods.
I think it's better to re-use
I'm not sure if this is how HTTP Auth works, maybe there's a way to revoke the credentials...
It's intended to be used by GUIs to do standard tasks like serve static content and provide WebSocket connections, if a GUI app needs to access to some Node.js APIs because they are not available on current browsers (for example open an UDP connection or configure the wifi or mount a pendrive) then it would use a WebSocket connection to start it's own backend server to do this non-standard tasks. I know, this would lead to have two OSes at the same time with incompatible APIs (NodeOS in Node.js, and NodeOS GUI in HTML + Javascript), but it's the best option for organization and interoperability.
That's strange, the 5 seconds only take effect when there's no more open connections to that user server (both HTTP and WebSocket) and get cancelled and renewed when a new one occurs... I've just reviewed the code and didn't find any problem here... :-/ |
|
I have been thinking regarding the GUI apps, and I think we can make the scheme really simple. We have two kind of apps:
Apps can be "stored" inside npm packages, augmenting the We launching a GUI app, to identify them it's just a matter of check for the existence of the In that sense, Thoughts? Comments? Do you think there's another way? |
|
I've reviewed the Auth Digest and it's not possible to fetch the realm on the server. I thought about sending the port as a part of the path to identify the requests that don't go to the main one (the GUI server, oneshoot), but this has the problem that's not possible to know when a server can be clossed or how to restart it, so only solution seems to be to send a custom header with the path of server.js file so nodeos-reverse-proxy can be able to start it on demand. This has the advantage that alloe to make the system fully homogeneous, too :-) |
Voidspace helps with sharing variables across multiple processes. It also allows RPC calls to be made between them. If that's what your program needs, yes voidspace can help 😄 Voidspace is accessible externally, as long as the port voidspace is listening on, is known by the connecting client, and open for connections. |
This doesn't sound toooo hard 😝 |
Yeah, but there's the problem of needing to add the header on the petitions, and this is not transparent... :-/ Honestly, the only problem here is when an app makes use of AJAX requests or asynchronous load (like by using templates or specially injecting img tags or similar, where you can't be able to add headers), because if not, all the request would go the server could be done on load and the server would die after that, so the problem is about how to restart it later :-/ I think I'll try to do something working to try to find how to make this work by using a "design by doing" approach, I think static content would be served by the main one without problems. |
Ahh I see what you mean. What was the issue again with sending the destination as a URL parameter? |
To be able to route it to the port where the app server is listening. I was thinking about using the port as a prefix in the URL, but this could change. Now I think I could be able to use the server path as the prefix the same way I was going to send it on the header, since this doesn't change. I would need to parse the URL, but maybe it's possible... |
Oh so that is what you're going to do? Okay yeah that sounds like an excellent idea. If you need a hand, tag me as always ^_^ |
After thinking too much, the only solution I have found to be able to map per-application servers to the external world is to include the server name or path inside the URL, separating it with some special charactes. In this way, I think the best is to identify the first path element to see if it's in brackets, and if so, its content say the server that must be used. For example, @lite20 and @zodern, what do you think about this scheme to start backend servers for the GUI apps? |
|
I like that idea. Above I wrote
If silk could be started with ws://12.34.56.78/[silk]/foo/bar that would be great. Go to When accessing icon.png from the steam-ui server after it has been started, would I use For the actual apps, I think it would be better for Silk (or the desktop the user is using) to start them so it can make the api available to the app and have control over the process so it can stop the app when the user is done with it. Though if I use VoidSpace I could use that instead for the api and use your proposed idea to start the apps. |
|
One concern I have is Silk will have one way of running when in NodeOS and another when running on any other operating system. |
That's just the idea :-) nodeos-reverse-proxy will then later request
Good quedtion, since this was the use case that made me bang the head
Take in account that servers need to finish someway, so if they are not |
Why you think so? |
I do not understand oneshoot enough. I am going to spend this weekend working on Silk and let you know then. |
I like this implementation, It's simple. ^_^ I do have a few questions though. Could services be remotely started with this? That could become a security issue as once a malicious script is on the device, a hacker could easily execute it via this interface. Are there plans to add some sort of authentication?
If putting the application in brackets would launch the application, wouldn't this request launch a new instance of the application? Infinitely calling requests and no end would actually be reached? How would we go about implementing it? I don't know enough about websockets in nodejs but in the example you bound to a path. I didn't even know that was do-able 😛 After you implement everything, a bit of experimentation should suffice to get a working system off it. My understanding of oneshoot is also still extremely cloudy. If you could write an example implementation or even a super basic tutorial explaining what's happening behind the scenes that would be incredible 😄 The codefest continues... |
More than services, GUI apps backend server. But yes, that's the idea.
Yes, all requests are authenticated using HTTP Auth agains the user name
No, it isn't :-) Servers are started by nodeos-reverse-proxy, and it has a
Magic, you know ;-) When I found that trick was possible some years ago I
I'm going to rewrite oneshoot as a library. Think of it as a normal server |
That's what I needed! Thanks. My concern is gone. |
Cool dude ;-) |
Sorry I didn't explain what I meant well. I was referring to clicking a file in file explorer and then having another app open the file. Silk has a property in the app.json for what files the app can open and a client api for when it is supposed to open a file. Currently Silk opens a window for the app that will open the file and adds a query string with the file path. There probably is a better way of doing it.
I agree. There is the icon, window url, if it supports multiple windows, if it needs any other ports available remotely, types of files it opens, and the app name that all would need custom fields. I can use a bower.json for the bower dependencies and get the window title from the html.
Silk gives apps 5 seconds to start, and qemu without kvm was too slow. It wasn't because of oneshoot.
I was thinking about this last spring! I was also trying to figure out how to use npm for downloading, updating and removing apps but I am not sure I want apps to be inside |
![http://12.34.56.78/[/Steam/steam-ui]/hl3/icon.png](http://12.34.56.78/%5B/Steam/steam-ui%5D/hl3/icon.png){kind=link}
This is a totally different discussion. I think this is better handled by using protocol handlers and content handlers.
Ok for the window title thing. Why need to use bower? We can get the dependencies from npm too if the browser libraries are included as it's done in the main ones...
Ah, ok. Maybe is there any other way to check that they start that's not using a timeout?
Obviously this is not mandatory, and my brackets scheme allow to have apps in any place, but what problems would we have by having the apps inside |
|
I've just updated |
It all makes sense now. XD |
|
I've found that the latests changes on Cloud9 almost implement exactly what I was thinking for a GUI, but not also that. it's free software, it's published on npm and follow the same scheme of server + URL I was thinking about! Yay! :-D If not as GUI desktop, at least we need to make this work as IDE :-) |
|
Hahaha leaving this thread open for discussion. If it stays inactive, we can close it |
I have started making a GUI in javascript named Silk. You can find the github repository here.
4 main goals:
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-guicd silknpm startScreen 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
The text was updated successfully, but these errors were encountered: