3.0-rc1: hamster ignores screen lock events

[mwilck]

Hamster 2.2 would catch screen lock events and stop the current activity. This was a very important feature - without it, users need to remember manually stopping tracking when take a break or otherwise leave the screen. Even if the activation of the screen lock doesn't necessarily mean that activities have stopped, it's very helpful to have the time stamp of the onset of idleness recorded this way, to be able to manually correct activities later.

This regression has been caused by cc96625 ("remove idle.py"). The commit contains no explanation why this important functionality has been removed. My guess is it was because the idle.py code was accessing the deprecated gconf functionality. However,

1. This was only used to calculate backwards from the actual "lock" event towards the time when the desktop last recorded any activity,
2. The gsettings replacement would be lock-delay in /org/gnome/desktop/screensaver.

[mwilck]

Well, there's more:

• 5f2f061 remove stop_on_shutdown preference
• cc96625 remove idle.py
• 08eaf77 remove desktop.py
• 487a46f remove notify_interval preference
• 7e5b687 remove notify_on_idle preference
• 891d33b remove enable_timeout preference
• 0605cb3 disable desktop integration

@ederag, why have you ditched all this functionality? Where's the replacement?

[GeraldJansen]

From #494:

Remove unused external.py or currently nonfunctional stuff (desktop/idle)
that should be moved to a companion project, as discussed in #493.

[mwilck]

#493 talks about the "external" functionality only. #494 provides no insight to me, other than that it claims that "idle" wasn't functional, which is not true, at least not for hamster 2.2.

[mwilck]

To put it differently: if "idle" was broken before #494, it must have been broken by some other changes made after 2.2.2.

[GeraldJansen]

In addition to the considerable insight provided by #493, in my opinion, please keep in mind that Hamster is also used (and developed and tested) in non-Gnome environments. Furthermore, the project is actually pretty short on active testers and contributors from among the Gnome users. Just to voice a contrasting opinion, I for one think that @ederag made the right decision to "ditch" all that external stuff, given the lack of resources. On a positive note, it looks like @sh-zam plans to build an external service to restore some of that functionality.

[mwilck]

In addition to the considerable insight provided by #493,

Sorry, I'm unable to find any insight about idle detection in #493.

in my opinion, please keep in mind that Hamster is also used (and developed and tested) in non-Gnome environments.

Is that a reason to take functionality away from GNOME users? I believe the idle functionality could have been extended to non-GNOME environments quite easily, at least if these environments provided DBus signals for the screen saver kicking in, like GNOME does.

Just to voice a contrasting opinion, I for one think that @ederag made the right decision to "ditch" all that external stuff, given the lack of resources.

You don't care about loosing functionality you have never used. Understandable. You did seem to care about the XFCE plugin's functionality, didn't you? I bet you'd care about idle detection too, if someone had made it work under XFCE in the past.

Of course resources are scarce. But I fail to see what we gained by throwing away this important functionality.

I take it that I should have complained earlier, when this code was ditched, not now at the -RC stage. But I was lacking the resources to follow the development on a daily basis. And I certainly didn't expect anything like this to happen. Perhaps I should have volunteered to fix, or keep alive, the functionality that I'm now missing. Perhaps I will. But I don't think that, for idle detection, it's possible to do it in a separate project like https://github.com/kraiz/hamster-bridge. Hamster will either listen to these signals, or not. It's core functionality.

[ederag]

@GeraldJansen Thanks, it's good to have such a clear backup,
and helps keeping motivation !

@mwilck
Your tone only tend to undermine my motivation, and harms to this project IMO.
You were already asked to be more careful: #549 (comment).
Please keep it short and factual.
We read carefully, and care for all users / distributions.

Just for history: the #493 warning has been out for more than two months now,
and even pinned for more than 45 days.

But I don't think that, for idle detection, it's possible to do it in a separate project like https://github.com/kraiz/hamster-bridge. Hamster will either listen to these signals, or not. It's core functionality.

