Windowing/Tray UX about ipfs-desktop

[jbenet]

• App permanently lives in the tray at all times

SGTM

• When the app window is open, a dock/task bar icon will open.

SGTM

• When the app window is closed, the dock/task bar icon is hidden, and the app lives in the tray.

SGTM

• Enable silent launching to the tray so that people can add the app to their startup apps

SGTM

I think that the menubar item should stay there and let you turn IPFS daemon on and off. menubar/tray item stays (unless you ask it to not show)). the logo can change to reflect whether ipfs is running or not, more grayed out when it's off, or whatever.

[bcomnes]

Ohh good point. Offline access to files is important as is quick access to starting/stopping the daemon when peering is inappropriate.

[jbenet]

oh we could also have a "daemon online but disconnected" mode.

[krl]

Most of these things were already addressed, but only seems to work properly when the app is run as a package. This should be ok imo.

open:

minimized:

closed:

[jbenet]

seems to work on osx, too. \o/ gj

• considering whether it should use a repo in the app bundle? (so when people trash ipfs, it deletes everything? but then again maybe not. not sure, maybe best to keep it in default location) cc @bcomnes thoughts?
• it's using my $HOME repo (~/.ipfs), but not clashing with a daemon i have running... (maybe the electron-app daemon is failing to bind ports and it just "happens" to work cause the ports are the same?)
• also, if i move my repo away (i.e. no ~/.ipfs), launching the electron-ipfs.app doesnt do anything. maybe stuck somewhere? (is wizard supposed to appear here?)

[bcomnes]

¯\_(ツ)_/¯ I think keeping node data in the app bundle is the wrong place to keep it. I like using ~/.ipfs. What use case would there be for running a daemon AND a the electron daemon at the same time?

We may also consider using system sanctioned locations for data like ~/Library/Application Support

[jbenet]

We could let the user choose when it launches, maybe between:

• IPFS Default: /Users/<user>/.ipfs
• System Default: /Users/<user>/Library/Application Support
• Custom: [________________________________________]

[dignifiedquire]

@bcomnes @jbenet can you please check the latest version, and update the issue accordingly?

[jbenet]

Need to verify it works fine on:

• Linux - @krl ?
• OSX - @diasdavid ?
• Windows - @gatesvp @Mithgol ?

(what's your OS @dignifiedquire @bcomnes ?)

[dignifiedquire]

I have OS X and window in a vm

[daviddias]

works fine for me on OSX (and sent a shout to some more devs that are big fans of React and WebPack :)

[Mithgol]

I assume we are talking about https://github.com/ipfs/station

As its README recommends, I've cloned the repo and then run npm install.

I've watched it running for an hour and installing 869 dependencies in node_modules\.staging and then I've forced it to quit because I had to go and I had to take the flash drive with me. (I am sure there were even more dependencies, not only those 869.)

Ideas:

• Maybe it should be recommended to run npm install --production instead of npm install.
• Maybe a pre-built version should be distributed as a single archive to reduce the overhead of downloading hundreds of dependencies.

[whyrusleeping]

@Mithgol a prebuilt binary will be provided for users once the project is ready for release.

[Mithgol]

The file package.json also assumes a non-Windows system where it uses NODE_ENV=production some_command because that syntax (AFAIK) is not supported by the command line of Windows.

[bcomnes]

https://github.com/ForbesLindesay/win-spawn is a commonly recommended way to route around that issue, however I find that it doesn't always noop on unix systems like its supposed to. It could be a matter of just squashing a bug though, I haven't had a chance to really look into it.