NW13 plan and request for feedback

[Roger Wang]

Hello,

I'd like to collect the information on which NW.js APIs and features are you using? 

I'm asking this because in nw13 we are refactoring the existing code to align better with upstream's architecture (Chrome apps/extensions). With the "release early, release often" spirit I'd like to release some alpha versions while we're working on this. In each version we'll port more APIs and features from NW12. In the end all the existing APIs and features will be supported when the final version of NW13 is released. I'd like to have some applications running in the first early versions and collect some feedback.

With better alignment with the Chromium upstream, both the quality and the number of features will be improved. That's in our new year resolution of 2015: https://twitter.com/wwr/status/550642470623903745

Thanks and Best regards,

Roger

[VoidVolker]

Nice!
I check forum and manual and found, that chromium extensions are not work with nwjs. Is there in plans to add more chrome API to run chrome extensions in nwjs?

Thank you for your work, Roger :)

[hushth...@hushmail.com]

The #1 priority, now that NW12 is stable should, in my opinion, be to try to minimize the size required to distribute as much as at all possible. This really is way more important than some people seem to think. It matters little if NW helps me to create a useful little app when that app has to be distributed as a mega ZIP which unzips to 100+ MB on the system. This is the biggest problem with NW as I see it, and something I wish that will be taken seriously.

[Laszlo Z. Antal]

Hi,

> On Mar 30, 2015, at 8:31, hushth...@hushmail.com wrote:
>
> The #1 priority, now that NW12 is stable should, in my opinion, be to try to minimize the size required to distribute as much as at all possible. This really is way more important than some people seem to think. It matters little if NW helps me to create a useful little app when that app has to be distributed as a mega ZIP which unzips to 100+ MB on the system. This is the biggest problem with NW as I see it, and something I wish that will be taken seriously.

This should never be #1. When was the last time you downloaded a software that did something meaningful and it less then 80MB? I can't remember it.
My bundles by the time they sent out are close to 300MB zipped. Never got a single complaint about it.


Laszlo
http://twitter.com/LZAntal


>
> --
> You received this message because you are subscribed to the Google Groups "nw.js" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to nwjs-general...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[hushth...@hushmail.com]

>This should never be #1. When was the last time you downloaded a
>software that did something meaningful and it less then 80MB? I
>can't remember it.
>My bundles by the time they sent out are close to 300MB zipped.
>Never got a single complaint about it.

People in general rarely complain/make their voice heard. They simply don't use it and never let the author know.

As for your question: "frequently".

foobar2000's dir is 9.47 MB, for instance.
Notepad++'s dir is 19 MB.
PuTTY = 484 KB.
Media Player Classic Home Cinema in 64-bit version is 44 MB.

Those are just some random examples.

[semm...@yahoo.de]

@hushth...@hushmail.com 

People in general rarely complain/make their voice heard. They simply don't use it and never let the author know.

Fair point 

As for your question: "frequently".

foobar2000's dir is 9.47 MB, for instance.
Notepad++'s dir is 19 MB.
PuTTY = 484 KB.
Media Player Classic Home Cinema in 64-bit version is 44 MB.

 

Yeah for utilities running in the background thats nice if they are slim, but  its different for business apps like Word etc. where the user really working with - there are just a few of it open at the same time. Comparing the footprint of nwjs to Firefox' or Chrome's I reckon nwjs is fine the size it is.

Computers tend to grow in capacity (storage, main memory) in general - so the size problem will be resolved automatically in time I guess.

Semmel

[Pier Bover]

Hey hushthatbush
 
If filesize is critical for your project you should be using a different technology. Notepad, Putty, etc, are probably written in C, C++, or Python and not in HTML5. There are many frameworks for developing visual desktop applications using those languages (Qt, Kivy, SDL, etc) but it will take you a lot longer to develop your project.

Another option for you could be to develop a Chrome extension.

[phili...@gmail.com]

I would like to see a new API for nw.gui for menubars which can be more easily integrated into non-nw.js-web-apps. I could imagine two ways:

- Either use plain markup with annotations/directives like you did with <input type="file" nwdirectory />. Maybe we can use plain <menu> elements and nw.js is smart enough to build a native menubar from that, thanks to the annotations.

- Or just change the API to be more "native" (in browser terms). Currently I cannot just re-assign the items from a menubar (they are immutable). I also need to append new items on the menubar, instead of push them to the items themselves, because items isn't a real array. Therefor I can't use new array methods like find to find a particular item.

