Roadmap

[Paul Spaulding]

I see a lot of uses for this.  Does this project have a public roadmap?  I'm particularly interested in when a Windows version might be available.

[Roger WANG]

Paul Spaulding <pjs6...@gmail.com> writes:

> I see a lot of uses for this. Does this project have a public
> roadmap?

Thanks for bringing up this topic. There isn't any roadmap yet -- we've
just finished the basic functionality and just about to start making a
roadmap. Any thoughts will be discussed here.

Since the project is developed in open, ideas and brainstorming are
welcome. We can make a roadmap together.

Hopefully the roadmap will be made soon.

> I'm particularly interested in when a Windows version might be
> available.

Right. As a runtime we'd like to support more OSes and
applications. Supporting OSes such as windows and android should be on
the TODO list.
--
Roger WANG Intel Open Source Technology Center

[Roger WANG]

Roger WANG <roger...@intel.com> writes:

> Paul Spaulding <pjs6...@gmail.com> writes:
>
>> I see a lot of uses for this. Does this project have a public
>> roadmap?
>
> Thanks for bringing up this topic. There isn't any roadmap yet -- we've
> just finished the basic functionality and just about to start making a
> roadmap. Any thoughts will be discussed here.
>
> Since the project is developed in open, ideas and brainstorming are
> welcome. We can make a roadmap together.
>
> Hopefully the roadmap will be made soon.

Given there are requirements on porting to OSX and Windows, we are
exploring ways to port it and will start the porting as soon as the ways
are found.

As you may know, the major unique feature of node-webkit is that Node
API can be called directly from WebKit -- that means no IPC is needed
for data passing, which is good for performance. So WebKit and Node are
working in one process and one thread. To archive that, main loops from
Node and WebKit are merged.

Main loop merging seems to be harder on Windows platform. IOCP
processing (from Node) and Windows message processing should be merged
in this way. We have yet found ways to do it, but we are still looking
into it. Any suggestion is welcome. Running Node and WebKit in different
threads is also under consideration, but that would require very tricky
synchronization thus may not be doable.

[Roger WANG]

Roger WANG <roger...@intel.com> writes:

> Main loop merging seems to be harder on Windows platform. IOCP
> processing (from Node) and Windows message processing should be merged
> in this way. We have yet found ways to do it, but we are still looking
> into it. Any suggestion is welcome. Running Node and WebKit in different
> threads is also under consideration, but that would require very tricky
> synchronization thus may not be doable.

Just got an idea today: WebKit2 may make the porting possible or
easier. With WebCore running in background process and communicate with
UI with IPC (named pipe on Windows), it could be merged with Node's main
loop. Node's IOCP based main loop can be used to facilitate the WebKit2
IPC.

This could also be helpful for porting to OSX.

[Chris Sainty]

A couple of things have come up that could be useful.

If some are already there, then sorry for missing them.

 

1. Being able to pass a closedown callback to nwebkit.init(). Have it called when the program is about to exit to perform cleanup.

 

2. When using some third party libraries I have found it is difficult to bypass their usual expectation that data loading will be done with an HTTP request. So it might be nice to be able to intercept requests the browser makes and handle local requests.

For example I might set the data source of a grid control to /data.json, then have a function mapped somewhere in Node that can handle this request by querying the database.

It is possible to fire up a http server from within the app.js and handle it that way, but without the closedown function from 1 it does not close when the browser is closed.

I am in two minds about whether you should build this, or just enable it better and let users pick their own middleware for the mapping etc.

 

Another use I am seeing for this library is being able to create a web and desktop app from the same codebase that sync together. Think offline mode for an email client that would then reconnect when it can.

If the online/offline switch could be made with a simple repointing of the URL, rather than replacing the data layer in the app, then it would be even simpler to make this sort of approach work.

 

[Roger WANG]

Cool ideas. These are the real requirements we need from
developers. We'll see how to implement them.

Chris Sainty <csa...@hotmail.com> writes:

--

[Roger WANG]

Chris Sainty <csa...@hotmail.com> writes:

> 1. Being able to pass a closedown callback to nwebkit.init(). Have it
> called when the program is about to exit to perform cleanup.

Now you can pass a 'onclose' callback function to the options parameter
of init().

The example usage is in tests/callback.js

[Chris Sainty]

Perfect.

Works just how I wanted it to.

 

http://csainty.blogspot.com/2012/01/running-nodejs-server-alongside-your.html

[Andrey Solomatin]

Now you can pass a 'onclose' callback function to the options parameter
of init().

The example usage is in tests/callback.js

Is it possible to use  onclose inside *.nw package?

[Andrey Solomatin]

var GUI = require('nw.gui');

GUI.Window.get().on('close', function(){
   GUI.App.quit();
});

пятница, 14 декабря 2012 г., 2:07:20 UTC+4 пользователь Andrey Solomatin написал: