0.13 - Single instance only! :-(

[Fergus]

The "Migrate from 0.12 to 0.13" page in the docs says: "single-instance is deprecated and it’s always true. You CANNOT have multiple instances for your app."

This is truly a killer blow.

It means that an editor, for instance, cannot have two instances open. I don't know about anyone but I have four or more open when working on a project. Or a game app that allows communication between two players via sockets cannot be tested with two instances on the same machine. Likewise various handy dev tools or user widgets - database viewers. image and pdf readers, file explorers/tools, handy calculators or web-watching widgets... these are all cases where the user being limited to just one instance means going elsewhere for their application, even if the nw.js one is otherwise the bees knees.

Is the cause of this restriction insurmountable? Could creative minds puzzle a way around it?

[LZAntal]

Hi,

On Feb 5, 2016, at 10:04 AM, Fergus <firg...@gmail.com> wrote:

The "Migrate from 0.12 to 0.13" page in the docs says: "single-instance is deprecated and it’s always true. You CANNOT have multiple instances for your app."

This is truly a killer blow.

I felt this way but…

It means that an editor, for instance, cannot have two instances open. I don't know about anyone but I have four or more open when working on a project. Or a game app that allows communication between two players via sockets cannot be tested with two instances on the same machine. Likewise various handy dev tools or user widgets - database viewers. image and pdf readers, file explorers/tools, handy calculators or web-watching widgets... these are all cases where the user being limited to just one instance means going elsewhere for their application, even if the nw.js one is otherwise the bees knees.

Is the cause of this restriction insurmountable? Could creative minds puzzle a way around it?

I use nwjs for my RaptorGL editor. As you said I had multiple instances running with multiple windows. Moving to 13 it was gone and frustrating at first BUT! I started to think about my design and use cases and I ended up liking the change. Now I have a “main” window that handles opening other windows and setting the Project object to feed the directory tree, last opened files, debug port etc…

What this allowed me to do is to have a tighter integration between them. Also this made my tools use a lot less resources, mainly the device simulator where you run your game and live edit it(hot swap code). Before you could have multiple of them running but now I only allow one of them just the way Xcode does it for iPhone simulator. This is a change I wouldn’t have thought of if I could run multiple instances at the same time. I got a tons of thumbs up from my beta testers for about not using so much ram and cpu.

Of course it doesn’t mean that it works for everyone and every project but the projects you mention all can be created and used with single instance. For your multiplayer game I am actually happy it can’t be run on a single machine. Why? because you can still run it on your local network and unless you encounter packet droops and latency all your test will be false and misleading. I actually used two machines to run the editor and connect even though I could have run it on the same machine. 

Hope it helps.

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.

[firg...@gmail.com]

Yes, it's certainly possible to design and implement a top level manager that controls multiple windows under the same instance of the app but should it have to be necessary? Every programmer who wishes to provide multiple instances is now required by NW.js v0.13 to reinvent a wheel that NW.js v0.12 already provides out of the box - and I'm sure that not all programmers will make a good job of it.

Some won't bother if it's too hard and others may not even realise that some people might want multiple instances. If a user obtains a utility, game or whatever from someone who didn't, or couldn't, create a workiing top level window manager then what choice do they have? Find something similar write to use Electron or Tint?

Another issue is how a subsequent instance would get opened. From what you've said, I gather that the user asks your application for a new window and off they go. How would it work if that window isn't readily available? Consider a NW.js calculator app that's not quite as trivial as Window's own. The user might have opened it, used it and moved on. It might be buried under a pile of other windows or even away, out of sight, on a different virtual desktop. The user may have forgotten that they've even got it open. They click a shortcut for the calculator, or press a hotkey combination, and nothing happens. Confusion and frustration ensues... and then possibly a hunt by the user to find the missing open app. It's all very unnecessary.

Heh heh. You shouldn't be glad that I can't run my two game instances on a single machine. I'm still testing the game logic and message protocol so the transport efficiency is a problem for a later todo list. :-)  Actually it doesn't even need to be two players communicating. I've had six instances of the game open just for myself, to analyse the options for my next move. Now I could do what you've done and write a window manager for that but if I adopted NW.js then I'd only be putting back a facility that I already have.

I don't use actually NW.js, I use MS HTA, the original Html+Css+Js application container. It's giving me good service for over a decade but it's time to look for a successor. I'm literally only just evaluating NW.js against the other options and v0.13 loses big points for this limitation.

[LZAntal]

Hi,

On Feb 5, 2016, at 2:21 PM, firg...@gmail.com wrote:

Yes, it's certainly possible to design and implement a top level manager that controls multiple windows under the same instance of the app but should it have to be necessary? Every programmer who wishes to provide multiple instances is now required by NW.js v0.13 to reinvent a wheel that NW.js v0.12 already provides out of the box - and I'm sure that not all programmers will make a good job of it. 

Some won't bother if it's too hard and others may not even realise that some people might want multiple instances. If a user obtains a utility, game or whatever from someone who didn't, or couldn't, create a workiing top level window manager then what choice do they have? Find something similar write to use Electron or Tint?

You can always make that change to the source if it’s a deal breaker. I am also a big believer of the right tool for the right job. So if it’s another framework then I would switch, in my client projects(not related to webtech) I use multiple frameworks instead of trying to bend any one of them :))

