Bucket and event design fo VS-Code extension

Support
#1

Hey there,

over the last few days I’ve tried to create a vs-code extension which tracks the current project/coding-language/editor. To accomplish this, I’ve build following stuff:

  • VS-Code extension
  • Nodejs / typescript ActivityWatch Client (for making api-calls) + little wrapper
  • mocha tests for the ActivityWatch Client

It is all still work in progress, so some functions are still missing and the extension is just a prototype, but the first heartbeats were already sent :heart:
The current version of it: https://github.com/Otto-AA/aw-watcher-coding

Now I am wondering how you would do the bucket and event design.
I’ve came up with some possibilities:

(1) one coding bucket
Bucket: “aw-watcher-coding_{hostName}”
event.data:
{
editor: string;
project: string;
language: string;
}

(2) one vscode bucket
Bucket: “aw-watcher-vscode_{hostName}”
event.data:
{
project: string;
language: string;
}

(3) multiple buckets
Bucket: “aw-watcher-coding-project_{hostName}”
Bucket: “aw-watcher-coding-language_{hostName}”
Bucket: “aw-watcher-coding-editor_{hostName}”

Greetings
The Grand Alf

#2

Awesome! :smiley:

I see that you are doing the extension in TypeScript, but if you are fine with vanilla JS we would appreciate it a lot of you re-used the aw-client-js library for communicating with the aw-server HTTP API.
It’s not really necessary, but since we currently only use it in the aw-webui and are about to migrate aw-watcher-web to it we would appreciate if we could work on it together to create a great and high-quality client instead of duplicating work.

Our idea with buckets is that each activity type (window activity, afk activity, web activity and now programming activity) should have a standard data format which can be identified by the buckets type id. We should come up with a standard format for programming activity aswell.

To start off, aw-watcher-coding is a very ambiguous name and might cause problems if a bucket with that name exists with multiple editors (for example both eclipse and atom both do heartbeats to a bucket with the name aw-watcher-coding). So with that in mind option 2 seems like a good way to structure the data, but to me it would also be useful to have a “file”/“filename” field.

A friend of ours also wrote a watcher for vim which I have wanted to try out but haven’t yet, would be nice if we could come up with a format which you could both use.

Good luck, if you have any more questions we’re here to help! :slight_smile:

#3

I’ve published the first version (0.1.0) to the VS Code extensions now :slight_smile:

As far as I’ve tested, it works fine. Yet I’ve noticed, that the activity dashboard doesn’t recognize this bucket. Would it be possible to do something about this? (e.g. a dropdown with all remaining buckets)? If yes, that would be awesome!

In the future, I will implement some commands (disable, reload for the case the server wasn’t running), maybe settings, a test file and cleaning up the code + documenting it a bit better.

Btw, how do you link folders in git(/hub) like you did in aw-webui with aw-client-js @ 8ca96b8? Is it possible to do this locally, so the aw-client.ts is linked to this specific version on github?

If you have any feedback, I’d be glad to hear it :slight_smile:

#4

Awesome :smiley:

The current data in the Activity view is currently only written for window activity and browser activity, since you just started writing a watcher for code activity I’ve started to improve aw-watcher-vim so it works for me (since that’s my editor of choice) (nvim incompatible · Issue #1 · ActivityWatch/aw-watcher-vim · GitHub), once I get that to work we should decide on a standard format for the coding activity and I’ll implement this in the Acitivty view aswell for you!

In the mean time it is possible to manually use the “Query” tool in the web-ui to get a visual summary of your bucket data, but as of now this tool is not yet documented at all so I am betting it will be hard for you to get it working since you do not know the aw-core codebase :stuck_out_tongue:

Google up “git submodules” and you’ll understand :slight_smile:

1 Like
#5

Regarding the coding activity event format, this is the one I currently use:

  • editor: “Visual Studio Code”
  • language: “typescript”
  • project: “vs-code-extension” // The currently opened folder / workspace
  • file: “extension.ts”

Do you think this format is missing something?

Besides that, I am not quite sure what I should do if some data of this event is unknown. For instance, when opening an image file, it seems impossible for the extension to get the file and language. Currently I simply don’t send those, but probably it would be better to send them with file: "unknown"…?

#6

I started working on the aw-watcher-vim watcher and it seems to work for me now and have thought about this aswell.

The editor field is unnecessary since it will always be the same in every event anyway and the bucketname describes what the editor is, so you can remove that to save some disk space.

You can actually remove the language field aswell. Since vim and other more simpler editors sometimes don’t have an API to fetch the language of the file we would have to do this analysis in the aw-server anyway, so the suffix from the file should be enough.

The project field i named “workdir” since that’s more abstract and would be an accurate name for both editors and IDEs. I have been thinking about if we should only have the folder name or the whole path here and have concluded that it’s probably best to save as much data as possible and then if we want to we can remove the parent folders during the analysis in aw-server later instead.

I named the file field “filename”, but maybe I should just name it file as you do instead since that’s descriptive enough and shorter.

So, in essence I would propose this format:

workdir: string (complete path to project folder, eg "/home/me/Programming/project")
file: string (filename, eg "extension.ts")

Yeah, “unknown” is probably better than nothing. In that case you would know that there was activity at least.

#7

The editor field is unnecessary since it will always be the same in every event anyway and the bucketname describes what the editor is, so you can remove that to save some disk space.

At least in VS Code it can differ when working in the development build of VS Code. But I guess this marginal case isn’t worth the disk space.

You can actually remove the language field aswell. Since vim and other more simpler editors sometimes don’t have an API to fetch the language of the file we would have to do this analysis in the aw-server anyway, so the suffix from the file should be enough.

I sometimes work with files which don’t have a suffix (in particular bash scripts in the ~/bin folder). For these cases it would be nice to detect the language the Code editor and not make a guess afterwards.

file: string (filename, eg "extension.ts")

Probably we also should store the path of the file (relative to the path of the workdir). Because some projects have several files with an identical name, so they couldn’t be distinguished with only the name.
Example folder structure for such a scenario:
- workdir/
- - index.html
- - about/
- - - index.html
- - installation/
- - - index.html
- - contact
- - - index.html

So ./about/index.html or something like that would be nice to have.

#8

Aha, but yeah it’s probably excessive.

Hm, alright.
Still though many editors does not support this and even if they did some might call a language “python” while another editor calls them “python3.6” or even just “py” so we would have to make a mapping for each editor watcher so that would be a huge hassle. Still though, your point still stands so I’m not really sure what the best way is.

Good point, not sure how to best do this though since you can in most editors open files in a project which are not inside the project folder. For example if the file is in ../other_folder/file.txt it might not be a huge issue, but if it’s somewhere completely else such as residing in /media/networkshare/folder/file.txt but the project being in your home folder this might not work well.
Maybe it’s better to just simply store the absolute path instead? Keep in mind that this is only what we are going to store in the DB, how we display it we can make completely different later on with an AW query and can for example display the path as relative when inside the project folder but absolute otherwise so it’s easier to read.

#9

Just found a way to get the language name in aw-watcher-vim aswell after some digging, will implement later.

#10

Alright, I’ve gotten aw-watcher-vim up to speed now and I think this might be the best format

language: “typescript” // just the name of the language
project: "/home/user/Programming/project” // The full path to the project, if we only want the name we can fix that in queries later
file: “/home/user/Programming/project/src/file.ts” // The full path to the file, if we only want the name we can fix that in queries later

What do you think?

#11

Seems good to me :+1:

#12

aw-webui progress :slight_smile:

language statistics

1 Like
#13

Feel free to test out