Arch Linux User Repository

Sorry for the delay, life got busy for a few weeks.

Glad you found a fix, @akaessens! I actually removed the custom User-Agent when I was doing the overhaul, since my testing didn't reveal any problems, sorry about that... Classic Chesterton's fence. It's odd that I couldn't reproduce this, perhaps my account has "less secure app access" enabled (can't find it in my settings), or it has something to do with both of my accounts being on Google Workspace. Will test with my old personal account from now on.

Nativefier has a relevant issue. It's a shame nobody has gone through the trouble of figuring out how Google knows that the default User-Agent is fake yet.

@alecmev any idea what is causing the login not working? I reproduce it, too with electron v11.3.0. EDIT: The issue is the user agent of electron. It needs to be set explicitly to something else or google forbids the login. This was an issue in previous releases but i forgot that this happened. Fixed now.

@alecmev. I have an up-to-date system with Electron 11.3.0-1 installed. I tried the app in a fresh Arch VM that never had any software installed, and it had the same issue. I ran both versions from the terminal, and the non-dark version throws this error:

WARNING: Ignored nativefier.json rewrital (Error: EACCES: permission denied, open '/usr/share/google-calendar-nativefier/nativefier.json')

I have screenshots of all of this here.

I tried a quick change of permissions and ownership to see if that affected the error, and it didn't. I don't think this permission error is related to my login issue.

I also tried with a different Google account. No change.

@connorhodes Thanks for reporting. I've nuked my app data directory (so it's like a fresh install) and went through the login procedure, without issues, including 2FA. Not sure where to even begin, to be honest... Is your system up-to-date, specifically Electron? Can you make a screenshot of the error, please?

I can't login with this package. I get a "This browser or app may not be secure" message. Strangely, I don't get this message with the "google-calendar-nativefier-dark" package. That one works without issues.

Yes please! I haven't thought about this before but I like that. Resource usage is one of the main problems of electron-based applications.

Is there any advantage over official todist-appimage and todoist-electron which was officially recommended before?

The main advantage is the shared runtime, which hopefully saves some RAM and CPU cycles, at the expense of a slightly higher chance of breaking between major releases of Electron (unlikely, since, AFAIK, Electron never introduces breaking changes without putting them behind a flag first and asking everybody to adjust their code). Todoist's official app doesn't appear to do anything special, so there's no sacrifice.

Speaking of, do you mind if I switch this package to the same style of PKGBUILD as todoist-nativefier, i.e. use shared Electron?

Alright thank you. I'll be co-maintaining to stay up to date until the other packages are adopted.

Offtopic: I switched away from google services, therefore i'm using a nextcloud calendar and and todoist for notes. I see you're maintaining todoist-nativefier, cool! Is there any advantage over official todist-appimage and todoist-electron which was officially recommended before ?

I maintain other Nativefier-based packages, so happy to adopt this one, but not the other two, sorry. Off-topic, but what do you use instead, if not a secret?

Thank you for the heads up, that is quite annoying. Especially as i don't use it myself anymore and therefore cannot see it within short time to update again. If somebody would like to adopt this one, that one and the other one I'd be happy to hand over responsibilities.

Please, consider bumping the pkgrel every 59 days, because otherwise every user of this package needs to rebuild it manually, as to avoid the old build warning, which starts coming up for builds which are 60+ days old. The warning can be disabled, but this is a good practice regardless.