Mac OS X port

[iliv]

Hello,

I'm a big fan of Project Hamster. It is hands down the best time tracking software there is out there. Design and usability are unmatched by any other. It is most intuitive to use application in its class I've ever run into. It makes a pretty much dull and tedious task of time tracking an interesting exercise because I can feel how this little app alleviates most boring input efforts with memorized entries and tags. I could go on and on, statistic module albeit not extremely flexible and detailed is very decent and, well, looks great! A point that gets overlooked by many in software development world.

Anyway, I couldn't find a good enough replacement for Project Hamster on OS X -- despite the myriad of commercial applications -- nothing is quite as good. I've been checking out your wordpress site and github account in hopes to see OS X version for years but alas this is apparently not something you're planning to do.

I just wanted to contact you and let you know that there is a real need for a good application like project hamster on OS X. There's a gap to fill. Much like GnuCash OS X port is a kick-ass personal finance application on OS X that has no rivals even of commercial breed, had the Project Hamster been ported to OS X, it would've been the king of time tracking.

I know how open source software development is and I totally understand that OS X is not everyone's priority but I do wonder what it would take to port Hamster to OS X. Especially seeing how GnuCash is actively supported. There must be framework already established that could be taken advantage of and save Project Hamster developers a ton of time.

Is there any "political will" at all? How demanding an effort like that would be? Heck, I so want to see Hamster on OS X that I'm considering to run a donation campaign or something.

Ivan

[nchachereau]

Hi there! Thank you for all this enthusiasm, I am sure everyone who tries to devote some free time to hamster is glad you like it so much.

However, as we are only a few people, without very much time and doing this on the side... porting the app to a platform we do not even use is really not an option. At all 😞 Especially since the current code base has so many bugs... So in the interest of cleaning the list of issue, I am marking this as wontfix and closing.

I hope you will find a way to run hamster on OS X (does anyone know whether this is possible? after all, GTK+ is more or less cross platform...) or another great application for your new platform of choice. Kind regards!

[jeff-dagenais]

sad.

Any updates on this? Any other suggestions? Does the rewrite have a better chance of working on macOS?

[ederag]

This would require someone with knowledge of macOS and dbus.
And yes, the rewrite uses up to date python packaging
that has better chance to work cross-platform.

[mapkyca]

I'm also trying to scratch this itch.

I travel an awful lot for work and so use owncloud to sync the hamster db between various machines, which works great. However, my new gig is now mainly a OSX ecosystem.

I'm actually hoping to sidestep the whole issue by writing an interface to poke into the database directly. It seems fairly achievable, since as far as I can see the database is pretty simple...

I will let folks know how I get on...

[ederag]

db.py is doing just that, directly, if the issue is only dbus.
Is the overview window showing ?

[plowsec]

I just tested on OSX, I could successfully install the dependencies (including GTK3) and build hamster. For now I have trouble with dbus but the situation is not as hopeless as it used to be :)

[ederag]

Great news, thanks !
You might be interested in PR #573, and the --no-dbus option.
I have now moved off the project (the new team is full of energy; the project is fine),
but it would be great to see that work useful.

The instructions for testing a PR might be useful.

[plowsec]

Oh wonderful! I should have checked the PRs. So here is a screenshot:

I could not install hamster with the following command:

( umask 0022 && sudo ./waf install; )

So instead, I launched hamster-cli.py manually (python3 src/hamster-cli.py) and fixed the errors as they appeared.

One thing that gave me trouble was the error

(hamster-cli.py:5156): GLib-GIO-ERROR **: 22:55:09.752: Settings schema 'org.gnome.Hamster' is not installed

I fixed it in the following way (I have no idea what I'm doing but I just want the damn thing to work):

cp data/org.gnome* /usr/local/share/glib-2.0/schemas

Then it is my understanding that I should update the gschema.compiled with the command below:

glib-compile-schemas /usr/local/share/glib-2.0/schemas/

And then:

python3 src/hamster-cli.py --no-dbus

I had to install those dependencies:

brew install python3 gtk+3 pygobject3 adwaita-icon-theme
brew install gettext
brew install intltool
brew link gettext --force

Thanks for the help and the --no-dbus flag :)

