The help text on activity configuration says something about being active if 
during "activity time" there is no inactivity longer than "noise time". 

With the new semantics of "activity time" (new activity == old activity - 
noise) this is no longer correct

Yes it is.

Old semantics: workrave decides after "activity time" - "noise time" ms that you
are active. (Because after this time, it is no longer possible to be idle for
more than "noise time" ms before "activity time" ms has passed)

New semantics: workrave decides after "activity time" ms that you are active if
you have not been idle for more than "noise time" in that time period. So, it
always takes at least "acitivity time" ms.

But I will check to be sure...

I'm not sure I understand. The text currently reads "The timers are activated 
if, during a time span of 'activity time', there was no inactivity for longer 
than 'noise time'"

Considering the current 'normal' settings (activity = 1s, noise =9s) it is 
impossible to be inactive longer than 'noise time' during 'activity time', 
because 'noise time' is longer. Hence, the timers should be activated 
(presumably on first activity).

This is not current behaviour, so either the text or the code is wrong.

I currently can't think of a better text.

No, this on not the current behaviour. In case 'noise time' > 'activity time',
the timers are activated on time t when there exist an event on time t1 with t1
< t and "activity time" < t - t1 < "noise time"....

Right. But that's not what the help text says.

I guess, every thing was relatively easy to comprehend in the old semantics, 
because then, it was not meaningful to have activity<noise (this would disable 
noise detection)

Then you did an internal optimization, by realising that you could decide what 
to do at t== activity - noise.
Then, you changed to the new semantics, confronting the user with an 
optimization detail, and making things harder to explain.

I guess I propose reverting to the old semantics.

btw. is it still possible to disable noise detection in the new semantics??

I'm lost, so an executive summary. We have 2 solutions:

1) To start the timers, you have to be active for at least "activity threshold"
ms. Being "Active" for a time period means that the delay between 2 consecutive
events (keypresses, mouse moves) in this time period does not exceed "noise
threshold". 

Note: At least 2 events are required before you are "Active". Workrave can't
look in the future, sorry.

Note: If "noise threshold" > "activity threshold" then the delay between 2
events in "activity threshold" ms can never exceed "noise threshold" ms. So at
the second event, you are "Active" (ofcourse, only if the time between the 1st
en 2nd event < "noise threshold")

2) Solution 1) BUT after "activity threshold" - "noise threshold" ms, workrave
already decides that you are active because after that time, the delay cannot
exceed "noise threshold". This could be considered an optimization.

Also note that there is NO difference is functionallity bewteen these 2
solutions. "noise threshold" is the same in both cases. The difference is the
(absolute) time from which on you are considered active. This time is

ad 1) first_non_noise_event_time + "activity threshold"
ad 2) first_non_noise_event_time + "activity threshold" - "noise threshold"

For solution 2, the value of "activity threshold" is IRRELEVANT if its value is
smaller than "noise threshold" (because it will result in a time in the past).
As a result, you will become active on the 2nd event. On the first event
first_non_noise_event_time is set. If the second event comes within "noise
threshold" ms, you are active. the value of "activity threshold" does NOT
matter. Again, just like solution 1.

The original behaviour was 1, then 2, then back to 1. So, what will it be? (It's
only a matter of changing an #if)

Could we try to come up with a preferences "Help" text for both approaches? Then
we can see which of these explanations is easier to understand for an ordinary
user...

Explanation still too complex, but at least correct :-)

Denk nog steeds dat het huidige mechanisme te ingewikkeld is. Nieuw user
interface proposal:

"Please make me 'active' if the time between two user interface events is more
than a:aa (insert your widget here), but less than b:bb"
"Please make me inactive if there are no user interface events for c:cc"

Simpel, en kun je aan iedereen uitleggen.

Je hebt wel een nieuwe semantiek nodig:
active time = a:aa
noise time = b:bb - a:aa
idle time = c:cc

constraint: a:aa < b:bb

I talked to Rob some more.

If we demand that 'active time' < 'noise time', then the explanation can be
simplified to:

"Please make me 'active' if the time between two user interface events is more
than <active time> (insert your widget here), but less than <noise time>"
"Please make me inactive if there are no user interface events for <idle time>"

No new semantics are necessary (sorry, my mistake)

Furthermore, I recommend to everyone not to talk to Rob about the internals of
this, because you'll get a very cryptic story about events not being the same,
reference events, operators without operands and a whole lot more.

I guess that's what happens when you try to formalise something that's
intuitively clear :-)

Kees-Jan, this all sounds wonderful.. but have you ever thought of how the numb
& sluggish settings settings fit into this? It is impossible now to specify a
numb/sluggish setting.

I talked to Rob some more. :)

The proposal by Kees-Jan is incorrect just as all other proposals so far.

Solution: the monitoring prefs are going to be removed

Rob? Agreed.
Raymond? Agreed.
Kees-Jan?

Monitoring configuration is no more amongst us.