othiym23
05:44
it's not a very helpful way of doing it tho
Yesterday
groundwater
05:48
2.0.0 stable has been released: https://github.com/electron/electron/releases/tag/v2.0.0
daviwil
08:25
@zeke what's the limitation for making the updater work on Linux?
or just Not Done Yet
marshallofsound
08:25
Electron has no autoUpdater for linux
You should distirbute through standard Linux repos for installation / update like apt and yum
daviwil
08:26
But that's what I'm trying to avoid
malept
08:26
Or use Snaps.
marshallofsound
08:26
Or use snaps yeah
daviwil
08:26
Aside from needing to make sure the user has the right prereqs installed, is there any other fundamental limitation?
marshallofsound
08:27
Linux users won't be a fan of yours if your app self updates
malept
08:27
Snaps essentially self update though
marshallofsound
08:30
Nah, the store updates them right
daviwil
08:30
Problem with using Snaps is then you get involved in the Snap vs AppImage debate
marshallofsound
08:31
Not much of a debate imo
daviwil
08:31
For context, I'm asking about this for Atom
marshallofsound
08:31
Snaps are supported by canonical
daviwil
08:31
Trust me, they will debate it anyway
marshallofsound
08:31
Oh yeah
daviwil
08:31
Snap did seem to be the ideal approach for me
Fedora has pretty good Snap support too but you have to install it first
I was mainly just checking to see if I could remove the whole class of problems by using the new updater service
marshallofsound
08:32
What is atoms update story on Linux atm?
daviwil
08:32
But if not, not a problem
We serve deb/rpm feeds using packagecloud.io
As of December
marshallofsound
08:33
Sounds fun
malept
08:33
You guys can use
electron-installer-snap
daviwil
08:33
Yeah, not so great, and costs a decent amount of money
marshallofsound
08:33
Without self plugging
Too much
Supports windows, macOS and both variants of Linux repos (apt / yum)
All just backed by an s3 bucket
daviwil
08:34
that's convenient as we already store all our release assets in a S3 bucket
marshallofsound
08:37
It's got we needed internally for update stuff so should work well for atom. We're gonna still rolling it out atm (switching from our old update stuff takes a while) but when we do it'll save a bunch of money and effort
daviwil
08:38
thanks for pointing it out! looks really interesting
I had basically started looking into doing something like this on my own but decided to just pay someone else to deal with it
daviwil
08:41
I am definitely considering some other approach like Snap or AppImage for Atom but there's just limited time to look into everything
I believe the Snapcraft site already has its own Atom distribution
malept
08:42
I'm quite sure that they'd hand over the app updating to the Atom team if y'all asked
daviwil
08:42
yeah, I found a wiki page saying as much
malept
08:43
For reference, I spent 1.5 weeks working on Electron+Snap packaging literally next to Snapcraft devs
daviwil
08:44
nice!
I remember hearing about that effort
zeke
09:04
@daviwil looks like I’m fashionably late and @marshallofsound and @malept already answered all your questions
daviwil
09:04
yep! I have the info I need
bengotow
09:05
ahh man I made Mailspring a Snap and I can confirm appimage fans argue a lot haha
felix
09:10
+1 for snaps. The updating works extremely well, it’s Slack’s most successful updating mechanisms when it comes to getting everyone on the new version asap.
daviwil
09:10
any complaints from folks who think they shouldn't have to install snapd in their distro just to install the Snap?
felix
09:11
Zero, but then again, we don’t give them reason to complain - we still offer a
.deb via packagecloud.io (just like you do)
@felix uploaded a file: Slack's Snapcraft Update Chart
daviwil
09:12
It'd be more likely for rpm-based distro users to complain I guess, but maybe it's not really standard for anything other than .deb to be provided for most things
felix
09:12
Look at this beauty: That’s the stuff dreams are made of
(edited)
daviwil
09:12
nice!
marshallofsound
09:22
Is that like 95% in 7 days?
timfish
09:30
Does anyone get asked for 32bit Linux builds? I said we'd re-evaluate if anyone asked and nobody ever has...
paulcbetts
09:50
@felix That is an extremely nice update graph
Ironic given that Linux has historically been the worst updated app by a country mile
What's that graph look like for Windows?
marshallofsound
09:51
hopefully just a blue rectangle
then when felix shows it to people, we can all make blue screen jokes
i'll leave now
paulcbetts
09:56
Squirrel.Windows is pretty good, but not 95% in a week good
Though some of that speed requires you to aggravate the user by like, closing their app and shit
Which I never wanted to do
marshallofsound
09:56
I guess it depends on total user volume, and how annoying your update notification is
paulcbetts
10:14
@zeke sorry sorry I wrote u an essay https://github.com/electron/update-electron-app/issues/22
Hi! I love that someone is trying to make the update process more straightforward and easier to set up for Electron developers. As one of the original authors of Squirrel, I'd like to share a bit of the philosophy of Updating that might inform some of the design decisions around the default update experience.
The Zen of Updates
One of the things we always tried to make possible in Squirrel is, "Never get between a User and their Work". Users open apps because they want to get something done, and we as developers want to respect their time. Software Updates by unfortunate necessity get in the way of that - we're asking the user, "Please, stop thinking about your stuff, and think about my stuff instead"
To that end, Squirrel makes it possible (but not required!) to do completely silent updates in the background. While that's not appropriate for every application, it's a great experience for those that can do it, because users Don't Have To Think. When we do have to pop an update dialog, we should do it at a very context-appropriate time - for example, in a music application, a good time to show an update dialog is at the end of the album / playlist: the user finished what they wanted, and they have to interact with an app anyways to do The Next Thing.
What To Do
So, I suggest that:
1. The default UX is nothing, it just fires an event
2. The code for showing the UI dialog gets moved into a public method with a super clear, obvious-to-intent name
This lets people who want that dialog as maybe a way to get started, to get it with a one-liner, but still let people have silent background updates if they think it's appropriate for their app (PS: it probably is!)
Why It Matters So Much
Defaults are important - even if some People Who Care make a great experience, we know that the vast majority of people are going to just do whatever update-electron-app leads them to by-default. This means we have a huge opportunity to make the update experience for lots and lots of new Electron apps Great By Default, which is extremely rad and good!
The Zen of Updates
One of the things we always tried to make possible in Squirrel is, "Never get between a User and their Work". Users open apps because they want to get something done, and we as developers want to respect their time. Software Updates by unfortunate necessity get in the way of that - we're asking the user, "Please, stop thinking about your stuff, and think about my stuff instead"
To that end, Squirrel makes it possible (but not required!) to do completely silent updates in the background. While that's not appropriate for every application, it's a great experience for those that can do it, because users Don't Have To Think. When we do have to pop an update dialog, we should do it at a very context-appropriate time - for example, in a music application, a good time to show an update dialog is at the end of the album / playlist: the user finished what they wanted, and they have to interact with an app anyways to do The Next Thing.
What To Do
So, I suggest that:
1. The default UX is nothing, it just fires an event
2. The code for showing the UI dialog gets moved into a public method with a super clear, obvious-to-intent name
This lets people who want that dialog as maybe a way to get started, to get it with a one-liner, but still let people have silent background updates if they think it's appropriate for their app (PS: it probably is!)
Why It Matters So Much
Defaults are important - even if some People Who Care make a great experience, we know that the vast majority of people are going to just do whatever update-electron-app leads them to by-default. This means we have a huge opportunity to make the update experience for lots and lots of new Electron apps Great By Default, which is extremely rad and good!
jhgg
15:25
Discord gonna try to hit up the electron 2.0 upgrade to our canary channels. We pushed 1.8.6 today (from 1.6.15), and it was not too good. Lots of GPU/rendering/perf issues. I didn't see much in the issue tracker though. Gonna see if 2.0 exhibits these issues and see what we can do...
We get asked for 32 bit linux builds all the time btw tim.
jhgg
15:33
re: updating, for windows, we update the app in the background, then show a little "update ready" icon users can click at their convenience.
it's a bit worse a story if u are outdated, and we have to update you before we launch the app... we eventually wanna make this happen in the background, and let you launch the old version while we upgrade you...
we shipped a host update today to our stable channel, and I think we saturated the egress on some Cloudflare colos... oops
it's a bit worse a story if u are outdated, and we have to update you before we launch the app... we eventually wanna make this happen in the background, and let you launch the old version while we upgrade you...
we shipped a host update today to our stable channel, and I think we saturated the egress on some Cloudflare colos... oops
kilian
16:23
As both a linux user and someone that has spend a godawful long time publishing stuff on PPA's and getting it accepted into official repositories I'm inclined to disagree
Linux users won't be a fan of yours if your app self updates
RyanZim
23:39
Links to other parts of the article here are broken: https://electronjs.org/docs/tutorial/security#checklist-security-recommendations
(edited)
Today
zeke
01:03
Would love to get some of this linux updating info into the docs: https://github.com/electron/electron/issues/12796
(edited)
timfish
01:56
if you paste the following into the renderer console, what would you expect to happen?
require('timers').setTimeout(() => { throw new Error('Test'); }, 1)
Nothing happens at all until I navigate around the app for a while and then it eventually hits the renderer console and locks up the renderer
on an empty test app I can't get it to come up in the console at all
require('timers').setImmediate(() => { throw new Error('Test'); })has the same delay and when it eventually makes its way through the event loop terminates the renderer whereas throwing in window.setImmediate terminates the renderer instantly
paulcbetts
02:05
Is
timers a 3rd party module?
timfish
02:05
no, node timers
paulcbetts
02:06
That's quirky
Attach a debugger to the renderer and get the call stack of the crash
timfish
02:08
I've been looking into where errors in the render can come up through the node error handlers rather than the chromium ones: https://github.com/electron/electron/issues/12790
(edited)
As in attach a native debugger? Strange thing is this doesn't hit the breakpad crash reporter.
paulcbetts
02:10
Ya
process.pid in a console, then lldb -p $THAT_PROCESS
timfish
02:14
Ah,
window.setImmediate(() => {throw new Error('Die!')}); in 1.8.6 terminates the renderer but in 2.0.0 it doesn't so there must have been some changes there.
timfish
02:35
@paulcbetts in 1.8.6 there's nothing to catch in the debugger, the renderer process appears to exit "gracefully" on errors in the node context
paulcbetts
02:36
You should still be able to breakpoint on the exit call and see who made it, right?
timfish
02:36
true that
timfish
03:00
Still bootstrapping electron. Interestingly, adding
process.on('uncaughtException', () => {}) in the renderer stops the process from terminating
ajm
04:02
@ajm has joined the channel
nornagon
07:32
does anyone that we know of embed libchromiumcontent without electron?
zcbenz
08:45
there used to be a few apps, all of them are long dead now
jhgg
15:00
electron 2.0.0 not looking good so far lots of weird graphical glitches, anyone have any ideas? here's an example from one of our users: https://i.imgur.com/9iJyQlk.gifv
bpasero
15:21
@jhgg we also saw flickering with 2.0 for certain elements where we used
webkit-mask via CSS and the only way to fix it was to put those elements on a separate composition layer (e.g. via will-change:transform)