A complete reconstruction for the menu items would be nice, as it seems we have many bugs currently associated with them (https://github.com/nwjs/nw.js/search?q=menu&type=Issues&utf8=%E2%9C%93). S

[jon.w....@gmail.com]

Using the window menubar and the file save/open dialogs.

The window menus under Linux are strange.  The menu items don't always register clicks and don't line up perfectly in columns underneath the menu name.

-Jonathan

[VoidVolker]

I have few small requests:

1. Add for iframe (webview) event 'urlChange' - for update text in custom url input. Right now I use event binding iside iframe for user clicks and interval for url update. It not very comfortable.

2.  "target" attribute handling in "new-win-policy"  (_blank _self _parent _top).

[henrique matias]

+1 for smaller size of the app.

Although i'm not sure how "doable" it would be, so let's take an example this "imaginary app"

 - renders HTML / CSS

 - plays a WAV file

Would it be possible to then remove from the bundle features like "play video" ( and whatnot ), so we could save on some weight?

Making an app in C++ seems like the right way to go if you just want to make a "toolbar app" or a "background app", but wouldn't it be beautiful if we could just "require" the "modules" we need if we need ?

+1 for 1 file window distribution?

~> Am i unaware of a simpler way of distributing it? my windows build is basically loads of files in the same folder, would be pretty amazing to have them all as one clickable file ?

--
You received this message because you are subscribed to the Google Groups "nw.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nwjs-general...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

time isn't passing, it's you passing.

❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ 

❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ 

[Roger Wang]

Unfortunately this is hard to shrink because we're shipping the whole Web engine and IO.js. Even on mobile the Blink web engine cost nearly 60MB. 

In the long run we're going to make an installer for NW.js which is shared by all the NWJS application in the system, and a package tool which generates an installer for your app to download and launch our installer. We would also consider making configurable builds (like make menuconfig for the Linux kernel) once upstream modularize the web engine, but that would be even later.

In NW13 the binary size will be slightly bigger than NW12 because there will be more chrome.* API support due to demand: https://github.com/nwjs/nw.js/issues/518 .

Thanks,

Roger

[Roger Wang]

This is interesting. It reminds me how React Native works. It takes much more efforts than JS API but I'd like to try it after NW13 release.

Roger

[Seth.]

Hello roger

Do you have any more plan to add sqlite as native functional? 

Regards

-seth

--
Sent from Gmail iPhone App

[Roger Wang]

Hello,

We're also working on a repository of prebuilt native modules, which are automatically built in our buildbot for each releases. I'm sure sqlite will be in it.

Thanks,

Roger

To unsubscribe from this group and stop receiving emails from it, send an email to nwjs-general+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Seth.]

Roger, the last thing, does the nwjs has the native printing module as well or any plan for future?

something like this

https://github.com/tojocky/node-printer

as SQlite and printing is getting bottleneck to use with our application.

- Seth

[Roger Wang]

On Tuesday, April 7, 2015 at 6:10:38 PM UTC+8, post2seth wrote:

Roger, the last thing, does the nwjs has the native printing module as well or any plan for future?

something like this

https://github.com/tojocky/node-printer

as SQlite and printing is getting bottleneck to use with our application.

 

Will look to add it too. 

btw, what's wrong with the printing feature that comes with the browser part?

Roger

[Seth.]

Hello Roger

There are various things which we have to manage.

like the page size manipulation, getting default printer, need printer list, don't ask user to choose a printer for printing. cancelling the print job.

so i found the above native printer library could work great, if this will be a part of the nwjs then nwjs will be the first choice for any company which are developing the application with Adobe AIR or such frameworks.

- but still i really appreciate your work, you really did a good job and still doing.

-Seth

--

[phili...@gmail.com]

"like the page size manipulation" → If you mean resizing and moving the windows smoothly with transitions a big "+1" from me. It would be great to smoothly resize windows.

[Seth.]

Page size manipulation mean "we can set the print size in the printer"

[tobias....@shipstation.com]

