You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I fear this post will earn me thumbs-down emojis, but I think I need to discuss this once more. There's little new content here, most has been said elswhere already; I'm just trying to summarize. Links are provided.
I've been using hamster 3.0-x for a few weeks, since the beta release. The other day, I made a mistake while updating my system, and inadvertently downgraded hamster to openSUSE's official 2.2.2 release. After a few hours, I realized that I enjoyed using hamster more than I did with 3.0. Here are the reasons:
I totally miss the idle detection under GNOME in 3.0 (3.0-rc1: hamster ignores screen lock events #568). I seem to be simply unable to remember stopping the current activity manually before I leave or lock the screen. When I get back, I have to start guessing when might have left. This feature, along with other desktop integration features, has been deliberately removed (Move idle, external, and similar features elsewhere #493, Remove external stuff #494). @ederag said that the functionality could be reinstated by creating another service, and that's true. But doing that is not a one-day task. For the time being, this feature will be missing from hamster. This affects only GNOME users, because the feature never worked in other environments anyway.
With 2.2.2, when I click the "edit" button in the GNOME extension, the hamster "edit activity" window appears immediately, as if the extension and the hamster were the same application. With 3.0, the reaction time is significantly more sluggish. I think the main reason is that in 3.0, the original implementation of the hamster-windows-service DBus API has been replaced (Restore edit, remove dialogs #549) by wrappers, which fork() and exec() the hamster command. That's necessarily slower than an already running background application simply popping up a dialog. This is not a fatal regression, but it does affect how working with the UI "feels", in particular if the GNOME extension is involved. I haven't seen a convincing argument why this code needed to be removed. @ederag has called it technical debt, but don't understand why - IMO, that code was no worse than anything else in hamster.
but that is still experimental, the actions API is subject to change.
@ederag argued that this is the new gnome way. It's true that GNOME advertises the GApplication API, but I haven't seen evidence yet that this means other APIs are now deprecated, or need to be replaced short term. I am a little wary of exposing a DBus API in an official release which is considered experimental by the developers.
@ederag has invested lots of work into the multi-input "edit activity" dialog (Separate edit fields #461 and related PRs/issues). I've had a few discussions with him and others about this, but it was only after I had downgraded to hamster 2.2.2 that I realized how much I prefer the single-input KISS-style pop-up of the old version. Although the new multi-input dialog is well laid-out, the sheer number of inputs feels distracting and confusing to me. 95% of the time, I only open this dialog to fix the start time of the current activity.
All this is totally subjective and personal. Going back to 2.2.x is not an option. Some changes in 3.0, like the waf update and the move from gconf to gsettings, are mandatory, and, thanks to @ederag's work, there are lots of bug fixes in the 3.0 release which nobody wants to loose.
I do appreciate @ederag's work very much, and I definitely don't want to scare anybody away from using or trying hamster 3.0. Perhaps it's really just me who prefers the "feel" of the previous version. I just want to encourage a discussion - perhaps we can find a remedy for the issues raised. If everyone else thinks that I'm on the wrong track, just close this.
The text was updated successfully, but these errors were encountered:
I fear this post will earn me thumbs-down emojis, but I think I need to discuss this once more. There's little new content here, most has been said elswhere already; I'm just trying to summarize. Links are provided.
I've been using hamster 3.0-x for a few weeks, since the beta release. The other day, I made a mistake while updating my system, and inadvertently downgraded hamster to openSUSE's official 2.2.2 release. After a few hours, I realized that I enjoyed using hamster more than I did with 3.0. Here are the reasons:
I totally miss the idle detection under GNOME in 3.0 (3.0-rc1: hamster ignores screen lock events #568). I seem to be simply unable to remember stopping the current activity manually before I leave or lock the screen. When I get back, I have to start guessing when might have left. This feature, along with other desktop integration features, has been deliberately removed (Move idle, external, and similar features elsewhere #493, Remove external stuff #494). @ederag said that the functionality could be reinstated by creating another service, and that's true. But doing that is not a one-day task. For the time being, this feature will be missing from hamster. This affects only GNOME users, because the feature never worked in other environments anyway.
With 2.2.2, when I click the "edit" button in the GNOME extension, the hamster "edit activity" window appears immediately, as if the extension and the hamster were the same application. With 3.0, the reaction time is significantly more sluggish. I think the main reason is that in 3.0, the original implementation of the
hamster-windows-service
DBus API has been replaced (Restore edit, remove dialogs #549) by wrappers, whichfork()
andexec()
thehamster
command. That's necessarily slower than an already running background application simply popping up a dialog. This is not a fatal regression, but it does affect how working with the UI "feels", in particular if the GNOME extension is involved. I haven't seen a convincing argument why this code needed to be removed. @ederag has called it technical debt, but don't understand why - IMO, that code was no worse than anything else in hamster.A new
org.gnome.Hamster.GUI
DBus API has been added, but it's not fully functional and behaves strangely ('org.gnome.Hamster.GUI' - strange semantics of window pop-up and persistence #563). IIUC, the intention is to use it as a replacement for the windows service some day, but not yet:hamster/src/hamster-cli.py
Line 103 in afbec4c
@ederag has invested lots of work into the multi-input "edit activity" dialog (Separate edit fields #461 and related PRs/issues). I've had a few discussions with him and others about this, but it was only after I had downgraded to hamster 2.2.2 that I realized how much I prefer the single-input KISS-style pop-up of the old version. Although the new multi-input dialog is well laid-out, the sheer number of inputs feels distracting and confusing to me. 95% of the time, I only open this dialog to fix the start time of the current activity.
All this is totally subjective and personal. Going back to 2.2.x is not an option. Some changes in 3.0, like the waf update and the move from gconf to gsettings, are mandatory, and, thanks to @ederag's work, there are lots of bug fixes in the 3.0 release which nobody wants to loose.
I do appreciate @ederag's work very much, and I definitely don't want to scare anybody away from using or trying hamster 3.0. Perhaps it's really just me who prefers the "feel" of the previous version. I just want to encourage a discussion - perhaps we can find a remedy for the issues raised. If everyone else thinks that I'm on the wrong track, just close this.
The text was updated successfully, but these errors were encountered: