Created attachment 110720 [details] [review]
Proposed patch

Simple dbus support - sends a message on break activation and completion.

spam

I don't think this is a good idea. If we create custom signals for all applications that might have some sort of "user is away" awareness, those said instant messengers would have look after an entire zoo. Maybe we could reuse existing standardized signals like what the screensavers use? At the very least we should create a generic away signal rather than a number of app-specific ones.

That makes sense, I'll look around for a more generic form already in use. I'm a newb so point me in the right direction if you know a good place to look.

In general, being more generic and avoiding a dbus "zoo" are virtues.  However, taking a typing break is semantically a very unique state - I think it cannot and should not be shoehorned into a more generic "away" notification, like for a screensaver.

A screensaver kicks in when the user is simply idle, i.e.: they've walked away from the machine/aren't paying attention to it.  However, the typing break just *pops up* to the user.  They don't initiate the event; it's something that happens *to* them.

A typing break appearing is not a generic "away" state, but a special type of "be right back" state, and should thus be handled specially.

(In reply to comment #5)
> A screensaver kicks in when the user is simply idle, i.e.: they've walked away
> from the machine/aren't paying attention to it.  However, the typing break just
> *pops up* to the user.  They don't initiate the event; it's something that
> happens *to* them.

I agree that it shouldn't use the same ones as the screensaver, and I never requested that. I only said to look for similar signals that might already exist and could be reused. Assuming that the result of all that looking is "none found", creating a new one for typing break is a valid option.

If we do create that signal, what should it look like? The one Ben used in his patch looks a bit suboptimal to me. We have the signal type, plus a fixed string that is basically the same as the signal type. Is that useful? Shouldn't the message be at least something that could potentially be shown to a user, somewhere along the lines of: "Typing break started, will regularly end in x minutes."? That would also have to be translatable, of course. In its current form, the msg parameter looks redundant to me.

(Aside from that there are a few minor quibbles like inconsistent indentation (tabs vs. spaces), terminology ("Break ended" sounds so much better than "Break done"...), and I think the first dbus_notify call isn't placed correctly, but I haven't checked too closely.)

(In reply to comment #6)
> (In reply to comment #5)
> I agree that it shouldn't use the same ones as the screensaver, and I never
> requested that. I only said to look for similar signals that might already
> exist and could be reused. Assuming that the result of all that looking is
> "none found", creating a new one for typing break is a valid option.

Ah, ok.  I opened all my installed desktop applications (hooray for 4GB RAM!), and using d-feet, I looked through the current signals being offered through d-bus on my system.  (I have a pretty typical but heavily-loaded GNOME 2.24 desktop).  I found nothing semantically similar currently in place.

> If we do create that signal, what should it look like? The one Ben used in his
> patch looks a bit suboptimal to me. We have the signal type, plus a fixed
> string that is basically the same as the signal type. Is that useful? Shouldn't
> the message be at least something that could potentially be shown to a user,

Agreed, the current signals aren't quite right.

At most, there could be the following signals:
BreakStartingIn(UInt16 minutes) - minutes: number of minutes until a break begins
BreakStarted(UInt16 minutes) - minutes: duration of break
BreakEnded() - bare signal, no message needed
BreakPostponed() - bare signal, no message needed

I don't think any user-exposed strings should be set here - I think that should be left up to the applications that want to listen for the signals.  The apps are what the user is interacting with, so they are in the best position to decide what they want to do with the information.

Does the difference between BreakEnded and BreakPostponed matter?

(In reply to comment #8)
> Does the difference between BreakEnded and BreakPostponed matter?
> 

Not from the standpoint of most apps.  I included a BreakPostponed signal for the sake of completeness and that one might want to trigger some other action based on skipping/postponing a break.  (Like for myself, I might want to have a program tally up the number of breaks I've skipped - naughty! - and record them somewhere, or perhaps run some program or pop up a message, etc.)

In fact, now that I think about it, the following might be better:

BreakStartingIn(UInt16 minutes)
BreakStarted(UInt16 minutes)
BreakEnded(String message) - message: "Expired" or "Postponed" - Expired if it ran its course normally, Postponed if the "postpone break" button was hit"

Mass move to DrWright module. The code has been removed from the control-center, and put back in the drwright module as its interaction with the GNOME 3.x experience was not defined.

See http://git.gnome.org/browse/drwright

DrWright is not under active development anymore, has not seen code changes for about five years, and saw its last tarball release in the year 2012.
Its codebase has been archived: https://gitlab.gnome.org/Archive/drwright/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.