I'd also like to +1 an API to interact with the print system programmatically (get the printer list, specify print options, etc).  This would ideally go beyond the simple print commands in the browser (e.g. window.print()) which open the print dialog for the user to interact with.  We're using node-webkit to automate print jobs for the user (which may even be in a headless environment, so no user to interact with), so having to click through the print dialog won't work for us.  We worked around this by spawning an external process to handle our printing, but it'd be nice if we could keep it internal to our nwjs process (especially since this external process on Windows needs to include a separate executable to handle printing PDF documents (SumatraPDF in our case).  I'm guessing that since Chrome lets you print a PDF itself, we could just print the PDF directly through the Chromium engine in nwjs?)

Aside - *thank you* for the great work the team has been doing so far.  Awesome stuff!

[henrique matias]

so many things being added/requested !

would definitely be nice to plug in/out stuff, otherwise everybody will ship apps with all features and simple apps will end up migrating to some other platform... which would be a shame, cause using nw.js is delicious.

[Anatoly Pashin]

I'd like to finally see availability of customization for white 'loading' page, white 'page not opened' page and cloudy 'uncaught error' page.

And desktop notifications from chromium.

Пашин Анатолий,
эникейщик.

[Roger]

Well, the original post is about what APIs *are you currently using*. Not the APIs you want to add ...

Roger

[Anatoly Pashin]

Hm. New nw13 will be firstly free of current nw.js apis, just chromium with chrome apps apis? Even io.js will be wiped?

[Seth.]

Yes these are must but you can do some of the changes since 0.8 as we are doing that 

For example if yoU need to change tge cloudy error page just catch the "uncatugh errors on process" and either do the modification in dom or open the error window or just console them its upto you. This method also availble in documentation

--

[Anatoly Pashin]

I know this method and using this already. Can you please give me magic for two white pages I mentioned too?

[Seth.]

For white loading page am not sure, but we are using bg color & background image with visible false window. and as soon we got the dom ready event we make the window visible by this user is not able to see the white loading.

for the page not opening, am not sure how you are using the open page, are you opening a new window or opening the webpage into the iFrame?

P.S: can you change the post so we can discuss there as its the post about the "NW13 plan and request for feedback"

-Seth

[VoidVolker]

No need to add more complicated printer API into NW. There are many other software for printing with excellent printing options. Just export data to PDF(or any other format) and then just open system printing dialog for printing options or use any other console software for automatic printing. Need to fix bugs at first and then extends API. NWJS - must not become "multi-extra-uber-universal-tool-for-all-tasks". It must be simple constructor, allow user to build simple tool without ussles for him options.

 

Roger Wang:

[Seth.]

Dear Michaël Picovsch,

What kind of application you made with NW?

If you look into the elearning community or ERP community or POS community ( which are still using the offline applications with windows & other platforms ) these three community must require two main features,

1. Offline DB Integration like sqlite.

2. Printing capabilities.

I do understand that nw should be simpler and affective and must be light weight but due to random behavior of these two external plugins many developers leaved the platform and we (as NW community member )

are losing users as i am closely bind with these three fields and a country like INDIA (where internet is still a problem in smaller cities and people are use to for offline applications ), Developer must think to provide offline support and printing support in their applications.

if you compare with ADOBE AIR, Which is very close alternative to nw & work in the same work around. so people are choosing AIR instead of NW.

so as per my perspective these two inbuilt functionality in the NW will make the community larger.

Yes i agree the documentation & other things are on priority but we can not ignore that too.

- Seth

On Thu, Apr 9, 2015 at 4:13 PM, Michaël Picovschi <michael....@gmail.com> wrote:

As a user of NW I do agree with the opinion that it must remain SIMPLE.

NW is an app builder with a Node.js backend that allow to make desktop app from JS/Dom. That's it.

It should just use latest stable versions of webKit in order to respect all standards and the basic needs such as the system api.

I personally make a HTML5 with WebGL and I want it to work neat like it does on browsers. And I'm surely not lone in this case.

--
You received this message because you are subscribed to the Google Groups "nw.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nwjs-general...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michaël Picovschi, Morphiks

http://www.morphiks.com

[Seth.]

What about a Victorinox tool set & the tool box you added in right side image? ;)

Am not forcing to add some functionalities for me, am just saying adding some module natively will make the nw.js more famous and adoptable. 

have you even tried to pack an app with sqllite 3 native module? there was a a problem in the past (not sure if that still exists) that you can not rename the final packed file, if you change the name nw.exe to any other name the sqllite stops working. for  make that working roger suggest to compile the nw source code, people are confused with this issue and finding a solution for this is not that much easy even.

[TrevorPT]

First, thanks to Roger and his team for an amazing development platform. 

As for APIs that we're using in our project:

• nw.gui
• path
• fs
• util

Interfacing with the host (mainly the file system but also API like the clipboard) is critical to our project. 
HTTP support will become part of the project in the near future.
We're also using a number of npm modules (a terrific feature) so continued support for those is important.

It's great to see the nw.js team keeping the project updated.  But I hope that issues in current builds don't get lost in continued refactoring as there are a few that really stop this from being a polished desktop application.  Also, testing with each new nw.js major release gets tedious -- except for memory consumption, I found v0.9.2 more stable than 0.10.x and early 0.11.x; 0.12 is a vast improvement but introduced UI updating bugs that 0.9 doesn't have.

Thanks for the opportunity for input, Roger.

[maplel...@gmail.com]

I need to port my chrome extension to nw.js

I need at least

chrome.storage

chrome.cookies

chrome messaging

background.js

[philipp...@gmail.com]

Hi Roger!

