Rewrite in some other language

[johan-bjareholt]

Since PyInstaller does not work reliably with QT and has created lots of issues for us we should probably consider writing it in a QT-native language so it can work cross-platform more reliably.

My first choice would be to write it in C++ with QT, but writing it in Rust with gtk-rs could also be an option if we feel like experimenting a bit.

[ErikBjare]

I'm terrible at C++, and almost as bad at Rust. Last time I looked into GTK I remember there was some reason that made it unpractical, but can't remember what it was.

For now, I think our best bet is still to work around PyInstallers rough edges (less work in the short run), but perhaps rewriting it will be a good idea in the future.

[johan-bjareholt]

The thing is we have to work around every case on different platforms which is barely viable even now, if we get even more users we will start spending even more time fixing PyInstaller. We don't even know how to work around these issues currently.

• "exo-open: symbol lookup error" when trying to open log folder #29
• error loading python dll python35.dll (error code 1114) #23
• "Open Dashboard/API Browser" not working when packaged with PyInstaller #20
• aw-qt not starting : got an ImportError out of nowhere! activitywatch#161

[xylix]

I don't know how open this issue still is / what of those open issues would get fixed without changing from qt. However if this is still an issue (since the issue is open) I'm giving what input I can.

As another option if besides qt and gtk I'd recommend considering electron for the tray widget (https://www.electronjs.org/docs/api/tray ). Even though electron get's a bad rap activitywatch already uses a browser page for the frontend and electron wouldn't really be that much worse. (Altough an electron tray icon app would probably use a non-significant amount of more ram.)

Qt also has their own official JS subset (https://doc.qt.io/archives/qt-4.8/qdeclarativejavascript.html ) which could also probably be packaged with a bit better support than pyqt.

[ErikBjare]

We considered it long in the past, but Electron is a no-go due to the RAM issue. It will run a whole instance of Chromium just running in the background for the tray icon, which is not acceptable.

If it weren't for this fact we'd use Electron in a heartbeat as we, as you mentioned, already have a web UI. But users don't need it open all the time, and running it in the users browser uses significantly less resources since it can share resources with a browser which is likely to be running anyway.

I'm not familiar with the Qt JS subset, but the plan here is to move to something like Rust and not just chance one interpreted language for another. Packaging aw-qt isn't much of a current problem since it now works somewhat well, so doesn't make sense to switch to something just because it's easier to package.

Edit: The Qt JS thingy is for building the UI, not as a general way to use the Qt library.