Just now, something very odd happened (I'm not sure whether it was with 1.2.2
final or with b2): I had a restbreak prelude, but continued working. wr beeped
at me, and almost immediately showed another restbreak prelude.

Maybe my pause was advanced because I had a due micropause, and then later I got
the real thing? I don't know. Whichever way, this should not be happening :-)

I have seen this regularly during testing. I had my time-before-break very low,
for both the daily limit and micropause (low, as in 15secs). I often got a MP
prelude followed by a DL prelude...

How about this one:
- prelude appears.. which I obey
- MP appears, counts-down as usual, until at T=0:13...
- prelude for daily limit appears, followed by
- daily limit window

Looks cool.

Uh.. This is the current behaviour. However, its unlikely this will happen for
MP and RB. The RB timer is stopped when taking a MP (only the DL timer is not
stopped if 'regard MP as activity' is on). So you wil never get a RB during a MP.

This "break advancing" stuff makes sure that *after* a MP, you can work for at
least 1 minute before you get a RB. So, if your MP timer reached 0, you will get
a RB is the RB timer is < 1 minute. If you ignore this RB, you will get the real
RB somewhat later (where somewhat might be way less than the snooze time). I
guess the break should be manually snoozed when it is advanced.

Uh... I think I'm a bit confused when you say "Manually snoozed". I never get to
see the break window, so I can't manually snooze the timer. I agree with you,
however, that the timer should be snoozed in this case, but automatically.
Basically pretty much the same way it would be snoozed when the break was not
advanced and I would be overdue.

If I understand your description correctly, it is possible to be allowed to work
only 30 seconds between a MP or RB and a daily limit (daily limit is at most 1
minute advanced, MP duration 30 seconds, MP considered activity).

This is a bit short, I think. Maybe the time a break is advanced should depend
on the pause duration or postpone times of the breaks involved, instead of being
fixed at one minute. 

Come to think of it, I would not be happy if my daily limit were advanced by a
significant amount. Maybe it's better to postpone breaks, instead of advancing
them. Proposal for you to think about: If break x is due, then I recommend
postponing break x if break y is due within the configured postpone time of x.
The time that x is postponed should preferably equal the remaining time of y,
not xs actual postpone time.

Manually is not the right word... I meant manually by workrave, instead of
automatically by the Timer. The timer only snoozes automatically when the limit
is reached. So when a break is advanced, workrave (i.e. GUIControl) has to
snooze the timer.

At the moment, only a RB is advanced, I think. 

>If break x is due, then I recommend postponing break x if break y is due within
>the configured postpone time of x. 

Do you want to postpone x? Or just skip it (because postponing break x would
cause x to overlap with y)?

>The time that x is postponed should preferably equal the remaining time of y,
>not xs actual postpone time.

Uhh. So both breaks start at exactly the same time and thus overlap? I think
this is more or less the current behaviour, except for the fixed "within" time.

I fixed the original bug: When an advanced RB is postponed or ignored, Workrave
will wait "postpone time" until the next prompt. It will no longer prompt when
the timer reached 0.

In absense of further comments: closing.

Ah... Timeouts again... They tend to trick me every time :-)

I did do some thinking on this, though. In general, I feel that breaks should
not be postponed, daily limits should not be advanced, and breaks should not be
too quickly behind eachother.

Assuming this bug is fixed (didn't verify yet), I think current behaviour is not
too annoying. The only time you risk receiving breaks shortly behind eachother
is at your daily limit, which should be at most once a day. (On the other hand,
if I postpone my daily limit, I'm so busy I tend to get annoyed real quickly :-)

There are two alternative approaches I've come up with, neither of which is pretty.

First approach is described in my earlier comment: If x is due, and y is due
within the postpone time of x, then postpone x.

Second approach: The only time you'll ever get a break is when a micropause is
due. Which break you'll get depends on which other breaks are also due.

I do not have a strong preference.