Nwjs looks great, we plan to use it as a wrapper for our upcoming Steam title Manyland ( http://manyland.com ).

We have one crucial issue that prevents things from working at the moment -- cookies are missing with websockets:

https://github.com/nwjs/nw.js/issues/2819

To reproduce this:

- go to http://websocketstest.com in a standard Chrome browser.

- Open dev tools, and go to network tab (and refresh page).

- Highlight the ws upgrade request, verify that cookies are being sent with upgrade request (in this case some google analytics/adsense)

- go to http://websocketstest.com in nw.js

- Open dev tools, and go to network tab (and refresh page).

- Highlight the ws upgrade request, verify that no cookies are being sent with upgrade request

Screenshots of above procedure:

- Chrome: http://i.imgur.com/fzuE20W.png

- nw.js:  http://i.imgur.com/V9jg5Iw.png

We'd be happy to put up a bounty for this issue if that help! https://www.bountysource.com

cheers

Scott & Philipp

[Andry Bray]

Hello,

it could be a great feature to have the same USB / Bluetooth API for Windows / MacOS / Linux using the chrome APIs

Chrome Bluetooth
https://developer.chrome.com/apps/bluetooth

Chrome Serial
https://developer.chrome.com/apps/serial

Thank you

[Roger Wang]

WebSocket should be working well. btw, we just fixed a bug regarding cookies with websockets, see https://github.com/nwjs/nw.js/issues/2819

Roger

On Tuesday, April 14, 2015 at 3:52:00 PM UTC+8, michael.picovschi wrote:

It's actually the really same for us. Interfacing with a third party lib like steamworks or any needed is a must have.

Our game demo is available here at morphiks http://www.morphiks.com/synchrom our plan is to release pretty soon and it's working quite well right now. I'll send you a build when it's done so you can have a look of how it's done.

WebSocket is really not working ? It's quite a breaking feature also for most multiplayer games. I guess that WebRTC should be provided too. We also plan to interface with a Kinect, it works with a websocket stream.

--

You received this message because you are subscribed to the Google Groups "nw.js" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nwjs-general+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[John Kim]

can we get a full list of supported chrome apis and the status?

--
You received this message because you are subscribed to a topic in the Google Groups "nw.js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nwjs-general/A7VpwOztU_s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nwjs-general...@googlegroups.com.

[matthew...@gmail.com]

I personally use very few "Chrome" features. Mostly, the APIs I'm using are around window / menu / file management (although file management frustratingly doesn't have a "true" API, since an element must be wastefully inserted in the DOM to access file system commands). 

So, my biggest request is that would be more of the standard simple app distribution and startup features, like NWJS APIs for file extension association / management, installer commands, and an updater engine. Small pieces of these exist as separate projects, but that very fact prevents NWJS development from being "simple" since there is no officially sanctioned path to actually build and update apps for end users. So, as it stands, NWJS is more of an "app platform in theory", since in real-world practice, it doesn't address the last required mile to actually provide apps to users.

It would be nice if there was a "smaller" Blink / Chromium engine that just provided HTML / CSS / JS, and didn't have extra stuff like web audio / video, XML parsing, WebGL, etc. So, basically just app layout features that meets 99% of a basic desktop app's needs, for a smaller distributable. (Despite someone's comment that it should never be a priority, it's still important.) I'm sure that's not trivial, but if you had a build system that could provide custom engines, that would be pretty sweet.

On Sunday, March 29, 2015 at 9:38:50 PM UTC-7, Roger Wang wrote:

[ro...@master-pos.com]

Hi

i think the most important thing is the huge file size , if its a big app its ok , but sometimes you want to build and deploy small apps the file size becomes an big issue.

the solution to this issue is easy , you can do like Dotnet framework , install the framework on global location and the launcher should use the global instance from running the app,  this way NWJS will be a true framework for desktop applications

other stuff need to be handled is the deployment of application , 

today when we want to deploy a version , we need to compile all native modules on each platform (mac ,windows , linux) 

meaning i need to mac , pc - windows , pc-linux for all deployment,

