several feature suggestion
Oren Gampel
oren at orengampel.com
Sun Dec 29 22:10:34 CET 2013
Hi Joachim,
Thanks for the prompt reply, and changes! I'll try to answer inline, and
adding another feature request at the bottom.
On Sun, 29 Dec 2013 16:25:45 +0100, Joachim Breitner wrote:
> Dear Oren,
>
> nice to hear that you can make good use of arbtt. I’m always interested
> in user reports, especially if you actually found out something
> interesting with it. If you write such a report somewhere (blog,
> Google+, etc.), let us know here!
>
> Am Samstag, den 28.12.2013, 12:07 +0200 schrieb Oren Gampel:
>
>
>> 1) --local-z flag for arbtt-dump that will print each TimeLogEntry at
>> the local timezone
>
> arbtt-dump is mostly meant for debugging and integration, not so much
> for human consumption. But since you are using it that way, there might
> be a different feature lacking elsewhere. When and why are you looking
> at the output of arbtt-dump?
Well, since I've debugged some rules in the configuration, I used the
dump to understand/debug what's going on. I admit that it's not critical,
but since...
>
> Anyways, I implemented the feature, check out the development repository
> if you want to try it (which would be appreciated).
... you already implemented it, I can only say thanks :)
I haven't tried the dev version yet. Not even sure I got Haskell
installed, but I'll try to set it up and will let you know.
>
>> 2) Workspace logging. I've seen it implemented in other time trackers,
>> although I have no idea how difficult it is to implement it for the
>> different environments.
>> I'm using KDA with Plasma Desktop. I get
>> (True,"plasma-desktop","plasma-desktop") entries but since there is no
>> desktop number or name there is not much analysys that can be done.
>> Using different workspaces for different tasks is extremely common
>> in multiple workspace/desktop environments and can add very good basis
>> for analysing time usage.
>> Since I only saw few (True,"plasma-desktop","plasma-desktop") and much
>> more (False,"plasma-desktop","Plasma"), I suspect the true entry is
>> logged only when the workspace switch is happening, although I'm not
>> sure.
>
> So the problem is that the plasma-desktop is showing up as the active
> window? Does it then even log actual windows as active?
>
> Does "wmctrl -l" print anything useful about workspaces? In particular
> the second column?
>
I've used "wmctrl -l" and the result shows 11 "plasma-desktop" as window
titles. I have 5 desktops, each spans two screens so I guess there is 1
+2*desktop windows. So this doesn't help, but:
"wmctrl -d" shows all the desktops, their correct names, *and* points to
the active one:
oren at black:~$ wmctrl -d
0 - DG: 2960x1050 VP: 0,0 WA: 0,0 2960x1000 Main
1 * DG: 2960x1050 VP: 0,0 WA: 0,0 2960x1000 Android dev
2 - DG: 2960x1050 VP: 0,0 WA: 0,0 2960x1000 Kids
3 - DG: 2960x1050 VP: 0,0 WA: 0,0 2960x1000 Project X
4 - DG: 2960x1050 VP: 0,0 WA: 0,0 2960x1000 Project Y
with a single asterisk marking the current desktop.(!)
I'm really hopping this can lead to implementing a desktop-related entry
in the log. It would be extremely helpful!
>> 3) --list-titles flag for arbtt-stats that will show for specified tag
>> all the titles it has. I often find myself "debugging" by adding ...:
>> $current.title just to see all the titles and this feature would be
>> easier than changing the cfg every time.
>
> Not quite sure I can follow. You want to know, for samples with a
> certain tags (remember that tags are applied to samples, i.e. points in
> time, and not to individual windows), what the title is – the title of
> what? Of the current window?
>
> In that case, can’t you just permanently add
> tag Current-Title:$current.title,
> to your config and query it, for example, using
> arbtt-stats --only 'Editing-Haskell' --category Current-Title
> ?
Exactly. That was what I used - adding tag Current-Title:$current.title
to see the list of titles, and then change the rules accordingly, and
than comment out the "debug" tag. A --list-titles flag for a tag would
save me from using this debug technique.
While I'm at it, I would like to ask for another feature that might be
useful to others:
4) Add a --ignore-minor-breaks=Seconds [very bad flag name] to arbtt-
stats.
For example, review the following output of:
"arbtt-stats --intervals=Writer" where Writer is a tag I gave my
LibreOffice Writer activity.
Writer | 12/24/13 09:26:12 | 12/24/13 09:42:58 | 17m01s
Writer | 12/24/13 09:43:28 | 12/24/13 09:45:58 | 2m45s
Writer | 12/24/13 09:48:14 | 12/24/13 09:54:44 | 6m45s
Writer | 12/24/13 09:55:29 | 12/24/13 09:55:29 | 15s
Writer | 12/24/13 09:55:59 | 12/24/13 09:56:45 | 1m01s
Writer | 12/24/13 09:57:45 | 12/24/13 09:57:45 | 15s
Writer | 12/24/13 09:58:30 | 12/24/13 09:58:30 | 15s
Writer | 12/24/13 09:59:15 | 12/24/13 10:00:45 | 1m45s
Writer | 12/24/13 10:02:45 | 12/24/13 10:02:45 | 15s
Writer | 12/24/13 10:03:15 | 12/24/13 10:07:45 | 4m45s
It's pretty clear that I spend all of this time on my authoring activity,
with minor interruptions for thinking/browsing the web/etc.
With a flag that would specify amount of SECONDS to ignore, I could let
two consecutive entries to be joint to a single long one if the
interruption between them is less then SECONDS. So for 60 seconds ignore
flag
Writer | 12/24/13 09:48:14 | 12/24/13 09:54:44 | 6m45s
Writer | 12/24/13 09:55:29 | 12/24/13 09:55:29 | 15s
would become
Writer | 12/24/13 09:48:14 | 12/24/13 09:55:29 | 7m45s
i.e the total would be the sum of both intervals + the interruption time
betweens them.
Another option is setting the interval as a multiplier of the --sample-
rate. In that case I would even consider a default of *2 multiplier as a
standard interruption ignore time.
I admit that I'm using a 15 sec --sample-rate, which might be short, but
there are other things I do that actually need this granularity. On the
other hand, for specific tasks, I would like to ignore short breaks of a
minute or two. For authoring a technical paper for example, that needs
constant dealing with other tools, reading other articles, browsing the
web etc, this can be significant.
Oren
More information about the arbtt
mailing list