hamster shell extension doesn't work with hamster snap package

[mwilck]

Forked off the discussion between @extraymond and myself on #326. See this comment and below.

Snap-packaged software doesn't support DBus activation for security reasons (discussion on snapcraft forum).

That's a problem for the extension, because the extension is started right after login, and by that time, the hamster-windows-service may not be started yet. The extension gives up after failing to start the DBus service. Even if the service becomes available later, the extension won't be activated again, at least not in the GNOME panel (perhaps that's a bug, but I have no idea how to fix it).

So, basically, users of the snap package and the GNOME extension will need to launch hamster manually after logging in, and then type Alt-F2 -> r to restart GNOME shell, which is not exactly user-friendly, and doesn't work at all for Wayland.

Creating an autostart file for hamster may be a workaround, but it's currently unclear if it works at all, and if it will work reliably.

[matthijskooijman]

This sounds like it will be fixed in snap at some point, which also seems the right place to fix this.

However, what might make sense is to let the extension monitor dbus to see if the hamster endpoint (or whatever the terminology is) becomes available later. I suspect that dbus has some kind of "Send me an event when this name becomes available later" interface that we could use for this? This might also be useful in cases where hamster quits and gets restarted (not sure how that is currently handled, though).

[extraymond]

Thanks for the outline, the current situation is indeed not ideal for snap, I'll continue looking for improvements if that's possible without changing how hamster works typically.

[mwilck]

Well, I guess we need to avoid the initial extension enablement to fail, and find some way to place the extension on the GNOME panel at a later time when the the DBus service is found and the extension has the chance to become functional. But I lack the knowledge of GNOME shell internals to fix that on a reasonable time scale. Perhaps someone else?

[salim-b]

So, basically, users of the snap package and the GNOME extension will need to launch hamster manually after logging in, and then type Alt-F2 -> r to restart GNOME shell

I'm on Ubuntu 20.04. I've installed the Hamster Snap package, ran the necessary snap connect hamster-snap:system-observe and opened the Hamster GUI running hamster-snap. But after restarting GNOME Shell with Alt+F2 -> r, issueing journalctl --user | grep hamster still gives me:

Mai 08 01:15:07 mypc gnome-shell[2334]: hamster-shell-extension: 'hamster-windows-service' not running. Shutting down.
Mai 08 01:15:07 mypc gnome-shell[2334]: Shutting down hamster-shell-extension.

Can I start the DBus service manually somehow?

[mwilck]

Perhaps it might have worked better with hamster 2.2.2. In hamster 3.0.x, the code behind the hamster-windows-service DBus API has been removed and replaced by invocations of the hamster CLI, which behaves strangely and doesn't have the same functionality as before. See hamster #563. With 2.2.2, you could have started hamster-windows-service via DBus and it would persist as a lean DBus service, even if hamster itself wasn't running. With 3.0, you need to have hamster running all the time, and when you close the last hamster GUI window, the DBus service will disappear, too.

With a regular installation, that's only a minor issue (just the delay between clicking "edit activity" and the hamster window popping up is noticeably longer). But with snap, as DBus activation doesn't work cleanly, I guess its a cause of major headache.

[salim-b]

Thanks for your response!

I briefly skimmed projecthamster/hamster#574 and gained an idea of how the current situation of incompatibility between hamster core and GNOME Shell extension could arise... 🙈

Anyway, to get to the point:

With 3.0, you need to have hamster running all the time, and when you close the last hamster GUI window, the DBus service will disappear, too.

Even if I keep the Hamster GUI open all the time, i.e. incl. restart of the GNOME Shell (what I already did the last time IIRC, but to be sure I've checked again now), journalctl --user | grep hamster still gives me the same:

Mai 11 00:07:29 mypc gnome-shell[2579]: hamster-shell-extension: 'hamster-windows-service' not running. Shutting down.
Mai 11 00:07:29 mypc gnome-shell[2579]: Shutting down hamster-shell-extension.

Addendum: Just to be clear, I've installed the 3.36 release of the Shell extension.

[mwilck]

I don't think it that this is related to the version of the shell extension. It's most probably rather a limitation of snap, as explained in the initial comment of this issue.

[mwilck]

Perhaps someone should try to create a native Debian/Ubuntu package. It can't be that difficult. But I'm not into Debian packaging, so I can't really judge it.

[ederag]

@mwilck

Perhaps it might have worked better with hamster 2.2.2. In hamster 3.0.x, the code behind the hamster-windows-service DBus API has been removed

hamster-windows-service stayed there, and should be fully compatible, even in 3.x.
See projecthamster/hamster#573 (comment):

@ederag has always been a very strong supporter of maintaining a stable DBus interface.

---

@salim-b

I briefly skimmed projecthamster/hamster#574 and gained an idea of how the current situation of incompatibility between hamster core and GNOME Shell extension could arise

Too "briefly skimmed"...
I was dedicated to keeping compatibility between core and extensions,
and even tried repeatedly to install the extension [last try].

---

So I do agree with @elbenfreund that part of this sad story was due to FUD. (Had to look for the definition) 🙂

Shallow understanding is unfortunately widespread.
No hard feelings at all.

Please be nice to the new maintainers; I'm out.

Bottom line: Criticizing v3 was a red herring here.

[salim-b]

Too "briefly skimmed"...
I was dedicated to keeping compatibility between core and extensions,
and even tried repeatedly to install the extension [last try].

Yeah, I meanwhile realized that v3 and all the development-internal conflicts around it weren't the cause of the incompatibility per se but rather some shortcomings specific to the Snap version of Hamster v3 as @mwilck indicated in the initial post of this thread.

Anyway, the recently added Flatpak version of Hamster v3 works fine in combo with GNOME Shell extension.

But what still remains a major deal breaker IMHO is the removal of the idle detection which hasn't been brought back in any other form yet. Due to this, the GNOME Shell extension is currently way less useful. I understand that from an organizational / software architectural point of view this removal might be beneficial – but I guess it was effectuated overhasty (i.e. without waiting for a proper alternative/succesor for the same functionality).

[ederag]

@salim-b
About the "idle" removal, there were good reasons.
And about "overhasty", I disagreed a while ago.

which hasn't been brought back in any other form yet

Responsibility is on a bunch of people who were not thorough enough,
and who wanted too much.

---

shortcomings specific to the Snap version of Hamster v3 as @mwilck indicated in the initial post of this thread.

And I precisely disagreed:
the shortcoming comes from snap not having activation, so v2 was no better.
It has little to do with v3.