its really annoying problem (I'm sure there is a better way)

(have native modules compiled lib like node-hid , node-printer... etc can be nice)

also i think you should lunch a platform tools section , for generic stuff (load icon and convert it to icns format for mac , and patch the icon to nwjs on windows...)

maybe a compiling service , i will upload my zip folder (with package.json file and other files  , specify node modules i want) and the service will let me download executeable files for each platfrom

or at least an app that will make this work for us.

thanks.  

[Pier Bover]

i think the most important thing is the huge file size , if its a big app its ok , but sometimes you want to build and deploy small apps the file size becomes an big issue.

It's true that the current file size is less than ideal, but bandwidth and disk space are very cheap these days. Why should file size be a priority when the cases where this is critical are a minority and there are limited development resources?

the solution to this issue is easy , you can do like Dotnet framework , install the framework on global location and the launcher should use the global instance from running the app

Outside of the developer world (= most users) nobody even knows what a framework. I really doubt the majority of users will make the effort of downloading some unknown "thing" unless your app is very famous or they really need a certain feature. For example SteelSeries (the manufacturer of gaming mice) uses NWJS in the client to configure their mice. I surely would download some framework to be able to configure my mouse if forced to, but I would probably hate the manufacturer for it. Downloading 100MB to configure my mouse painlessly is really no big deal these days.

I know I'm not preaching to the choir, but a realistic option to reduce filesize considerably (if it is really critical) is to create a Chrome extension. Most users have Chrome already installed, and if not it will be much easier to convince them to install Chrome than NWJS.

--

You received this message because you are subscribed to the Google Groups "nw.js" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nwjs-general...@googlegroups.com.

[hushth...@hushmail.com]

> I know I'm not preaching to the choir, but a realistic option to reduce filesize considerably (if it is really critical) is to create a Chrome extension. Most users have Chrome already installed, and if not it will be much easier to convince them to install Chrome than NWJS.

This is so incredibly stupid beyond words that I simply can't figure out how to respond to it...

[Pier Bover]

> This is so incredibly stupid beyond words that I simply can't figure out how to respond to it...

Thanks for that useful contribution.

On Tue, Apr 14, 2015 at 7:16 PM, <hushth...@hushmail.com> wrote:

> I know I'm not preaching to the choir, but a realistic option to reduce filesize considerably (if it is really critical) is to create a Chrome extension. Most users have Chrome already installed, and if not it will be much easier to convince them to install Chrome than NWJS.

This is so incredibly stupid beyond words that I simply can't figure out how to respond to it...

[ro...@master-pos.com]

I'm not talking about the advanced users , most of my customers have 5 to 10 years old computers and crappy wifi connection (sometimes even hotspot with limited data plan)

they also don't know what framework is , today our installer just checks if .net framework exists and if not its downloading it so the install process takes longer , but if the user already have the framework on the computer its just skip it so the install process is faster

the end user doesn't need to know which framework your using , actually he doesn't even care . 

but if want to deploy 3 apps for my customer i will need to bundle the nwjs 3 times, why ? why wont them all be using the same files , its the same source , same version. 

today we need to figure out which os version they have (32/64 bit) download the right packaged packed with our application (and again most of my users know the diff between 32 to 64 ) then run the installer

so if i have 3 applications i need to do it 3 times , and i can't even find even 1 good reason why its better then global path

.net framework doing ,

java doing it , ( i don't need to install java for every software that using java)

even chrome installer , let you download 3-5 mb file , that check your os and then download rest of files

and I'm sure if you will look around you will find more good examples

"I really doubt the majority of users will make the effort of downloading some unknown "thing" unless your app is very famous"

they doing it any way when they downloading your app , don't they ?

the users downloading java , 90% of them don't even know what it is

I think the main difference between me and you is that you look at it as "the user will need to download a framework"

I look on it as just resource sharing , like you have on your computer JDK , and i guess some editor downloaded it for you.

"(if it is really critical) is to create a Chrome extension. Most users have Chrome already installed, and if not it will be much easier to convince them to install Chrome than NWJS."

really ? thats your answer ? I'm thinking about nwjs as desktop revolution , giving web-based apps power they didn't had before

my customers paying for my app , monthly based , they expecting a little more then a "chrome-app" , which btw i can't control as good as i can control the nwjs (icons , branding , os integration , nodejs packages) 

"It's true that the current file size is less than ideal, but bandwidth and disk space are very cheap these days"

my mac have only 128gig ssd , im out of space once a week , yet im not going to replace my hard-drive (and specially my customers that barely knows how to operate their computer)

[Pier Bover]

I think my point is not coming across.

I'm not saying file size isn't important. It is for the many reason you have pointed out.

What I'm saying is that considering limited development resources and the small portion of use cases, in my opinion, it's simply not as critical as some other tasks. I'd rather see a better API to get  for example USB, Bluetooth or even Serial access.

really ? thats your answer ?

If file size is really critical, and you need that solved now, today, then yes. Extensions are a very capable technology these days. As capable as NWJS apps (if not more). If you need something that can't be done with a Chrome extension, you probably shouldn't be using NWJS for your project either.

my customers paying for my app , monthly based , they expecting a little more then a "chrome-app"

Maybe I'm missing something, but the last time I checked Blink was powering the rendering on NWJS and V8 the JS code. The same technologies that power Chrome apps.

Are you implying that using web technologies to make desktop apps is not a valid choice?

which btw i can't control as good as i can control the nwjs (icons , branding , os integration , nodejs packages) 

That is simply false.

1) You have access to a more complete API with USB, Bluetooth, etc. (afaik NWJS will be integrating part of this API in the 0.13 version)
2) You can have local icons, status bar icons, etc. For example Google's Hangout app is a Chrome app.

