Hi.

I have set the number of prompts for rest breaks to 3, and yet, I seem to be
able to postpone my rest break as many times as I want. It is the same for
micro-pauses. Setting the maximum to say 1 doesn't force me to take the break
after the first prompt.

Basically, it seems that the maximum number of prompts is ignored, even though I
 have "force break" when maximum number of prompts is reached.

Regards,

Hugo

ah... that's a feature :-)

Indeed. You can click the postpone button as many times as you want, each time
postponing the break.

You may have noticed that if a prompt appears, and you continue working the
prompt goes away again. This is what the number of prompts setting is about: if
you set it to three, then the prompt will go away two times, but not the third.
The third time, a break window will be shown (in which you can manually click
postpone).

So, if I understand you correctly, then the behaviour you described is as
intended, though admittedly a bit odd.

I see.

Then, can I request this feature to be implemented?

I would like Workrave to force me to have a break, even if I keep pressing the
postpone button.

Maybe the number of prompts counter should be increased when the postpone button
is pressed.

Regards,

Hugo

Thinking about this feature a bit more, I think that it could be implemented two
ways:
- enforce a maximum number of times that one can postpone a break; this counter
would be incremented both when a prompt disappears because the user hasn't
stopped typing and when the user pushes the postpone button;
- enforce a maximum delaying time: if a break is overdue by more than x minutes,
then force the user to take his or her break.

Regards,

Hugo

Since I am finding myself postponing my breaks more and more, I started having a
look at this from the angle of changing the code as little as possible.

In BreakControl, final_prelude indicates that the maximum number of preludes has
been reached. I thought that this could be used as a signal that the break
cannot be postponed anymore, since, IIUC, everytime the user is asked to take a
break, prelude_count is increased.

So I was wondering if a sensible way to go with this would be to add, under the
STAGE_TAKING case in BreakControl::heartbeat(), the following:

        // Final prelude: the break cannot be ignored anymore
	if (final_prelude) {
	  set_ignorable_break(false);
	}

I haven't managed to test it yet as I am getting a weird segmentation fault in
TimeBar::set_progress() that I can't understand at this point, but wanted to at
least record that, since I have to give up on it for a little while.

Created attachment 29
Core modifications to limit number of preludes & postponing

I have a patch which implements the limitation I was talking about. It seems to
be working.

What is missing at this point is the configuration part, as I got last in
TimerPreferencesPanel.cc...

I have been trying to add some code to the configuration panel in addition with
the patch I posted yesterday, but I keep getting some weird segmentation faults
when adding a Gtk::Adjustment. It must be a stupid mistake, but I just don't see it.

The following makes workrave segfault when bringing up the preference panel:

diff -ur workrave-1.4.1-worky/src/app/gtkmm/TimerPreferencesPanel.cc
workrave-1.4.1-complete-attempt2/src/app/gtkmm/TimerPreferencesPanel.cc
--- workrave-1.4.1-worky/src/app/gtkmm/TimerPreferencesPanel.cc 2003-10-20
14:52:10.000000000 -0400
+++ workrave-1.4.1-complete-attempt2/src/app/gtkmm/TimerPreferencesPanel.cc    
2003-12-14 11:20:52.000000000 -0500
@@ -44,6 +44,7 @@
 
 TimerPreferencesPanel::TimerPreferencesPanel(BreakId
t,Glib::RefPtr<Gtk::SizeGroup> size_group)
   : Gtk::VBox(false, 6),
+    force_break_limit_adjustment(0, 2, 100),
     max_prelude_adjustment(0, 1, 100)
 #ifdef HAVE_EXERCISES
   ,exercises_adjustment(0, 0, 10)
diff -ur workrave-1.4.1-worky/src/app/gtkmm/TimerPreferencesPanel.hh
workrave-1.4.1-complete-attempt2/src/app/gtkmm/TimerPreferencesPanel.hh
--- workrave-1.4.1-worky/src/app/gtkmm/TimerPreferencesPanel.hh 2003-10-20
14:52:10.000000000 -0400
+++ workrave-1.4.1-complete-attempt2/src/app/gtkmm/TimerPreferencesPanel.hh    
2003-12-14 11:19:37.000000000 -0500
@@ -73,6 +73,7 @@
   BreakInterface *break_data;
 
   Gtk::CheckButton *ignorable_cb;
+  Gtk::Adjustment force_break_limit_adjustment;
   Gtk::CheckButton *monitor_cb;
   Gtk::CheckButton *prelude_cb;
   Gtk::CheckButton *has_max_prelude_cb;

I am afraid that I am going to give up, at least for now. Any help with this
part appreciated.

Basically, the functionnality of the patch I provided is the following: after
being asked for more than n times to take a break, the postpone and skip buttons
are hidden in order to force the user to take a break. This is independent from
prelude_count and final_prelude.

I was going to add a configuration option similar to the one about the preludes
for it, but I am struggling with it.

Regards,

Hugo

Thanks for the patch. I just had a very quick look at it. Some small remarks:

- It seems that the postpone/skip buttons are removed after a configured number
of prelude windows are shown. For example: If 'max_number_of_preludes' is set to
3 and you ignore 3 prelude windows before taking the break, you will not get a
postpone button. If you ignore the prelude window twice, you can postpone the
break window once. Is this intentional? In other words, 'max_number_of_preludes'
represents the maximum number of times you can postpone or ignore a break (not
only postpone)