[ederag]

Congratulations !
It would be great to make the installation process work on mac as well, but meanwhile,
this workaround might be useful, to work without any installation.

[ederag]

Note: PR #573 has just been updated with the latest fixes.

[GeraldJansen]

What a nice surprise. Yay for the --no-dbus flag!

[ggdupont]

@plowsec thanks for making this work, I've been missing hamster tracker since I moved to macos... Quick question though: I can't manage to get the "gi" module available even after cleaning my python env and installing it fresh with homebrew like you suggested. Any clue on why my python interpreter might not find the package installed?

[mwilck]

Can someone please explain for non-Mac people why --no-dbus is required? Is there no DBus on MacOS, in general, or do you just have issues making it work? A quick web search suggests that making DBus work on MacOS is possible...

As I've expressed in #573 already, I don't think that --no-dbus is a good idea. The DBus-based architecture is at the heart of hamster's design, IMO. If that precludes people like you from using hamster, I may need to reconsider my position. But before I do, I'd like to understand the actual issues.

[jeff-dagenais]

I think making a --no-dbus build is a quick simple workaround for a macos build. The alternative, I suspect, means that dbus headers and library dependencies will need to be found. This can most likely be achieved with brew. What you would encounter on a successful build and execution is the fallout of broken expectations of the usual session dbus ecosystem. A normal desktop user session populates the bus with many dbus objects and their interfaces. These would include ways for hamster to send notifications, get user inactivity events, etc. Since macos itself does not use dbus, by default, your session bus would be rather empty. So unless you or someone cares to create a "full-featured" dbus user session, you would most likely get errors from hamster. Hence the --no-dbus shortcut. 😉

-my 2 cents

[matthijskooijman]

What you would encounter on a successful build and execution is the fallout of broken expectations of the usual session dbus ecosystem. A normal desktop user session populates the bus with many dbus objects and their interfaces. These would include ways for hamster to send notifications, get user inactivity events, etc.

Did you happen to try this? I'm not entirely sure, but I think hamster does none of that through dbus (there are no notifications, and gnome-specific inactivity detection was recently removed). The gnome-specific UI (e.g. indicator in the top bar) is managed by a gnome-shell extension. I believe (but have not checked) that the only use of dbus is to separate the database backend from the GUI client (and allowing multiple clients to access the same data).

I guess getting dbus to work could be a challenge itself, of course. Depending on how much of a challenge, this could be an argument for --no-dbus (though it might also be worth getting dbus working on MacOS, allowing e.g. a gnome-shell-extension-like client that better integrates into the MacOS system).

Quick question though: I can't manage to get the "gi" module available even after cleaning my python env and installing it fresh with homebrew like you suggested. Any clue on why my python interpreter might not find the package installed?

The gi module is Gobject Introspection, which (for hamster) consists of 2 parts: The actual glib/gobject library (which I think is in the brew install list) and a python module that interfaces with that. The latter can probably be installed through pip (though that might need additional development packages from brew maybe?) or maybe brew has prebuilt packages for those (this is how it works on Debian/Ubuntu, at least, see the README for the Debian/Ubuntu packages used). Maybe this helps?

In any case, given there seem to be multiple people still interested in supporting OSX, I'll reopen this issue. However, I do not expect that any of the maintainers will be in a position to actively drive this, but I would be happy to receive pullrequests to make this work (and document the installation). If we do, however, I would want to make this work cleanly (e.g. figure out what is needed to make waf install work, possibly by letting waf skip some steps, rather than documenting a manual install).

A subsequent step could maybe be to write some scripts or config files to allow generating a .app file (that's the MacOS app bundling format, right?) that could be built for releases (through a GH actions workflow), or see about including hamster in brew (which would probably require someone external to maintain it, similar to the Linux distro packages). But all that is the dot on the horizon, making things work properly would be the first step :-)

[ggdupont]

thx all for the answers, I managed to launch it with the --no-dbus option too.

Few hickups:

• triple check the python3 interpreter vs the one used with brew (and thus linked to module installed with brew install pygobject3)
• No module named 'xdg' => pip3 install pyxdg