Another issue is how a subsequent instance would get opened. From what you've said, I gather that the user asks your application for a new window and off they go. How would it work if that window isn't readily available? Consider a NW.js calculator app that's not quite as trivial as Window's own. The user might have opened it, used it and moved on. It might be buried under a pile of other windows or even away, out of sight, on a different virtual desktop. The user may have forgotten that they've even got it open. They click a shortcut for the calculator, or press a hotkey combination, and nothing happens. Confusion and frustration ensues... and then possibly a hunt by the user to find the missing open app. It's all very unnecessary.

Hmm why don’t you try it first. If you have an app opened and buried under other windows and you click the icon again the window comes to focus. So nothing is hidden and can’t be found.

Heh heh. You shouldn't be glad that I can't run my two game instances on a single machine. I'm still testing the game logic and message protocol so the transport efficiency is a problem for a later todo list. :-)  Actually it doesn't even need to be two players communicating. I've had six instances of the game open just for myself, to analyse the options for my next move. Now I could do what you've done and write a window manager for that but if I adopted NW.js then I'd only be putting back a facility that I already have.

Sure it’s later on your todo but doing it later is a big pain. Unfortunately I am talking from (bad) experience lol. 

But you can still use it by creating a second set of package.json and run it from another folder with a diff name. Actually that way even your local storage would be separate and you could inspect saved stages and other requirements like login etc…

I don't use actually NW.js, I use MS HTA, the original Html+Css+Js application container. It's giving me good service for over a decade but it's time to look for a successor. I'm literally only just evaluating NW.js against the other options and v0.13 loses big points for this limitation.

I am happy to admit that I left nwjs about 3-4 times and I’ve always came back and this time for good. 

I have been working on acquainting myself with the inner workings of nwjs and hoping to start contributing back to the project.

I would recommend you to create a very basic project and use that to run it through all the diff frameworks out there. Then add a tons of advance features to it and do it again, you’ll see why I came back :)) Btw I wish I done that instead of just jump around. So hopefully it will save you time ;)

[Roger]

Being single instance doesn't mean your editor application can only open 1 file at the same time. You can still use multiple windows for that. When user try to launch the 2nd instance, the first instance will receive an event with the information (e.g. another file user wants to open) and it could open another window. http://docs.nwjs.io/en/v0.13.0-beta5/References/App/#event-openargs

Besides that, you can still launch another instance with a different user data dir (--user-data-dir). Is that good for you?

The chromium's user data directory is designed to be accessed exclusively, e.g. locks on files and databases. This actually applies to version 0.12 and earlier too... It might be possible to launch the 2nd instance with read only access to the same user data directory.

Roger

--

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

There are some pretty weighty implications IMO:
* nw.js cannot be packaged for Debian
* developers cannot quickly test network-based apps on a single machine
* developers can't even quickly compare two instances of the same app with different state (for testing and bug-hunting purposes)

If user-data dir is the only sticking point, then why not just make --user-data-dir a required
flag when --single-instance is false?  Or use a unique tmp dir if --user-data-dir isn't
specified, etc.

[lza...@gmail.com]

Hi,

On Feb 6, 2016, at 14:34, jon.w....@gmail.com wrote:

There are some pretty weighty implications IMO:
* nw.js cannot be packaged for Debian

What do you mean by it? Specific to Debian or Debian based? I have no problem packaging it for Ubuntu. 

Actively testing on it. 

* developers cannot quickly test network-based apps on a single machine

False. As I mentioned it's a simple copy paste diff name. Rogers suggestion was even simpler. 

* developers can't even quickly compare two instances of the same app with different state (for testing and bug-hunting purposes)

Same as above. 

If user-data dir is the only sticking point, then why not just make --user-data-dir a required
flag when --single-instance is false?  Or use a unique tmp dir if --user-data-dir isn't
specified, etc.

I suggest you just start using it instead keep reading into too much these issues and judging it before you get your hands dirty :))

If you run into anything specific post it here and the very friendly community will help out. 

Heck if you need quicker help hope on Twitter and ping me as many others done it. If I can I'll be happy to assist. 

Laszlo

http://twitter.com/LZAntal

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

On Saturday, February 6, 2016 at 6:15:29 PM UTC-5, LZAntal wrote:

Hi,

On Feb 6, 2016, at 14:34, jon.w....@gmail.com wrote:

There are some pretty weighty implications IMO:
* nw.js cannot be packaged for Debian

What do you mean by it? Specific to Debian or Debian based? I have no problem packaging it for Ubuntu. 

Actively testing on it. 

 

 Ah, sorry.  I confused multiple instances of the same app running under nw.js with multiple instances of nw.js itself running.  Nevermind that one.

Can you or Roger tell me more about the relationship between --user-data-dir and multiple instances?  I want to be able to specify the _same_ package.json path to nw and get multiple instances of my app.

Is there a straightforward demo somewhere?

Thanks,
Jonathan

[wombat...@gmail.com]

I found a temporary solution to this.

What I did was basically copy and pasted my index.html to index2.html (and removed this code [that I have put in index.html]).

  setTimeout(function() {

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

      // Create a new window and get it

      var new_win = gui.Window.open('/NXSBIN/main2.html', {

          "icon": "./NXSBIN/img/icon.png",

          "title": "Nexus Slasher",

          "frame": true,

          "resizable": false,

          "position": "center",

          "width": 1280,

          "height": 740,

          "show": true,

          "fullscreen": false

      });

  }, 2000);

I added this inside index.html but removed it from index2.html.  So when you set your package.json to open index.html first, it will then open index2.html after a few seconds. Works great and if you're using SDK build you can use chrome tools on both windows.  

The reason for the seconds is I find a slight bug when you open the window instantly, you must give it atleast a second or so.

Hope this helps!

-- Nick