- I would rename 'max_number_of_preludes' to
'max_number_of_postponable_preludes' or something. The existing
'number_of_prelude' chould then be renamed to 'max_number_of_preludes'

- It seems that Core.cc always calls stop_break with 'forced_stop' == false.
Perhaps hide the extra parameter from Core.cc (by giving it a default value)

About the Adjustment. No idea why it crashes. Perhaps a problem with your
dependencies. Did you try a make clean ?

I also tend to postpone break way too often. So, I think this is a good idea.
However, it means adding yet another configuration option. We don't want
workrave to become overly complex. Comment? Raymond :-)

I finally found the problem. The makefiles are lacking dependencies of the .cc's
on the .hh's, so not everything needed was being rebuilt. I will open another
bug report about that.

Anyway, I have a working patch, with the configuration panel changed. I have
integrated your suggestions.

Note that you can disregard my attachment from 2003-12-13.

Created attachment 30
Patch implementing max_number_of_postponable_preludes: complete patch, including modification of break control and preference panel

Hi,

I've been trying to understand what's being proposed here, but I'm not sure I'm
succeeding.

Anyway, it looks like the proposal is to have two configuration options. One for
the maximum number of preludes that can be ignored, and one for the number of
times one can click postpone. Though if I understand correctly, in the current
patches there is only one option, for the number of preludes that can be ignored
and the number of times one can click postpone combined. (How did I do so far?? :-)

The underlying problem seems to be users clicking postpone too often. Though the
arguments in favour of this new option are very legitimate, there is a trade-off
to be made here. Originally, the postpone button was added as a feature, to
avoid wr from being overly intrusive. And now the discussion goes like "Nice
feature, but I don't want to be able to hit postpone too often". Next someone
will step up claiming "I really like being able to click postpone only two
times, but in circumstance such and such (boss looking over shoulder or
somesuch) I want a super-postpone to postpone anyway".

If you follow this line of reasoning (which is, admittedly and intentionally, a
bit absurd) you would be making workrave completely responsible for your break
schedule. From a RSI-prevention point of view, this is undesirable. It's your
body, so you take care of it and break in time. Workrave is your friendly guide
giving some good advise now and then, but it is your responsibility to follow
the advice. Workrave can't possibly do that for you.

So if you find yourself clicking postpone too often, then maybe you should just
stop doing that. Work a day or to without the skip and postpone buttons being
visible at all to get used to that. If you then feel wr prompts for breaks too
often, then maybe you should relax your break schedule.

Anyway, there is a point at which you can no longer provide technical solutions,
and you (as a user) have to take responsibility yourself. I'm not saying this
one configuration option is beyond that point, though it would be a good
candidate :-)

Just my 2 cents

Kees-Jan

> I've been trying to understand what's being proposed here, but I'm not sure I'm
> succeeding.

In a nutshell: have the possibility of limiting the number of times
a break is ignored or postponed.

> Anyway, it looks like the proposal is to have two configuration options. One for
> the maximum number of preludes that can be ignored, and one for the number of
> times one can click postpone. Though if I understand correctly, in the current
> patches there is only one option, for the number of preludes that can be ignored
> and the number of times one can click postpone combined. (How did I do so
far?? :-)

I originally wanted to monitor the number of times the postpone button
had been pushed. However, I came to realize that, since preludes can be
ignored and the window doesn't appear, limiting the number of times a
user is asked, i.e. counting preludes and not resetting this count when
the postpone button is pushed, was probably a better solution.

Now that I am writing this, I realize that my patch may depend on whether
the user uses preludes, which wasn't the intent. That may need to be fixed.

> The underlying problem seems to be users clicking postpone too often. Though the
> arguments in favour of this new option are very legitimate, there is a trade-off
> to be made here. Originally, the postpone button was added as a feature, to
> avoid wr from being overly intrusive. And now the discussion goes like "Nice
> feature, but I don't want to be able to hit postpone too often". Next someone
> will step up claiming "I really like being able to click postpone only two
> times, but in circumstance such and such (boss looking over shoulder or
> somesuch) I want a super-postpone to postpone anyway".
> 
> If you follow this line of reasoning (which is, admittedly and intentionally, a
> bit absurd) you would be making workrave completely responsible for your break
> schedule. From a RSI-prevention point of view, this is undesirable. It's your
> body, so you take care of it and break in time. Workrave is your friendly guide
> giving some good advise now and then, but it is your responsibility to follow
> the advice. Workrave can't possibly do that for you.
> 
> So if you find yourself clicking postpone too often, then maybe you should just
> stop doing that. Work a day or to without the skip and postpone buttons being
> visible at all to get used to that. If you then feel wr prompts for breaks too
> often, then maybe you should relax your break schedule.
> 
> Anyway, there is a point at which you can no longer provide technical solutions,
> and you (as a user) have to take responsibility yourself. I'm not saying this
> one configuration option is beyond that point, though it would be a good
> candidate :-)

This is a good point, though easier said than done: I think that a
number of people with RSI have such a condition because they tend to
do things such as not take breaks when needed. And sometimes, the time
of a break is inconvenient. The point of my proposal was to say "yes,
the time of a break can be inconvenient, but after postponing it x
times, you really need to take it". I think workrave can help people
(including me) to do so.

I'd be happy to tweak my patch so that workrave maintainers would feel
it does something useful.

And if you feel that it's a feature that you don't want, I can always
use my own version.

Regards,

Hugo