A Qt system tray app should not be the suggested install route

[cunidev]

These are my main points:

• at least 50% of Linux users, especially "vanilla" distro ones/newcomers, are using GNOME, which does not (sadly) support system trays anymore.
• it forces users to have an extremely heavy dependency for little practical utility: as Linux is not Windows, it could well be running in background as a service/daemon the whole time for most users, who would still know how to properly start and stop it.
• any UI toolkit should be fully detached from the back-end part by default, and suggesting a Qt "tray" UI as default for Linux users somewhat breaks this rule

Instead, providing instructions on creating a .desktop file (or including it) that simply starts the background daemon (like libinput-gestures does) would be a much cleaner approach.

[ErikBjare]

That the GNOME team decided to break an API that's available on virtually every platform is on them. We (me and Johan) have decided to not do anything about this, but if a GNOME user contributes a GNOME-friendly solution we'd gladly accept it. Most of our users are not using Linux, and most people reading the getting started guide are likely to want the aw-qt manager since it's by far the easiest way to start using ActivityWatch. I'm not sure what you mean when you imply that aw-qt is not detached (or rather, decoupled) from the "backend". It's literally just a small tray that manages the back-end processes that can be run fully independent of aw-qt.

…

On Fri, 4 Oct 2019, 17:14 cunidev, ***@***.***> wrote: These are my main points: - at least 50% of Linux users, especially "vanilla" distro ones/newcomers, are using GNOME, which does not (sadly) support system trays anymore. - it forces users to have an extremely heavy dependency for little practical utility: as Linux is not Windows, it could well be running in background as a service/daemon the whole time for most users, who would still know how to properly start and stop it. - any UI toolkit should be fully detached from the back-end part by default, and suggesting a Qt "tray" UI as default for Linux users somewhat breaks this rule Instead, providing instructions on creating a .desktop file (or including it) that simply starts the background daemon (like libinput-gestures does) would be a much cleaner approach. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#26?email_source=notifications&email_token=AAKXDOX6GD4ZZCPZNIIRIKTQM5MUFA5CNFSM4I5RCNXKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HPWQHMA>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKXDORTFO3DPQHDTIYS2J3QM5MUFANCNFSM4I5RCNXA> .

[johan-bjareholt]

It's not hard to get aw-server running as a systemd daemon (we even supply systemd service files for that, it's also what I personally use).

For the watchers however that's a bit trickier as they can only be run with an X session context, so they have to start when X has started. Something like this might work, but I haven't tested it
https://superuser.com/a/1128905

[cunidev]

The simplest solution I found for Gnome and/or other desktops, with or without system trays, does not require Qt

I've simply created two files, start.sh and kill.sh, that couldn't be simpler:

start.sh:

#!/bin/bash

./activitywatch/aw-server &
./activitywatch/aw-watcher-afk & 
./activitywatch/aw-watcher-window [--exclude-title?] &

kill.sh:

#!/bin/bash

pkill aw-

Should something similar be the default solution for non-Qt users?

[ErikBjare]

Those that don't want to use the tray icon could do something like that, yes.

But as I said before, it won't become the default since the UX of it is terrible.

[cunidev]

Sure. My main question was: could something like this be added to the documentation as an install option for GNOME users?

[johan-bjareholt]

Sure, the docs already mentions Gnome 3 so you could change that text with something pointing to a section of the docs on how to run it easily on Gnome 3.

https://activitywatch.readthedocs.io/en/latest/getting-started.html#usage

[ErikBjare]

Your PR (#28) was merged. Closing.