Developing aw-webui only

To start with, it is a great project and thank you for developing that. I used to use Qbserve (nice vis, and direct feedback via taskbar, but Mac-only). I change my OS to Win, and I was happy to see ActivityWatch (open source and hackable, even with an interactive API help).

I would like to contribute to the dashboard part - as I am into data viz and Vue part (vide my projects). First, things I would like to use personally. Second, if other people like it, I would be more than happy to PR them.

Is it possible to install aw-webui only and use binaries for everything else? That is, run the app from a release and only have a custom installation of the web interface?

I did try to do that, and while the Vue app runs, it fails to connect:

sockjs.js?9be2:1606 Refused to connect to ‘http://192.168.0.185:27180/sockjs-node/info?t=1578067003591’ because it violates the following Content Security Policy directive: “default-src ‘self’ 127.0.0.1:5666 :27180 ws://:27180”. Note that ‘connect-src’ was not explicitly set, so ‘default-src’ is used as a fallback.

I did set cors_origins = http://localhost:27180 in C:\Users\pmigd\AppData\Local\activitywatch\activitywatch\aw-server\aw-server.ini as instructed.

(I tried to install the whole thing, according to instructions, but run in some problems. In any case, my preference is to use a stable version and tweak only the visualization.)

We’d be happy to see contributions, the web-ui certainly needs improvement!

The answer of that is: kind of.

It usually works, but it is not uncommon that the latest git master of aw-webui depends on some feature which only exists on the aw-server git master.

That’s because you are running aw-webui with “make dev” or “npm run dev” which tries to connect to aw-server in testing mode while you are likely running it in release mode. If you simply start aw-server with “aw-server --testing” it should start in testing mode with a seperate database to avoid messing up your standard install.

Another option would be to run “make build” or “npm run build” and copy the compiled aw-webui assets to the activitywatch folder and replace the existing ones, then your changes will be accessable on “127.0.0.1:5600” as usual.

Thank you for your answer, it helped me to set it up!

CORS and server vs web

However, it is not clear to me why I cannot pass the CORS blockade and get data from another “release” install of Activity Watcher at all. Yes, I expect some possible changes of API between versions. While I am thinking about make case to be able to quickly prototype things with my data, I think that in general, it would be wonderful to offer a way to interact with data in a way one pleases.

EDIT: It is possible after changing 5666 to 5600 in a few places: awclient.js, aw-client.ts and index.html. Or is there a simpler way to go, with to serve the Vue app with these settings?

It was somewhat unclear from the instruction that aw-server runs also the website, but which is NOT modified by changes of aw-webui files (why?).

Installation

I was able to partly install it on macOS (except for PyQt5), and run the server.

Still, on Windows (in PowerShell), I have trouble installing the whole part (there is no default make and neither choco make nor npm make work). Did anyone try to do that on Win Powershell?

On Windows (with WSL Ubuntu and Anaconda environment), I managed to install everything.
After aw-server --testing and cd aw-webui && npm run serve I kind of get results (data & vis - but the later in Timeline takes a longer delay, 20 s or so), but sometimes still get the same CORS errors (not sure why).

As a side note, no matter what is the system, there are a few issues in the Makefiles, mostly around using pip3 inconsequentially (which is not guaranteed to point to the environmental pip, e.g. in conda), the order in which poetry is being installed (also, used from some subrepos, for some - not). The same holds for python vs python3 (in this case it was problematic in some environments).

I would be happy to PR to Makefiles and instructions, but beforehand I would prefer to make sure that I am not missing something crucial.

You could change aw-server and aw-client to bind to 5666 by default instead by changing the aw-server.ini and aw-client.ini configuration files. However, at that point you could just as well just run aw-server in --testing mode, no need to rebuild it.

Personally I always have a release build running and have a --testing server running beside it when developing. If I ever need to fill my testing server with more data or restore it I just export the buckets from the web-ui on the release version, remove all buckets on the --testing version and then import them over. Makes me feel safe so I don’t have to worry about messing up my database when developing.

Nope, no one have tested it with windows powershell. We have makefiles because that’s the easiest way for a build script which works on all platforms. Make is bundled with MinGW if you have that, otherwise it should be installable with “choco install make”.

But at that point you are essentially running it in Linux, which shouldn’t really be necessary.

No idea about why the timeline is so slow or why you get CORS errors, sounds strange?

That certainly sounds like definite bugs, me and @ErikBjare which are the ones who primarily develop AW run it on Linux distros where “python” means “python3” and “pip” means “pip3” but that’s certainly not always the case.

Regarding poetry, the plan is to make all repos use it, we just started using poetry a couple of weeks ago. It’s still in progress. Not sure if it’s worth porting aw-server-python to poetry but the watchers definitely should be ported.