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