Stop tracking when destroy signal is received (e.g., due to screen lock)

[xai]

Summary
When the screen is locked in a gnome-session, it would be logical that time tracking is stopped as well by the extension. This was also the behavior of the legacy hamster applet/indicator.
Currently, tracking continues.

How to reproduce

1. Start an activity
2. Lock screen
3. Unlock screen again

Observed behavior: hamster is still tracking the activity from before locking the screen
Expected behavior: tracking the activity is stopped by locking the screen

[hedayat]

Thank you for your interest and for the PR. I'll wait to see what others have to say. But this is my opinion:

While I can see that such behavior can be desired in some workflows, it is not always the case. Actually, this is usually not the case for myself, because I don't necessarily use Hamster to track my direct activities with the system, but I track my activity which might also include locking the system and thinking about something for awhile.

So, if such behavior is to be implemented, I suggest it to be optional, and to be disabled by default so that the default behavior is not different from before. And to be honest, I guess the actual feature should be implemented in Hamster itself, with the extension just notify Hamster about the system state if it cannot detect it by itself, and let Hamster decide if tracking should be stopped or not.

I'd say its better for the extension to merely provide gnome shell integration, but not its own features in addition to what Hamster itself provides. This allows such things to be consistently available in any DE.

[xai]

Thanks for considering this issue, @hedayat!

So, if such behavior is to be implemented, I suggest it to be optional, and to be disabled by default so that the default behavior is not different from before.

You are right and I agree about making it optional, as clearly workflows and use cases differ.

Our users, coming from the legacy hamster applications, expect the behavior as stated in the ticket, but sure - default behavior changes over time (especially during a major rewrite) and I sure have no objections about making the legacy behavior an optional one.

And to be honest, I guess the actual feature should be implemented in Hamster itself, with the extension just notify Hamster about the system state if it cannot detect it by itself, and let Hamster decide if tracking should be stopped or not.

I'd say its better for the extension to merely provide gnome shell integration, but not its own features in addition to what Hamster itself provides. This allows such things to be consistently available in any DE.

Sounds very reasonable to me.

I cannot promise a PR for hamster as the current extension patch at least partly fulfills the needs of my employer ("partly" because we do still have an issue with logout/shutdown, gnome-shell does not seem to send the destroy signal anymore in these cases and we need a solution for this as well, so there's that ...).

If you don't mind, I would rephrase the issue + switch my PR to a draft and we could just keep this open and try to work on a solution that aligns more with the design of your project and its current default behavior. I cannot promise to contribute respective PRs for hamster, but I am very interested in helping (we do use hamster in our company for time tracking and also intend to roll out this extension as a replacement for the legacy indicator), and maybe others also have similar demands and can help out here.

Edit: I could not mark my PR as draft, so I edited the title as WIP to make it clear that there is a discussion and that it should not be merged as is.

[hedayat]

Thanks a lot for you contribution and understanding. I hope to see this feature going forward, I'm sure others will find it useful too.

[mwilck]

Hamster used to have support for this in the past. It lost the ability to track screen lock events with 3.0-rc1. See projecthamster/hamster#568.

[johnnyg]

For those that are still interested, I wrote a gnome extension which does exactly this.

[mwilck]

@johnnyg:

That's creative. A rather complex extension to modify the behavior of another extension. :-)

While I still think that hamster itself should deal with these events rather than the extension, I'd be open to take a patch from you that integrates this functionality into hamster-shell-extension (if you're interested in that, of course).

[johnnyg]

@mwilck ha ha yeah the extension is slightly more complicated than need be mainly because I was using it as an excuse to write a gnome extension.
Happy to provide a patch for hamster-shell-extension, the better question is what exactly which functionality you'd like as my extension actually supports multiple scenarios:

• when the user is idle (configurable time)
• when the screen is locked (I'm assuming that you'd at least want this given that this ticket is explicitly for this scenario)
• when the computer is suspended/put to sleep (i.e. closing your laptop lid)
• when the computer is shutdown

[mwilck]

I was using it as an excuse to write a gnome extension.

Wow. I hope you realize what you did. Writing GNOME extensions may be fun, maintaining them is, um, not really fun.

which functionality you'd like

Not sure, can we get these one at a time, and make them configurable? The usefulness of all these depends on individual work habits. I saw that your extension pops up a window showing the last activity, and asking what to do about it. I find that very useful. Personally, about 90% of the time when the screen lock has jumped in I've been idle in the meantime. But sometimes I haven't. So being able to handle the situation on a case-by-case basis would be helpful for me.

I also realize that with these changes, we'd move a substantial part of functionality from hamster into GNOME extension(s). Meaning that users of other desktops won't benefit. But as noted previously, I've basically given up on that.