Associate tasks to specific workspaces and follow changes automatically

[aurelien-naldi]

I added a simple mechanism to save/restore previous tasks and used it to:

• resume tasks which have been interrupted by screen lock
• change the current task upon workspace changes

It still lacks proper setting (and their GUI) but it "works for me" :)

[toupeira]

Please only catch the specific exceptions you expect.

[aurelien-naldi]

As I'm not familiar with dbus, I copied this from idle.py, but all other places in hamster where a session bus is retrieved are unprotected, so I'm taking out the try/except here.

[toupeira]

Thanks for your contribution! To merge this I would definitely like:

• Proper GConf settings, the old workspace_tracking preference supported the values memory (remember activity by workspace, i.e. your behaviour) and name (switch to specific activites as defined in the old workspace_mapping preference). I propose we keep this as a string list but ignore values other than memory for now.
• Disable the new settings by default so the behaviour doesn't change, which also means we don't need to update the preferences UI just yet (though that would be welcome as well of course)
• The save/restore mechanism looks like a good source for obscure bugs, so we should probably make this a bit more reliable and find edge-cases to test

Let me know if you need any pointers.

[aurelien-naldi]

Thanks for your feedback!

I agree on the settings part but I first wanted to know if it had a chance of getting in. I also want to add a "auto resume" setting to the lock screen part.

For the save/restore part, I wanted to start by adding a simple API for it, but indeed the implementation needs to be solid, maybe some additions to the storage object could help: is there a way to reuse the existing fact object to start a new slot? The gnome-shell extension has buttons to restart one of the previous tasks, this code could be shared.

[elbenfreund]

Thank you for your feedback, it is much appreciated.

Project hamster and its various sub-components is currently undergoing some major changes. We prepare the introduction of a rewritten codebase for most of the underlying functionality. A direct consequence of this is that it is unlikely that any open/new bugs within the current/old codebase will be fixed (unless someone steps up and offers to do so) as most resources currently available will be invested in making the rewrite prime time ready.

If you are still interested in working on the new codebase (repositories: hamster-lib/cli/gtk/dbus) we would be most thrilled. Please feel free to either open a new issue with the relevant repository and/or join the discussion on the mailinglist.
For more context please see our website.

Thanks for your interest and support! Eric.

[GeraldJansen]

Considering #470, #493 and #494, this PR should probably be closed.

[mwilck]

Considering #470, #493 and #494, this PR should probably be closed.

Yes, in view of #494, this isn't going to be implemented any time soon. We'd need to get the desktop integration back first.

But that doesn't mean it's not a good idea.
Do we have an option to save this as possible feature / future work?

[GeraldJansen]

Do we have an option to save this as possible feature / future work?

Aside from leaving it open, another option would be to open a new feature request issue in whatever project/fork undertakes reviving desktop integration and linking back here. AFAIK closed requests don't disappear, they are just less visible.

[mwilck]

AFAIK closed requests don't disappear, they are just less visible.

You might as well say "invisible". Who scans closed issues? We should differentiate between "will never implement" and "won't implement just now".

[matthijskooijman]

W00ps, i was a little overzealous in cleanup @ederag's comment. Turns out it still relevant, since there is a "Pending check" for CLA that can probably never realized. Here's the deleted comment:

There will never be any CLA on this code. Please disregard the wrong checks (#589).

Sorry for the noise.