Future of hamster v3.x?

[GeraldJansen]

This issue is intended for discussion of the future of the upcoming maintenance versions (v3.0, v3.1, etc.) of the "legacy" hamster time tracker.

IIUC, the main purpose of this effort is to get the gtk3+python3 version of legacy hamster back into shape as a reliable tool which can be easily installed as a system application on recent versions of mainstream linux distributions. Presumably v3.0 would be a candidate for package managers to replace the old hamster-applet packages which have been dropped from recent distributions (cf. #356, #399, #421).

Thanks to the formidable efforts of @ederag, it seems to me that we are in pretty good shape w.r.t. these objectives. Perhaps adequate testing and documentation of changes relative to hamster-applet remain as issues, but the main question is whether there are any package managers still interested in providing and maintaining hamster packages. A Snap package for hamster (#418) could well be a good alternative.

In the meantime, the rewrite as hamster-lib/cli/gtk/dbus is still advertised as being the main thrust of future development, in spite of the fact that it seems to be completely stalled for about 2-3 years now. To put it bluntly, it looks lifeless (ie. dead).

Personally, before putting further effort into the project, I would like to know where things are heading.

If there is any hope for reviving the rewrite, my preference would be to try to join that effort (with some modest contributions). Otherwise the v3.x line should be re-branded as the main thrust and some issues/enhancements currently assigned to hamster-gtk should be reassigned to v3.1, v3.2 etc. and ... we should drive on. Maybe some of the work from the rewrite could be considered for back-porting. I would be willing to continue with occasional contributions, but as I said, it would be really nice to know where the project is heading (if anywhere).

[ederag]

There is an interest for a debian package (#252), and @mwilck is packaging for openSUSE.

It would be good to hear from the rewrite devs.

The rewrite is still a good idea, especially as a base for new features,
but as time is going by the legacy code is becoming familiar,
and its maintainability increases.
It could be the stable version for the years to come,
even if the rewrite goes forward again.

[hedayat]

Well, as there is no manpower for it, I agree that the rewrite effort is dead. And, even if it revives again, it can (and actually does!) have a different name (hamster-cli/gtk/...?).

Anyway, IMHO, the idea of a 'very stable old branch' and a 'rewrite branch' doesn't work here. I'd suggest doing small (as much as possible) refactorings inside the current code which are regularly merged with the main branch rather than going for a full rewrite; which, I don't think will happen in this project.

And about packaging; hamster (2.0) is in Fedora repos up until Fedora 30, and is dropped from F31. As I see, hamster is ported to python 3 (python 2 packages are being removed from Fedora), so I'll probably start packaging the latest version and maintain it.

[GeraldJansen]

Great news about new packaging for Fedora! It would be super if this can be based on the imminent hamster v3.0 release.

[hedayat]

Great news about new packaging for Fedora! It would be super if this can be based on the imminent hamster v3.0 release.

Sure. I'm pretty busy so it'll take some time for me to package it up and re-introduce it to repos. So, I'll certainly wait for v3.0 release.

P.S. unfortunately, the gnome shell extension is again incompatible with the latest version of gnome shell... It'd be great if this app can be usable independent from that extension. e.g. probably having shortcuts for starting/stopping activities at least.

[ederag]

@hedayat

[...] small (as much as possible) refactorings [...]

That's exactly our approach.

The rewrite (hamster-*) is well advanced,
it has stalled for a while, but that might change any time, it's hard to predict.
My intention here is to ensure continuity, maybe for a long time.

It'd be great if this app can be usable independent from that extension. e.g. probably having shortcuts for starting/stopping activities at least.

That's also the case, for instance I'm using it on kde without the extension (never worked here).
Since the extension seems important where it works, we strive to keep the dbus interface compatible.
It looks like some versions of the extension indeed work with current hamster: #356 (comment).

Finally, v3.0 should be out in november or december,
but the installation process is hopefully ready for the release,
so it should be possible to prepare packaging whenever you feel like
(thanks !).

[GeraldJansen]

For the sake of completeness, the xfce4-hamster-plugin also works with current master (at least with current XFCE 4.12).

[hedayat]

Note that the gnome shell extension works with hamster, it doesn't work (correctly) with latest gnome shell! specially its master branch doesn't work fine with a number of recent gnome shell versions, but there are forks/PRs to fix it up to Gnome 3.32. For 3.34, there is still no fix, but probably will be fixes for it too. But the master branch seems to be unmaintained...

[GeraldJansen]

Perhaps this is getting off topic, but it should be possible to make a very simple Gnome shell extension with Argos and a Python script. That would require very little maintainance.

[ederag]

Here is a short term roadmap.
Let's take time to polish #461, hopefully in october.
Then another PR is ready (not pushed yet), touching dbus and db code,
that will need a month or so to test.
During november we'll review and converge on @GeraldJansen PRs (good job, thanks !).
If all goes well, we'll release about mid-december.

[GeraldJansen]

I think it would be good if we had an "unstable" (or "testing") branch in addition to the default stable master branch. Pull requests for new features could get merged into that branch more quickly (without seeking near perfection). Hopefully this would make it easier to get more and earlier testing and feedback (okay, I'm probably just dreaming).

[mwilck]

I've had a look at #461 and I'm not sure that this is the direction we should be moving to. @ederag, I'm aware that you put substantial effort into that, I and feel bad not to have commented earlier.
Yet I think I have to speak up, because I fear otherwise hamster is going to loose it's usefulness for me.

Time tracking is for busy people

The heading says it all. Nobody tracks time spent looking out of the window or with various games and amusements.

Therefore the most important feature for a time tracking tool is to get out of the user's way.

The second most important feature is to enable users to update the current activity with as little effort as possible. That means two mouse clicks, or one mouse click plus a few key strokes (with decent autocompletion). This is possible today, and please, let's not ruin it.

hamster used to shine in both, both via command line and GUI, and that's why I'm using it. That's also why I'm using the GNOME extension a lot, which is always just a single mouse click / key combo away. The current tendency towards big dialogs loaded with controls is against that spirit, IMO.

This is also a strong argument for "smart" input parsing with just a single text input field. It's so much faster to type "8:00-9:30 boss@Meeting #salary" than to click through 5 different input fields and type into each one.

Of course people make mistakes, and that's the main reason we need "edit activity" dialogs. Make those dialogs can be as complex as necessary, with all kinds of detail controls, I don't mind. But the primary dialogs, those we use many times a day, should be as lean and tiny as possible.

[ederag]

@mwilck The "Cmdline" is not going away at all !
It is still there as the top, ready for quick keyboard entry as usual.
Actually this is still my preferred workflow.
I'll try to answer with more details this week-end.

EDIT: This answer gave a summary of the rationale behind the proposition. An extensive discussion can be found in the rest of PR #461.

[ederag]

I'm taking a temporary break (at least 10 days) away from hamster.
Too much pressure, too little pleasure.
See you.

[mwilck]

@ederag, get your rest! Thanks for your continued work on this project.

[ederag]

Comments here and elsewhere showed that
the main parser changes will have to be validated before v3.0
(in good progress, part of it already in #482).
The opportunity to migrate to GSettings (#470, thanks @bgamari !)
already shattered the plans anyway. So let's polish before v3.0,
to be released at the end of January or perhaps in February (one year after the previous release).

[ederag]

It would require much more cleanup, but a working v3.0 could be released by the end of next week,
to give a chance for ubuntu packagers to get v3.0 into 20.04 LTS.

[ederag]

v3.0-beta is released in time.
Early testing would be great, as schedule is tight (v3.0-rc1next week-end if everything goes well).

[mwilck]

Recursion depth exceeded calculating fg color

Sorry for bothering, this not a hamster problem. It is an issue with the help viewer. It seems to be known, actually.

[mwilck]

SUSE users, hamster 3.0-beta packages will soon be available from the "Office" project on OBS.

[ederag]

@elbenfreund and @tstriker have just been contacted by mail about the shell-extension.

This is a message for them, but it might interest others as well, as a confirmation.

The legacy code is becoming more and more familiar,
and I understand more of the history and
reasons for the clever design decisions.
No wonder it has often been labeled the "best time tracker",
thank you so much @tstriker !

We are going to release v3.0 soon,
hopefully fulfilling the great work done by our predecessors on the v2 gtk3 port,
to keep the project fully alive for the years to come, as already said.

I sincerely think that if the rewrite resumes, it will be for the best,
as part of the current effort can be easily transferred to it
(e.g. the refactored parser - works well, just requires code clean up after the release).

In the end I do hope we will all be happy with the outcome !

[ederag]

v3.0-rc1next week-end if everything goes well.

Well, #549 has been delayed and still needs more testing
(I did under openSUSE+kde and ubuntu-19.04+gnome/X11/wayland,
but a variety of testers is important)
There's also the brand new #565 waiting for feedback from packagers.
Ideally, both are validated on monday, and v3.0-rc1 can be released,
leaving 10 days before the ubuntu LTS feature freeze.
Will we find a packager ? suspense !

[hedayat]

Great. I'll try to test & package it for Fedora. But might take some time ...

[GeraldJansen]

All clear from my testing of 549 on xubuntu-19.10 (including xfce-hamster-plugin). 👍

[ederag]

Thanks for testing ! Let's release v3.0-rc1 this evening.

[ederag]

v3.0-rc1 released, 8-9 days before ubuntu LTS freeze.
v3.0 this week-end if all goes well.

[ederag]

Still no sign of any ubuntu packager, 4 days before ubuntu LTS freeze.

Released as v3.0-rc2, not v3.0 yet,
because I have now a bunch of function and files moves/renames on a local branch.
It would be cleaner to wait and have them in v3.0.
This way we could say to the "external" projects
"the client module was moved to the dbus/ subdirectory on v3.0",
instead of "sometimes just after v3.0"...
All these changes are made backward-compatible (with links), so delaying a bit is just a convenience.
It would be easy to make that change in v3.0.1 for instance.

If any of the contributors would prefer to stick to the plan and get v3.0 right now, please just say so,
and I'll retag as soon as possible.

[ederag]

Still no sign of any ubuntu packager.
At least there's the satisfaction to have v3.0 released as scheduled.
Time to relax, thanks to all contributors, especially to testers !

[GeraldJansen]

@ederag: Thanks for all your commitment and effort. The changelog since 2.2.2 is impressive!

[ederag]

Thanks @GeraldJansen, I think we did well, indeed.
From the contributors page it should be already clear that you made a major contribution to v3.0.
It's obvious for people following the project,
but for others, let me recall that your continuous quality feedback shaped v3.0. Thanks again !

[didierm]

Non-official v3.0 Fedora 31 build : https://copr.fedorainfracloud.org/coprs/ifas/hamster/
Seems to work fine with https://github.com/mwilck/hamster-shell-extension/commits/GNOME-3.34

A sincere "thank you" to all involved !

[ederag]

A bunch of bugs was fixed in v3.0, and it is easier to maintain (still WIP),
so we are on a slowly rising slope.
But I hope that 3.1 or 3.2 will be seen by users as at least on par with v1,
and that all the work our predecessors made in v2 will shine through.

To bring back lost functionality, currently work is easing the "external" things, to help #493.
Then, in parallel, gui fixes.

[ederag]

It seems that @elbenfreund has a very biased view of the current state;
some support would be appreciated on #574.

[heyakyra]

Non-official v3.0 Fedora 31 build : https://copr.fedorainfracloud.org/coprs/ifas/hamster/

Is ifas/fas a contributor here? Would be great to see a Fedora 32 build, and see if it could be included in the official F33 repos

[didierm]

Is ifas/fas a contributor here? Would be great to see a Fedora 32 build, and see if it could be included in the official F33 repos

F32 & rawhide fail to build due to missing ''dbus-python' and 'gnome-python2-gconf' packages :
https://fedoraproject.org/wiki/Changes/RetirePython2

I am a contributor nor a Fedora package maintainer. Feel free to use/modify the F31 .spec in any way you want. Inclusion in the official Fedora repos would be great.

[hedayat]

Is ifas/fas a contributor here? Would be great to see a Fedora 32 build, and see if it could be included in the official F33 repos

Yeah, there is :P I've plans to include it in Fedora official repos again; however I didn't have enough time for it yet, and I was waiting for final v3 release.

F32 & rawhide fail to build due to missing ''dbus-python' and 'gnome-python2-gconf' packages :
https://fedoraproject.org/wiki/Changes/RetirePython2

Hmm... Isn't v3 migrated to Python 3? I thought it was, I've not checked yet. If not, the first step is to remove all Python 2 dependencies. Python 2 is officially dead. BTW, thank you for preparing the F31 version.