Currently the postpone time is active time. Postpone is typically used to 
quickly finish something just before the break. Usually this won't lead to 
exactly the specified amount of activity. If you do stop working after you have 
finished your work, the rest break window won't appear and you don't know 
you're in a forced rest break.

In 0.3.0 postpone time IS clock time. in CVS postpone time is active time (see
bug #123)

Postpone time is used for 
- "natural snoozing": When you ignore a prelude window, Workrave will remind you
again after postpone time
- "postpone snoozing": When you click the "postpone" button, Workrave will
remind you again after postpone time.

If clock time is used, you will get a break window when you are idle after
ignoring a prelude window. However, you will NOT get a break window when you are
idle and not yet overdue. This is not consistent. 

I propose using active time and adding a new feature: "Show break window when
taking a natural break after x seconds". Alternatively, use active time for
"natural snoozing" and clock time for "postpone snoozing".

Comments welcome!

A)
> I propose using active time and adding a new feature: "Show break window when
> taking a natural break after x seconds". 

B)
> Alternatively, use active time for "natural snoozing" and clock time for 
> "postpone snoozing".

Ad A): 
- will there be a prelude before the break window? 
- What happens when the user becomes active just before the break window appears? 
- What happens when you continue typing and effectively ignore the break, will
that count as an ignored break? Probably not because it was a natural break.
- But, how does a user tell the difference?
- Why specify x in seconds, and not as a percentage of the break duration?
- And how are we going to explain all of this to ordinary users?
I could go on here...

I really think A) is becoming needlessly complicated. Sure, you could put this
all in the prefs, but my bet is that 95% of all users will not touch the
defaults because. So what reason is there to make this configurable, besides our
own compulsive search for consistency?

B) vote++.

> - will there be a prelude before the break window? 

Probably. That requires the least changes.

> - What happens when the user becomes active just before the break window appears? 

Then the snoozing is terminated and no window will appear. Just as it is done now.

> - What happens when you continue typing and effectively ignore the break, will
that count as an ignored break? Probably not because it was a natural break.

Then there is no difference between active and clock time. So it doesn't matter
what workrave internally uses for snoozing. I think it will count as an ignored
break, asumming you continue typing during a prelude window until it disappears.

> - But, how does a user tell the difference?

She doesn't.

> - Why specify x in seconds, and not as a percentage of the break duration?

Whatever. 

> - And how are we going to explain all of this to ordinary users?

A checkbox saying "Show break window during natural break".

> I could go on here...

BTW, I also vote for B. (Mainly because it only requires setting a variable to
true/false at the right moment...)

Antivote!

Back in Bug #123 I was arguing to use active time instead of clock time for both
natural and postpone snoozing (there's not really a difference, from my
perspective), saying something like

> Anyway... What typically happens is that I want to postpone my
> restbeak, while still sticking to the micropauses. With the current
> implementation, a restbreak window may pop up right after my
> micropause window. This is very annoying. The disappearing of the
> micropause window suggests that I'm allowed to work, but alas, no-go.
> 
> A possible solution to this is to postpone on five minutes active time,
> instead of clock time. This would also feel more natural, because
> everything else in wr is based on active or idle time, not clock time.

I am sorry, but 1.0.0 has already been tagged, zipped and uploaded, so this is
too late.

But, apart from that, we need more than an antivote. I would like to see my
questions answered. Specifically, what do you propose exactly, and how do you
ensure that users understand what you are proposing?

To reply to some of Rob's comments:

> > - Why specify x in seconds, and not as a percentage of the break duration?
> Whatever. 

While we are at it, make that percentage a non-configurable constant. Sounds
logical to me, if I am at 10% (or something like that) of a natural break, popup
the window... I really don't see why you would want to pollute the preferences
with an extra input field for this.

> > - What happens when you continue typing and effectively ignore the break,
> >  will that count as an ignored break? Probably not because it was a natural
> > break.

>  I think it will count as an ignored
> break, asumming you continue typing during a prelude window until it 
> disappears.

Isn't this wrong. The user gets fined for ignoring a natural break?

> > - And how are we going to explain all of this to ordinary users?
> A checkbox saying "Show break window during natural break".

This, I like.

Kees-Jan said:
> Anyway... What typically happens is that I want to postpone my
> restbeak, while still sticking to the micropauses. With the current
> implementation, a restbreak window may pop up right after my
> micropause window. This is very annoying. The disappearing of the
> micropause window suggests that I'm allowed to work, but alas, no-go.

Using active time does not solve this problem entirely. It is very well possible
that right after you become active after a micropause, you have enough active
time to trigger a new restbreak window. As said, workrave solves this problem by
skipping a micropause and starting a restbreak instead if the restbreak would
appear within 30s after the end of the micropause.

In the near future (after 1.0.0), I want the "show break window during natural
break" option. Some problems:
- Give user visual feedback that he is taking a natural break instead of a
"normal" break. Probably a new window "natural break in progress" with a
progress bar ??.
- Always allow skip for natural break.
- postponing a nataral break doesn't make sense.
- Don't insist. Remove window as soon as user becomes active ?
- Statistics for these break are different then for normal break (don't increase
ignore breaks counter when the user skips a natural break window).

Raymond said:
> While we are at it, make that percentage a non-configurable constant. Sounds
> logical to me, if I am at 10% (or something like that) of a natural break,
> popup the window... I really don't see why you would want to pollute the
> preferences with an extra input field for this.

with a MP of 30s, you want a break window after 3 idle time? (Ok, 8s with the
activity monitor delay). 

> with a MP of 30s, you want a break window after 3 idle time? (Ok, 8s with the
> activity monitor delay). 

A better question is, what user would want to enable natural break windows
anyway?   

They interfere with other activities, such as thinking and reading a document
onscreen. Given that my MP duration is 0:30, give me any setting that does not
interfere ?

And, how does the program detect that I am taking a natural micro-pause or a
natural rest break? Will the user be confronted with first a natural MP window,
followed by a natural RB window?

Oh joy, I am drinking coffee and my computer keeps popping up windows and
bleeps, disturbing my co-workers ...

I feel this makes no sense at all.
For RB windows, perhaps..

Unless the current behaviour is REALLY annoying, it's not going to change soon....
I will create a new enhancement bug for "show break window during natural
break"