3) You can have NodeJS
4) You can even integrate C++ code in your app, something that is not so easily done with NWJS
5) You can distribute your extension directly from your website directly bypassing the Chrome Store

And most importantly for the discussion at hand:

6) You get exactly the distribution model you are proposing for NWJS (client separated from engine) and your application only weights as much as you need it to.

BTW, just in case it's not clear. I'm not saying extensions are better or worse than NWJS. I personally prefer NWJS for my own projects, but if file size was really critical I'd go with an extension in a minute.

[ro...@master-pos.com]

Hi

well its seems like its has been a while since i last the checked the chrome apps option

i went over the example you posted , and even downloaded the hangouts app

its not even close to the way its looks & feel with NWJS

not to mention there is a lot of differences that will change my work flow, and btw  when you logout from your user on chrome , your apps are gone, maybe its hard to explain but NWJS is far more superior to my opinion then chrome app.

regarding the global location :

I don't understand why you hate the idea so much , after all today were doing :

Run:

$ /path/to/nw /path/to/app/package.json  

you just need external file to check if /path/to/nw is registered in the system , and few minor changes

its not chancing the core of nwjs , and there is always an option to use the regular package - without the shared location , you can create .sh file / .bat file to do it in few hours , I'm sure for you writing this kind of file (c/c++) will be much easier.

"What I'm saying is that considering limited development resources and the small portion of use cases, in my opinion, it's simply not as critical as some other tasks. I'd rather see a better API to get  for example USB, Bluetooth or even Serial access."

i guess i missed the part of limited resources , yet i think thats the my idea can be done in a week or 2 , its an easy win , and as result i truly believe NWJS will gain much more popularity (and will be much well known , maybe you will find investor and be able increase development resources.) and we will be able to release a lot of tiny apps ( think about development tools built with NWJS , such as ssh manager , git deploy manager ... etc..)

regarding the usb, bluetooth , serial , i don't really believe its should be at the core of nwjs , its nice to have but you can use npm packages that already done the work for you , maybe clone and make there api's to work better with nwjs (like doing the hard work , and all user need to do is set it as modules : ['usb','bluetooth']  and nwjs will clone the right precompiled packages from nwjs repository) 

[Kamesh Arumugam]

Hello,

First of ALL Thanks  to Roger, NW Developers and Maintainers. I guess i am pretty late in giving this feedback. Hope NW team able to receive this request.

Webview is  really awesome api to use with. NW platform has evolved a lot considering the fact. One of our project was build on top Google Local Apps with webview, due to lack of support, we have to search for diff platform, luckily stumbled upon NOde-webkit ever since then,  we have really enjoyed working with it. Plus the excellent support provided the developers in NW is excellent.

So certain apps are developed to load multiple website. ( Note : Would be able to provide list if needed :) ), we had gone with "iframe" setup which works fine, but everything in SINGLE-THREADED meaning, one website does funny loop in javascript entire apps is frozen or "not responding " state.

In this case "Webview" plays a major role creating separate partition with new process which means all loaded website have separate process and independent.

"Context MENU" is one of the important things which application users rely on. for example basic
"copy" and "paste", if we are able to figure out  a solution for that would be pretty cool.

Unfortunately the "DOM MUTATION" codes which we previous used with iframe setup failed because we cannot directly reference the DOM inside webview from parent nw frame.

Possible solution which would help in controlling app would be.

a. Global context menu support
b. DOM reference ability from parent nw frame in webview.

Cheers.

--

You received this message because you are subscribed to the Google Groups "nw.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nwjs-general...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Thanks,
Kamesh.

[ken...@gmail.com]

Moving towards chrome api is a great news. Thank you for that.

nwjs apis I'm using:
Screen, Clipboard, Tray, File dialogs

and through node/npm packages I'm also using:

fs, tcp, usb, bluetooth

And I'd love to see chrome's bluetooth api in the nwjs so I can easily use it in both nwjs and cordova chrome app.

My app tries/needs to be everywhere so I spend a lot of time on smoothing differences between platforms (like this awesome library). Having more of chrome api would sure be awesome!

Another thing i'd love to see is moving nwjs from package.json to manifest.json and align with the chrome app manifest.

Mike

[Matthew Dean]

It's interesting that there's passionate debate about Chrome capabilities vs. NWJS. As far as I'm concerned, they are vastly different platforms. The fact that they both run on Blink is somewhat irrelevant. Ubuntu and an LG TV and a Linksys router run on Linux. They are not the same. That is: presentation / distribution are key differentiators, as are things like file access. The differences between NWJS's native file access and Chrome's sandboxed limited file access have massive implications in platform choice.

