Hamster for Windows, mobile, web?

[damluar]

Hi, is there any hope that Hamster will become available on Windows or mobile or web?

[tstriker]

dunno, would have to rewrite the whole thing and don't have horse power for that :)

[tstriker]

there is a windows port roaming around though - do a google search

[olgabot]

What about a mac port via Fink? http://pdb.finkproject.org/pdb/browse.php?sec=gnome

[iluminite]

Hi @tbaugis

First, thank you for the tremendous amount of time and energy you have invested in this project, and of course for sharing your work with all of us and contributing more open source software to the community.

Secondly, for the moment, please ignore any considerations to your time or energy available for this project - let's just assume this is not an issue. With that said, I am curious: what is your level of interest in this topic?

By "this topic" I do not mean a windows port, or a mobile client - the underlying issue here is that of portability. At present, Hamster is not in the least bit portable. This is not a fault of yours or some defect in Hamster, it is just the way it is. You have your world of needs and interests, a desktop environment and computing setup that works well for you, and all of which eventually led to hamster, and which still influences hamster's development. You have written good software that works and meets a critical need, so it is no surprise that it appeals to so many people.

But through all of this, there is one single detail which completely limits Hamster's use, hinders Hamster's growth, and fuels Hamster's bugs, issues in github, and eventually consumes more of your time and energy.. and it is this issue of portability.

In fact, this issue of portability is such a problem, it is incorrect to consider hamster the "linux time tracker", or even the "gnome time tracker".. Feel free to correct me if I am wrong, but I believe the only correct title for Hamster (at present) is "The Time Tracker for Gnome 3, on Linux with dbus".

Hamster is written in python, yet.. Hamster will not run, out of box, on gnome2, let alone XFCE, or KDE, or Hamster will not run on OSX, Android, *BSD, Windows or anything lacking dbus or hamster's other dependencies

Hamster will break if anything outside of this narrow sliver of the open source world is provided.

While the fact that Hamter is like this is completely understandable, this single limitation is a silly one to allow to persist.

Thus, I propose we aim to recreate Hamster such that it is fit for the title: "An Awesome, Open Source Time Tracker"

This title is purposefully generic. Hamster is written in python, python can run more devices and operating systems than can be noted in this comment - Hamster should capitolize on the portability of python! If we were to use this title as our guide, we would spread Hamster further, simplify the codebase, increase functionality, call in more developers, and otherwise revolutionize this awesome project in a way that I believe would more powerfully benefit a much greater user base.

Please note, I am in no way saying "Tom, you should go and do all this work" - to be clear, I am asking you for your input on this topic to gauge your interest, with the hopes that all of this would lead to a community-driven effort to recreate Hamster in a way that is more useful and more accessible to more people.

I can respect your having no interest in this topic, and choosing to put your head down and just keep coding the way you have - I have no desire to force some sort of change on you. With that said, I sincerely hope you are able to give this this topic serious consideration - our success in such a revamp would reduce your overhead while empowering others to contribute in their own way.

There are numerous ways to accomplish something to this effect. As an example, off the top of my head..

• refactor the hamster code base such that we have hamster-core, hamster-client, hamster-gnome-ui
• hamster-core would be limited to the very core of hamster, the stuff that is needed to meet hamsters's time tracking capabilities - essentially, low-level operations to properly manipulate the database
• as the next level up, hamster-client would build on hamster-core to include the actual time tracking capabilities. eg, high-level components would use hamster-client to start/stop/manipulate time tracking through hamster-core. we could even do this in such a way that we could register different clients with different hamster "instances"..
• continuing with the example, hamster-gnome-ui would be limited to gnome-specific functionality and code.. eg, hamster-gnome-ui would build on hamster-client to provide a UI for the gnome desktop.

The above could be accomplished on the current codebase, without altering functionality. We would then be free to..

• refactor hamster's db core, use SQLAlchemy or similar - this would free us from being tied to SQLite... we would be free to setup hamster-core running on a server, backed with postgres.. or mysql.. or..
• now it is super easy to add statistics, in fact, we could have a hamster-stats or hamster-contrib - having trolled through the code myself, desiring additional stats or details, I would not do so with the current code.. I'd waste my time debuging crazy bugs.. but if we refactored hamster similar to the above, a python stats hacker could whip up something new in a matter of hours
• want cool visualizations? by sensibly breaking up the project into core components focused on a specific problem domain, we open up the possibilities to integrating with the world of open source.

thoughts?

[tstriker]

i agree, we could split the code. the current chain of events is following: sqlite implementation - db abstraction - dbus service ---- dbus client - gnome ui

would you suggest to chop that into three parts (sqlite + db abstraction, dbus service + client, gnome ui) each next one depending on previous? there wouldn't be much to refactor - the code is quite loose as it is already - duplication could be solved by using git modules instead of creating yet another package.

the mentality here, though, for me seems to be "If you build it, he will come". i believe that the barrier isn't that high and any champion with motivation big enough, would overcome the initial hurdle.

so my question would be - what is your own motivation? - do you want to create a ui for another DE? if so, i'd suggest starting with frankensteining together whatever model would fit you better and then we could go from that end and looking for compromise and see, to which level the split is necessary. or in other words - don't promise - show!

Toms P.S. below i'm addressing your mail in full - not to fight about it but i thought it might give insight

---

Functionally, you can achieve everything you mention already:

• this might be useful - http://pypi.python.org/pypi/hamster-sqlite/0.1
• the storage - db abstraction allows you to replace backends (like switching to sqlalchemy)
• as you perhaps may know, hamster front-end communicates with backend purely through dbus. the idea of multiple clients is already there - an example would be the shell extension running in parallel with the overview window and so on

the suggested outcome seems to me be purely demagogic:

• the database is barely an issue and should not be a concern - why even bother about way the data is stored if it is abstracted behind APIs? i for one, certainly don't care how it's stored - and for hamster needs i'd argue you can achieve all of it in sqlite.
• for number two and three - there are python bindings to the backend that allow you to whip up stuff within matter of minutes. for examples see hamster_* scripts here: https://github.com/projecthamster/experiments

[jimwild100]

Hi Tom/anyone,

Could you possible explain how i might set up multiple users that feed into a single database that then allows me to have an overview of each and users time?

This application would be perfect for managing time in small design practices where multiple people work on the same project. There are too many other systems out there that deal with the whole works right through to invoicing which is just not necessary.

I also think I would use ssh X window forwarding to allow each 'client' to use the software, this is for mac and windows users and side steps the need for porting the whole package - until of course someone does!

many thanks, Jim.

[tstriker]

@jimwild100 - this would require a separate (possibly, web-based) project. I'd recommend that instead of syncing every individual activity, daily totals are synced. Preferably, one would also be able to specify via preferences, which categories should be exported (so that work and private can mix and not leak)

[jimwild100]

Thanks Tom,

Yes we don't need to sync in real time for monitoring, a weekly read would be enough. I really need to learn something about SQL databases, but presume it would be as simple as master user creates a new table/DB for this week/moment, then reads each persons tables in turn extracting relevant data, i.e. just one job from all the people, and compiling this into masters own DB/table. If this table is written well it can display in hamster or simply output to excel....work/private really isn't an issue, its time against specific projects that matters and private can just be empty or other entries, even so, this is for work and they should expect their time to be readable, just as it is in reality as they are sat behind me! Thanks again, I'll report my findings should I do anything son this. First was to do a mySQL tutorial, now I know some basic commands... next set up some sample users.

[tstriker]

herrm. forget about tables. as for CSV exports, you can do that already - Overview -> save report in overview's menu and pick CSV

[tstriker]

killing as wishful thinking.