You gave no reason why it should not work, just that you are scared it could not.
This is not helping at all.

Why an external program such as hamster-bridge could not do this,
since it can incorporate the code that was removed, and stop hamster through dbus ?

[mwilck]

Why an external program such as hamster-bridge could not do this,
since it can incorporate the code that was removed, and stop hamster through dbus ?

Yes, it might be possible. It might even be doable in the Shell extension. I didn't realize that at first. Just needs someone to pick up the pieces and glue them together. So, I guess idle detection in hamster is dead and buried. Sorry for the noise.

I'm also sorry if my postings "undermines your motivation". I've expressed repeatedly that I appreciate your work in general. I just happen to disagree with certain decisions you have made, and to dare to express this opinion. I believe this should be possible in an open source project.

[ederag]

@mwilck Sorry, but my repeated advices do not seem to register:

• Restore edit, remove dialogs #549 (comment)
• Restore edit, remove dialogs #549 (comment)
• Restore edit, remove dialogs #549 (comment)
• Restore edit, remove dialogs #549 (comment)
• Restore edit, remove dialogs #549 (comment)
• 'org.gnome.Hamster.GUI' - strange semantics of window pop-up and persistence #563 (comment)
• 3.0-rc1: hamster ignores screen lock events #568 (comment)

It seems I have to be blunt for the good of this project.
And your last post #568 (comment) accuses me publicly of being unfair,
forcing me to reply publicly as well.
Please note that I'm doing so after closing this thread, as a courtesy.
If you hide your post and say so, I'll hide mine as well (the "off-topic" reason seems appropriate).

It seems that you think you have the right to do what you do,
This is typical of vampires:

I just happen to disagree with certain decisions you have made, and to dare to express this opinion. I believe this should be possible in an open source project.

Except in the past ten days I passed more time reading and thinking how to answer your noise
then coding on this project,
just to repair your damage (would users be attracted to a seemingly mishandled project ?).

Don't get me wrong, I crave for good bug reports and constructive discussions
(there are, happily), but that does not qualify:

• Hasty report: Future of hamster v3.x? #433 (comment)
• Was not hamster: Future of hamster v3.x? #433 (comment)
• Empty window screenshot, no further information: Future of hamster v3.x? #433 (comment)
• Noise: "Add earlier activity" dialog no longer shows up from Shell extension #548 (comment)
• Repeated noise: Restore edit, remove dialogs #549 (comment). That was a patience exercise.
• Huge post, for nothing, and the answer was 20 lines above code you should have read carefully
  (you changed that file just before) and thouroughly searched about before posting: 'org.gnome.Hamster.GUI' - strange semantics of window pop-up and persistence #563
• Challenged my advice ("not quite") Exception against NameHasNoOwner crashes program #566 (comment).
• This whole thread, including the previous comment, 3.0-rc1: hamster ignores screen lock events #568 (comment),
  that showed you still did not understand the gravity of the situation.

Next time you post a comment expressing your opinion that this project does not go in the right direction,
or implying that I do not know what I'm doing,
chances are I'll be even more blunt, sarcastic, unhide posts and link to this one.

I make mistakes sometimes, but let's let someone else spot them.

As a conclusion, please read again the last sentence of #549 (comment), I still mean it.
You could be better to this project by just letting others drive it peacefully.

[mwilck]

Ok @ederag, you've lost a contributor. Thanks for the link collection above, which will enable readers to verify how our little controversy came to pass, how it escalated, and which party contributed to which extent. I'm hoping that people will form their own opinion. I could raise objections to every single point you made above, but it'd be a waste of time for both me and you.

Weird as it sounds, I wish for the sake of this project that my current judgement about its state and directions will be proven wrong.

[ederag]

you've lost a contributor.

@mwilck Understood, but this is sad news as you have made valuable contributions.
If later on you come to an understanding, the door is open.