What the Google team is building into Chrome in terms of app support is great, and it would be awesome to sync with many of the APIs just for portability (even if that meant trimming some app features), but Chrome apps will never be able to replace NWJS without a significant philosophy change on the part of Google.

————
Matthew Dean

Web: MatthewDean.me

--
You received this message because you are subscribed to a topic in the Google Groups "nw.js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nwjs-general/A7VpwOztU_s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nwjs-general...@googlegroups.com.

[Murray Hopkins]

Thanks for this opportunity to contribute Roger. Thanks also to you and your team for making nwjs available in the first place!

My interest is in building apps for small to medium enterprises. I use Sencha libraries for both desktop and mobile devices. I have a common code base with a ui layer on top (ExtJs or sencha touch) , and then use nw js for the desktop packaging and cordova for the mobile packaging. It was a real breakthrough to be able to do that thanks to nw js for the desktop side.

So, to answer your question Roger, the things that I mostly use are:
Native file system
HTTPS for remote web server access
Window management
Clipboard
Notifications
Local storage
Play video and audio
And finally building for windows, osx and later linux.

The pain points for me were mostly around the packaging side but I have now got a set of scripts that largely automate that process. For distribution I use Inno for windows and Dropdmg for mac. I'm yet to distribute for linux. It took a while to get auto updating happening across the board but that's now built in too.

For the future, anything that continues the integration with the local desktop os / device is probably going to be of use to me.

At first glance, the suggestions of going down the java / . net approach of having a central module that is installed separately to the app has appeal.

As an aside, I also think that nw js has great potential in education to allow kids to get into software development in a really easy way in an environment they are familiar with.

Thanks again,
Murray

On 30/03/2015 3:38 PM, "Roger Wang" <wen...@gmail.com> wrote:
>
> Hello,
>
> I'd like to collect the information on which NW.js APIs and features are you using? 
>
> I'm asking this because in nw13 we are refactoring the existing code to align better with upstream's architecture (Chrome apps/extensions). With the "release early, release often" spirit I'd like to release some alpha versions while we're working on this. In each version we'll port more APIs and features from NW12. In the end all the existing APIs and features will be supported when the final version of NW13 is released. I'd like to have some applications running in the first early versions and collect some feedback.
>
> With better alignment with the Chromium upstream, both the quality and the number of features will be improved. That's in our new year resolution of 2015: https://twitter.com/wwr/status/550642470623903745
>
> Thanks and Best regards,
>
> Roger
>

> --

> You received this message because you are subscribed to the Google Groups "nw.js" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to nwjs-general...@googlegroups.com.

[pavel...@gmail.com]

1. Update feature: easy way to check and install updates

2. Error handling: I know we can do it now, but would be nice to have it as a library which can: collect system info, make screenshot, collect stacktrace, app version and send to some service as airbrake.io

3. Improve testing: merge https://github.com/nwjs/nw.js/pull/3319 and provide proper manual what can use for average applications (current manual only for opening http://www.google.com/xhtml), add example for different testing frameworks

[jc.01r...@gmail.com]

Shelljs is not working in recent node-webkit version 12.0 or 12.1..............causing node-webkit to crash and then node-webkit closed automatically.........

[fish...@gmail.com]

在 2015年3月31日星期二 UTC+8上午12:53:03，hushth...@hushmail.com写道：

>This should never be #1. When was the last time you downloaded a
>software that did something meaningful and it less then 80MB? I
>can't remember it.
>My bundles by the time they sent out are close to 300MB zipped.
>Never got a single complaint about it.

People in general rarely complain/make their voice heard. They simply don't use it and never let the author know.

As for your question: "frequently".

foobar2000's dir is 9.47 MB, for instance.
Notepad++'s dir is 19 MB.
PuTTY = 484 KB.
Media Player Classic Home Cinema in 64-bit version is 44 MB.

Those are just some random examples.

  People in general ... Can't agree more. Think why you use such a software despite its fatty body, From a technical aspect, we are most often concerning "IDE", many of them tends to be big. And in some case we use it still because the lightspot

is hard to be found in similar products. As to general software , most people do lean to judge the package size before they cancel the download, they have so many choice after all.

[Jared Williams]

I'm using child_process and not sure whether there is a chrome equivalent.

[Ryan J]

Please don't make this required I still like having standalone application

On Tuesday, 7 April 2015 02:48:55 UTC-3, Roger Wang wrote:

Unfortunately this is hard to shrink because we're shipping the whole Web engine and IO.js. Even on mobile the Blink web engine cost nearly 60MB. 

In the long run we're going to make an installer for NW.js which is shared by all the NWJS application in the system, and a package tool which generates an installer for your app to download and launch our installer. We would also consider making configurable builds (like make menuconfig for the Linux kernel) once upstream modularize the web engine, but that would be even later.

