--
You received this message because you are subscribed to the Google Groups "appjs-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to appjs-dev+...@googlegroups.com.
To post to this group, send email to appj...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Hi Ægir,
Yes great point. I think there are lots of developers who can do so much so quickly on the web. Then for whatever reason we want to create a desktop application. That takes forever and the interface is not as good as what we can do on the web. As you mentioned we want easy / natural communication to the server.
I think calling it a "desktop shell" that you wrap around a server side application is a very good way of describing what I want to build.
You have got me thinking how do we build this so it is easy and natural to take a php / Rails / Djano / etc app and deploy to the desktop. Appjs did that for nodejs and Ingwie managed to use it with php. We should make it easy to do with any framework.
Great comment, I think this should be a goal of the project.
I always liked that appjs ran on mac / windows / linux as well. So whatever we do lets make it work on those platforms.
I built a cgi interface for appjs, and using websockets and an api is also available. Any suggestions about how to make a nice pluggable system that can be used with many backends?
Simon
--
Hey Ingwie,
This is great I see you are ready to get hacking already :-) Even really big projects only have 3 or 4 developers hacking the core so if a few of us come together and build what we ourselves need then we will go far.
I think your experience of using php with appjs is very good for us. We should try to remove as many difficulties as possible and make it easy to get your app onto the desktop.
Simon
At the moment the concept / design is real simple - it will obviously get more complex in the future. However there are hundreds of ways to build this thing. I dont want to come with a single way and lock out all other solutions. Instead I want to open it up and we can all have fun and build off each others ideas.
Let me describe the task like this:
1) we have something we know how to do well - php app for you, rails for someone else, nodejs for others. That lets you build applications and in one way or another provide an html interface for the user.
2) We can have our "own" browser, either chromium or cef or firefox or whatever. But we want it presented as a desktop app. Launch it from the dock or start menu.
So to start with we could just boot off the browser with parameters to remove the bookmarks bar etc and point it at the local "server side" app. Add api to allow communication both ways and you already hqve a very useful solution. Compaired to current appjs we loose the native menus and a couple of other things. But I think we can start basic and then try to hack solutions to the limitations and make the end desktop solution better and better.
All of that could be done without any C++ and no build process - and I think it will mean more developers that are perhaps afraid of C++ hacking would then jump in and be prepared to contribute.
Dont misunderstand me though, I have nothing against C++ at all I am just aiming to make the core more accessible to a larger audience. This is an experiment. I am saying ok how far can we get with C++. Then we can see what we can build. Then appjs 2.0 will be a mixture of appjs that we have now and the cool things from this experiment.
Having said that I fully expect to be able to ship apps to internal users (I.e. users in the same company) using this experimental technology so I believe it will be fully featured.
Simon
Sorry correction needed: how far can we get WITHOUT C++.
Typing this on a mobile phone so many mistakes :-)
Great you have understood my concept.
I think there are hundreds of ways of connecting the backend to "desktop shell" and making the "desktop shell" as close to a native desktop application as possible. The shell is just a browser of some form that we run.
Lets experiment and build a load of prototypes, then cherry pick the best ideas and put them in appjs 2.0
I think communication via json is very widely supported likewise html so we have all of the basic ingredients already.
Simon
Ingwie - you have already understood my concept and know how you would implement the php side. I will put together a basic prototype using just a download of nodejs and chrome. Then you can take that and play with it adding in support that you would like to see. Will be amazing to see what you can do with it.
Would be nice to hear what others would like to see, what functionality they need and if they have any suggestions on architecture or implementation.
Simon
Hi Chris,
Would be great to have your strong graphics skills :-)
Ok I think "DeskShell" can be the name of this experiment. It communicates my ideas of what we are building quite well.
Your developer tools sound interesting. Am I guessing correctly to understand a desktop app for changing a config file or similar but that reads / saves the result to a server over ssh?
Do you have suggestions for a 64x64 icon for DeskShell skunkworks project?
Simon
...
--
Cool, take your time and have fun with it, no pressure.
Simon
...
--
switch | comment |
--app | Specifies that the associated value should be launched in "application" mode. |
--app-id | Specifies that the extension-app with the specified id should be launched according to its configuration. |
--app-window-size | Specifies the initial size for application windows launched with --app. --app-window-size=w,h |
--apps-use-native-frame | Experimental native frame support for packaged apps. |
--desktop | |
--kiosk | |
--load-and-launch-app | "Loads an app from the specified directory and launches it" |
--no-startup-window | "Does not automatically open a browser window on startup (used when launching Chrome for the purpose of hosting background apps)." |
--profile-directory | |
--proxy-server | "Uses a specified proxy server, overrides system settings. This switch only affects HTTP and HTTPS requests." |
--remote-debugging-port | Enables remote debug over HTTP on the specified port. |
--unlimited-storage | Overrides per-origin quota settings to unlimited storage for any apps/origins. This should be used only for testing purpose. |
--user-agent | A string used to override the default user agent with a custom one. |
--user-data-dir | Specifies the user data directory, which is where the browser will look for all of its state. |
--window-size | Specify the initial window size: --window-size=w,h |
--window-position | Specify the initial window position: --window-position=x,y |
I believe that yes we would be able:
a) native file picker: press button on webpage, this sends an event to nodejs over websocket, nodejs calls a C++ npm module that pops up the native file picker. Results of the pick sent back over websocket.
b) nodejs can boot off powershell and interact with it creating .net objects that popup file dialog
c) can create a windows exe from visal basic, nodejs starts that with parameters to open the file picker.
So my approach would be to create a library or module that supplies the native functionality then just call that from nodejs. Can have same api but different implementations for each platform.
Simon
I guess my approach is to make the core so simple everyone can hack it.
Look in the mailing list how difficult it currently is to checkout and build appjs (admittably most of the difficulties are on windows). See aoso how many people respond and help with c++ issues.
By just booting off the browser everyone could hack the core, so the project will progress faster. The native functionality can be wrapped and supplied behind api's.
We wont be able to get to 100% native, but the more I have thought it through the more I think we can work around and solve the limitations.
Anyway it is an experiment to see how far we can go.
Simon
Yes you got my meaning. After you start thinking in this way then the concrete things you thought you could not do are actually possible in one way or another.
Simon
Navigates current page to the given URL.
Great thanks Chris! I have accepted your pull request and added the graphics directory :-)
On Sat, Sep 7, 2013 at 10:49 PM, Chris Banford [Webascent] <ch...@dihedrals.com> wrote:
Love the energy!
I'm thinking that in keeping with quick iterative rounds that we should just do something super simple for an initial logo/icon. Also if this ends up being more of a continuation of appjs, maybe we can just do a minor change of Milani's existing logo for the project? (sort of losing the 'js' bit as you're looking to support any back-end).
A quick hack to get the juices flowing:
<ghjchajf.jpg>
Great thanks Chris! I have accepted your pull request and added the graphics directory :-)
On Sat, Sep 7, 2013 at 10:49 PM, Chris Banford [Webascent] <ch...@dihedrals.com> wrote:
Love the energy!
I'm thinking that in keeping with quick iterative rounds that we should just do something super simple for an initial logo/icon. Also if this ends up being more of a continuation of appjs, maybe we can just do a minor change of Milani's existing logo for the project? (sort of losing the 'js' bit as you're looking to support any back-end).
A quick hack to get the juices flowing:
<ghjchajf.jpg>
Great thanks Chris! I have accepted your pull request and added the graphics directory :-)
On Sat, Sep 7, 2013 at 10:49 PM, Chris Banford [Webascent] <ch...@dihedrals.com> wrote:
Love the energy!
I'm thinking that in keeping with quick iterative rounds that we should just do something super simple for an initial logo/icon. Also if this ends up being more of a continuation of appjs, maybe we can just do a minor change of Milani's existing logo for the project? (sort of losing the 'js' bit as you're looking to support any back-end).
A quick hack to get the juices flowing:
<ghjchajf.jpg>
var rDebug = require('chrome-rdebug').rDebug;
var rDebugApi = rDebug.openSocket('ws://localhost:9222/devtools/page/A4CB0085-8ACD-4E3C-BC53-0BA888EFC4D6');
rDebugApi.ws.on('close',function() {
console.log('disconnected');
});
rDebugApi.ws.on('open',function() {
console.log('connected');
rDebugApi.getDoc().then(function(doc) {
rDebugApi.getOuterHTML(doc.root.nodeId)
.then(function(res) {
console.log("page html:",res.outerHTML);
rDebugApi.navigate2("http://appjs.com").then(function() {
setTimeout(function(){
rDebugApi.navigate2("about:blank")
},5000);
}).fail(function(err) {
console.log("error:"+err.error.code+" "+err.error.message);
});
}).fail(function(err) {
console.log("error:"+err.error.code+" "+err.error.message);
});
});
});
--
The name is for a nodejs module and they dont like you including node or nodejs in the name (part of their guidelines).
If you look at my implementation it is quite regular and I have coded the names and parameters directly from the docs so you should be able to translate to php. This api is not limited to appjs but would work with any chrome browser!
The api is a bit long-winded using long names, parameters etc. I suggest we add an api on top with as you suggest show / hide methods and everything for appjs combined with simpler remote d3bug calls. That way user does not need to know how it is implemented but just what they want done and the remote debug api could still be used outside of appjs.
Simon
Yes, are there any changes you would like to help the php port? It looks currently that we will use cef so that means nodejs will still be needed - so php could plug into those api rather than having to duplicate them.
The cgi standard is very well established, maybe I should just upgrade that implementation for you. I noticed you talking about environment variables, they should be available through cgi.
Let me know, maybe start a new thread as this one is getting long now :-)
Simon
Yes that is a good idea. If you write it all in php you can boot off chrome with an app then use remote debugging protocol to control it. You could make php listen to a given port then it could serve css / images / js and so on over http just like appjs does.
Very good to have multiple implementations as it gives more perspective to the design.
Simon
Hey.Well as it turns out, we can do a pseudo scope-bridge with the remote debugging protocol. So, that looks like its the direction it's gonna go.However, there is another thing I am questioning myself currently. As you know, there is a thread/issue open about building appjs - and that gets me thinking about ia32 and x64 - in other words, compatibility with platforms. So, if you added the WK-RDP, would that actualy solve current problems about building and compatibility?We can use the websockets and alike to open different pages and transfer the scope. But what I am thinking about is the compatibility with other languages. Sure, I can put together a "router" to implement somebodies favorite language (PHP for me). But what would it be, if we could cling any backend, nodejs independent, to appJS? Thats just something I am currently looking into, mainly because of curiosity. Using a little nodejs to set up a base, and managing the rest from other languages, shouldnt be a big problem for the most - after all, nodejs is javascript, which is what we use in the product anyway. :)I'm gonna look forward to your response tot hat ^-^. Man...im so happy appjs is continuing x)Regards, Ingwie
...
No, we are waiting for a binary to appear to being playing with ;-)
Otherwise we can do experiments with an off the shelf chrome.
Simon
--
I guess the question is what API do we want / need that is not covered by the remote debugging api.
You can open new windows with window.open in browser js. You can get browser to connect to your "application" socket, i .e. opened by php which can then implement any api you want.
In a similar way nodejs can open socket to provide an api to access database / files and do things not allowed in the browser sandbox. This api could be mirrored by php and other backends.
We can then have the "webserver/cgi" part, navigate to http://localhost:9098/helloWorld.php and you can then execute php page and return result helloWorld.py couod run python.
Simon
Hi AppJS Developers.This will be a long post, take a break get a coffee and prepare yourself!Background:=========I remember many years ago discovering that netscape navigator could read files directly off the local disk using the file:// protocol. At that time I was building desktop applications in visual basic. These were quite good and deeply integrated into the OS but the interface was nothing compared to dynamic html (as it was called back then in the golden olden days of the internets). Suddenly I had the opportunity to have a beautiful and flexible interface I could throw up in a couple of mins running on the desktop. Using iframes I could even list the contents of the disk and navigate through it with a nice interface. Of course it was a hack and a horrible security flaw so after a couple of years suddenly the hole was plugged and those hacks stopped working.I have tried out many different hacks, tricks and technologies through the years always trying to reach the same goal really:- I find web technologies very natural, powerful and rapid to develop and deploy. When I find myself building a desktop application (for example a file monitor that automatically uploads changes to a remote server), then I always want to have a desktop application with full access to local disk etc, but I want the interface to be html and web technologies.What is needed is a "browser" giving that wonderful html interface and web technologies, but it should have some security features turned off so local disk access and database is possible and it should not auto-update -- if I build an app I want it to run and work forever even if google depreciates those google gears apis I used to build an app 3 years ago.AppJS:=====When I discovered AppJS I found a great solution. NodeJS is very powerful and awesome for async programming and chromium is a very modern and powerful browser and gives a wonderful interface development platform. The magic is that both nodejs and chromium use the same v8 javascript engine, so with appjs you bridge the two v8 contexts and get the wonderful solution we all know and love.Technical Limitation:===============Unfortunately we have reached a technical limitation in appjs development. As wonderful, revolutionary and just plain awesome that bridging the nodejs and chromium v8 contexts was there was an unfortunate and unexpected side effect. Since both contexts are running in the same process, heavy operations in the browser will block operations in nodejs. Likewise heavy nodejs operations will block chromium. This is very unexpected to web developers and therefore causes problems. If for example you use CSS3 animations to spin and move items in the interface around then the animations become juddery and pause as nodejs performs heavy operations. Everyone just thinks hey it should not be like that!The obvious solution is to put nodejs and chromium in their own processes or threads so animations can run at the same time as nodejs is doing whatever the application needs. The async nature of javascript (it does not support threads as native objects but uses callbacks instead) means that altering appjs to run two separate threads but still bridge one v8 context to the other has proved to be extremely difficult. As you have noticed the number of open issues on appjs has risen and the forward development of the platform has slowed while this issue has been tackled. Unfortunately as it stands today it has not been possible to move to a two thread/process solution and get a working internal bridge between the two v8 contexts.I have discussed appjs with the head developer Morteza Milani. Due to the technical limitations of the current appjs technology appjs as it is today won't be getting new updates. He has begun pointing people to use node-webkit as an alternative to appjs and several developers have moved over to that project.A New Direction:============I think that we mostly attract web programmers to the appjs project. It is mostly web developers that need or want to develop a desktop app using web technologies that get involved. There are fewer hardcore C++ programmers among us and that means the burden of development falls very heavily on a few shoulders.My proposal is to get all of those javascript developers hacking on the appjs platform itself. To do that lets dial back the C++ and try to get as far as we can with javascript and web technologies. Where we hit something we cannot get around we can build something in C++ and expose it as an api to call from javascript. If we find an alternative using javascript lets provide that as well so the platform is more hackable to the largest number of people. The one exception to this rule is nodejs native C++ modules, I think we can just use them if available or provide a choice between C++ module and an equivalent javascript module.Maybe you are thinking that this will mean that we will only be able to have a very limited and essentially crippled platform. However the more that I have thought about this approach and the limitations the more I think it is going to be capable of. Since nodejs has native C++ modules that are available to javascript and an amazing number of npm modules available this is not the limited platform you would at first think.Concreate Plan:============This new direction can succeed if developers get excited and have some fun trying to take this idea as far as possible. This is an open source project so we can all benefit from each others solutions and experiments.What I am proposing is that we have an "off-the-shelf" standard chromium binary on the disk. We also have a nodejs binary on the disk. Nodejs starts and boots off chromium and we have then solved the nodejs blocks chromium and chromium blocks nodejs problem we got stuck on. We also magically get all of the latest web technologies in chromium "for free" and if you want some new cutting edge technology get hold of the latest chromium binary that provides that functionality, drop that into the folder and take advantage of the functionality straight away. Likewise want to use nodejs 0.10 then just drop that binary in, no compilation issues, no compatibility issues.With this new design we just got lots of things for free we could not have easily before. However we have also lost something major: we lost the internal bridge between the two v8 contexts and we lost the cross platform native desktop integration.Lets start from the new design of having two binaries and then lets work through and develop solutions to connecting the nodejs backend to the browser frontend, and try to make the end solution as close to a native application as possible.I am going to be using this setup to build a number of desktop applications for my own use. If we all start working in this direction then I am sure we can actually come a long way.Short Discussion:=============I just want to answer some obvious questions people may ask about the new approach.1) Communication:- nodejs opens a websocket, chromium is given the page to load and display on startup and this opens a websocket back to nodejs. Now you have two way communication and can pass json messages between the contexts. Chromium also reads its files from nodejs as normal http communication.2) Packaging:- I have previously developed code that lets you take your "site" i.e. the browser stuff and the nodejs stuff and wrap it all up into a single package file. You can then have a single install of the nodejs and chromium binary that can run the package files.3) Run code from node in chromium:- just take your function as a text string and send it to chromium, it can then eval the code.4) Access DOM from node:- Use the remote debugging protocol. https://www.webkit.org/blog/1875/announcing-remote-debugging-protocol-v1-0/ It is possible to remotely connect to a running webkit and then manipulate the dom, change it, iterate over items and everything that you can do in firebug or webkit inspector. The only problem here is security. Hopefully it would be possible to make chromium only allow remote debugging from nodejs. If you search the web you can see people have created remote interfaces that can debug javascript on the fly and evaluate commands as you type them in. So actually this would give us something like the original appjs bridge. http://jsconsole.com/remote-debugging.html. Protocol is json format so perfect for a web developer to hack with.5) Native functionality: On linux connect into DBUS, there are already npm modules that can be used. Create a javascript shim that provides an API and then uses dbus to communicate with the system. On windows you can open a powershell process and then pipe commands to it and have access to all of the .NET objects in windows. Create a javascript shim / api and then other platforms can implement the same or similar api so desktop app runs cross platform.6) Desktop Drag and Drop: create a native executable that opens a small window with a "drop here" icon, when the drop occurs do a POST to nodejs with the filenames of the files and folders that were dropped.7) Private Port:- Chromium app can have a client certificate, nodejs can refuse to talk to anyone connecting to the socket without the client certificate (problem with this is someone can just copy the client certificate from the chromium folder, anyone have a solution?).8) Cross platform:- lets run on mac / linux / windows as we do today, allow native integration to the desktop and special platform functionality through api's so the desktop applications can be as good as possible.Basically when you think about it we can work around many problems and get a lot of functionality for this platform. If we get a lot of contributions then the platform can develop quickly and I believe be very useful as a rapid desktop application platform.Call for Help:=========We can all sit and hack our own desktop applications but it is even more fun to do it together. It is also a great way to learn and develop as a programmer. If you are a professional developer you will find open source programming is different to commercial programming and can be fun to do as a hobby.If you would like to be able to rapidly build desktop applications using web technologies then this is the project for you. There are literally hundreds of different technologies that we could use to reach that goal. There are chrome packaged apps, phonegap, node modules and future technologies and api's that have not been thought of yet! Think what your future apps would need and then begin coding and hacking some form of solution. Show it off to everyone else and inspire them to hack something even better. Create a little pull request and get your changes into the project and mention you are an open source committer in your next job interview!Today I am not presenting any new code since I want to hear what everyone has to say first and hear what ideas you all have for future appjs direction. That feedback can then affect and steer how we build the first prototype. Having said that it is quite easy and would only take a couple of hours to have a nodejs binary, chromium binary and websockets code talking together to be the first implementation. Then from that we can experiment and add a lot of functionality as developers need it for the projects they are developing. I can contribute a packaging solution and others can improve on it.There are many awesome developers that have contributed and used appjs in the past and you are very welcome to start hacking on appjs itself. We would really like to encourage more contributions from everyone.Maybe you have never contributed to an open source project before or used github or know what a pull request is. No problem everyone has to learn at some time, it is much easier than you would expect!I know there are many companies and consultancies that are using appjs. This is a great opportunity for you. You can contribute code and move the platform so that it meets your needs while benefiting from everyone elses contributions and testing of the code in daily use. If we had 3 or 4 developers with some time on their hands we would get a lot done.It kind of goes without saying but this is open source so no matter how clever you are, or how amazing the idea, demo code wins over theory every time so if you have a great idea then get your keyboard out and put together a very bad first demo of the concept and then take it from there. Code always beats nice theoretical ideas!The only thing that beats code is of course documentation, tutorials, example code and demo apps. This is so important since this is how we all learn about the platform. If you want to make appjs accessible to others then that is amazing and very important.I will finish by saying that there is a lot of room for new people so if you have time to contribute then you are more than welcome to the team. Also since I have not yet presented any code you can get a head start on me and hack something together yourself along these lines over the weekend and then show it off to us all ;-) I have said that demo code beats ideas and theory so go for it and your code could be the first prototype!/Simon
Hi Marek,
Wonderful! So you have found a standards way around the UI locking problem. Very interesting indeed. If webworkers are implemented and working as a module in nodejs then I think we should add them and make them available in deskshell.
Actually the current deskshell design could still run the existing appjs implementation. Since you have solved the UI locking problem we could create a deskshell example using webworkers and then appjs. That might even be preferrable to using chromium for some setups.
As a simpler version of your solution I guess a nodejs script could start off a webworker to run the "appjs router" i.e. built in webserver and websockets in a separate thread. Then the script can open appjs window and be able to pass messages from browser to webworker code. That way you prevent UI lock and have just one webworker for beginners.
I guess a minor limitation is that webworker code cannot access browser DOM -- same limitation we have with deskshell, so changes would end up going via a socket call or even using the chrome remote debug protocol like deskshell.
Well thanks for sharing this solution with us we can definitely include it in deskshell (since it is the appjs v2 project). Then if we have multiple solutions available we can see what gives best solution in different situations. My spontaneous reaction is that this is compatible with our direction and sounds like a good solution. We are already thinking of supporting multiple backends and frontends and having some form of plugin structure so I can see one deskshell example setup being exactly along the lines of what you are suggesting.
Are you willing to create an appjs demo project for us that shows example use of webworkers? If you did that we could take the code and then see how we can change deskshell to be compatible and see where we end up.
Open Source development is so interesting as new ideas and directions come out of the blue all of the time. Congratulations on getting around the UI locking problem!
Simon
--
function fibonacci(n) {
if (n < 2)
return 1;
else
return fibonacci(n-2) + fibonacci(n-1);
}
and then handle the first button request and run:-
fibonacci(40);
and then the second button request does the same with a webworker. Press first button and graphic stops spinning for some time, press second button and graphic continues spinning :-)
I just searched google and found the following css3 demo for example:http://www.alessioatzeni.com/wp-content/tutorials/html-css/CSS3-loading-animation-loop/index.html
/Simon