In NW13 the binary size will be slightly bigger than NW12 because there will be more chrome.* API support due to demand: https://github.com/nwjs/nw.js/issues/518 .

Thanks,

Roger

[Pier Bover]

> Please don't make this required I still like having standalone application

I second this. I think convenience is more important than saving a few MBs.

[Roger Wang]

Sure. We'll keep the standalone feature supported, even when we support auto-update.

Roger

[mikef...@gmail.com]

I would love to see:

- Built in spell check (not requiring a web connection to some spell checking service).

- More secure way to package & protect source code

[sirvi...@gmail.com]

Hi, I believe it would be useful for developers if we could install and use external dev-tools extensions together with nw's dev-tools, like react developer tools.

[VoidVolker]

Also, I whant to suggest to add into package.json option to control sources unpacking: for small applications and secured files it must not unpack to disk and load files directly from PC memory. For big files and media files - they can be unpacked to disk.

понедельник, 30 марта 2015 г., 7:38:50 UTC+3 пользователь Roger Wang написал:

[gntheprogrammer]

Hi, and sorry if my English isn't very good but it's not my main language.

Since I'm new here, first of all I want to thank all the NW.js team for this great development platform.

As other people here in this thread, I think that shipping the binaries with every application isn't very handy, and I'm interested in a solution for a system-wide NW.js installation.

I'm writing this post to ask if there are currently plans to implement this "global installer" in a short time. If there aren't, I'm interested in implementing by myself an unofficial tool to accomplish this task (and I would release it with an open source license, probably BSD). To make it as user-friendly as possible, I think a good way of implementing it would be the following:

• The user downloads the app (and maybe installs it through NSIS installer on Windows / package managers on Linux, etc) as an archive that contains the "real" app files (html, css, javascript and node modules, etc) plus a native, platform-specific wrapper/launcher (e.g. a .exe on windows).
• To start the application, the user runs the wrapper.
• When started, the wrapper searches for a NW.js installation in a known global location (e.g. C:\nwjs on Win or /usr/bin/nwjs on Linux).
• If it doesn't find the directory, it downloads a (native) tool to manage the NW installation. This will help to keep different versions of NW since some outdated apps might need outdated NW versions.
• If the tool is already installed, the wrapper will run it passing the path to the application's package.json as a command line argument.
• This version manager tool reads the package.json and searches for additional fields added by the developer to know what NW versions are compatible with the application (something like "nwMinVer", "nwMaxVer"); if none of these fields are found, it assumes the applications can run on the latest nw version. Then, the tool searches in its own directory (e.g. C:\nwjs) for a subdirectory matching the correct NW version.
• If no suitable version is found, or if there isn't any NW version installed at all (e.g. it's the frst time a NW app is launched on the system) it downloads the latest compatible version from dl.nwjs.org. During the download the tool shows a window with a progress bar and a message saying something like "This application requires the NW.js runtime to work; it's currently being downloaded. Please wait a while and the application will start."
• The tool will then run the nw.exe from the directory matching the correct version, passing the path to the application's directory (which contains package.json and all the app's files).

More advanced features may allow advanced users to manually add/remove NW versions and choose with which version each app should be launched.

I'm interested in trying to implement this, however I won't do it if an official installer is already being written or if the NW.js team dislikes the method I described. Also, I won't support OSX since I own no Apple hardware (and I'm not interested in buying any), however since I would release everything as open source, I think that if someone is interested in porting to that platform, that won't be difficult to be done.

Regards,

Gianluca

Il giorno martedì 7 aprile 2015 07:48:55 UTC+2, Roger Wang ha scritto:

Unfortunately this is hard to shrink because we're shipping the whole Web engine and IO.js. Even on mobile the Blink web engine cost nearly 60MB. 

In the long run we're going to make an installer for NW.js which is shared by all the NWJS application in the system, and a package tool which generates an installer for your app to download and launch our installer. We would also consider making configurable builds (like make menuconfig for the Linux kernel) once upstream modularize the web engine, but that would be even later.

In NW13 the binary size will be slightly bigger than NW12 because there will be more chrome.* API support due to demand: https://github.com/nwjs/nw.js/issues/518 .

Thanks,

Roger

On Monday, March 30, 2015 at 11:31:34 PM UTC+8, hushth...@hushmail.com wrote:

The #1 priority, now that NW12 is stable should, in my opinion, be to try to minimize the size required to distribute as much as at all possible. This really is way more important than some people seem to think. It matters little if NW helps me to create a useful little app when that app has to be distributed as a mega ZIP which unzips to 100+ MB on the system. This is the biggest problem with NW as I see it, and something I wish that will be taken seriously.

[Ben]

+1 on VoidVolker's suggestion. More options on source unpacking and being able to unpack the source directly into memory would be excellent!