projecthamster / hamster-lib Goto Github PK
View Code? Open in Web Editor NEWA unified library for timetracking clients.
Home Page: http://projecthamster.org
License: GNU General Public License v3.0
A unified library for timetracking clients.
Home Page: http://projecthamster.org
License: GNU General Public License v3.0
By mimicing the original implementation our own version tries to do far to much.
Right now we do not only parse the info-string but also handle fallbacks and default logic.
This should be done seperatly.
One of the current downsides, just like in the legacy code, is that defaults are handled in various places.
Instead this method should just parse the string and return the decomposed instances.
We can then have a seperate method that evaluates those and may assign defaults/fallbacks. If this is to happen in the frontend or on the client level remains to be seen.
Also, it seems sensible to move this function to a helper module.
legacy hamster
provides a basic reports
module. In order to stay compatible we should adjust it as far as feasable and incorporate it into hamsterlib.
At least check if end>start.
A a way to list all activities present in the backend.
The original implementation falls back to datetime.time() if no end time is given.
That however translates to 00:00. Legacy hamster-cli
help itself however claims it would default to 23:59.
Our original implementation stuck to the fauli behaviour in order to stay compatible.
Our new API however should correct that behaviour.
Also: it may be more sensible to respect configs day-end
setting here instead of 23:59.
Add a command to to export existing facts to one of various files.
supported file formats:
The old code seems to order the returned list by the related facts start time.
When Fact.create_from_raw_fact.
parse_time_infois not passed a valid start time, it falls back to 00:00 of the start date. However, to be consistent with the rest of it may be desirable to fall back to the configures
day_start` value from our config instead.
The original implementation creates normalized (lowercase etc.) versions of attribute fields to match search terms against.
Do we actually need this?
Basic CRUD operations of our storage backend should always log their results as debug()
.
Provide a command to show the current 'temporary fact' if there is one.
Timeframes as returned by hamsterlib.helpers.parse_time_info
may miss some of their attribues and as a consequencec not provide a comple referenceframe.
This helper function applies our default fallback/autocomplete strategy in one central place and returns a complete (start, end) tuple of datetime
objects.
Our current method does not match the legacy functionality
.
Although some bizzare unused function in hamster-cli
does specify categories
this is actually not relevant for us.
Instead this method is to return:
start in our initial implementation unifies two faculties:
Evaluate ways to allow for databasebase migration.
For our SQLAlchemy backend see here.
Should this be generalized? If so, how?
Right now, we use the original libs general spec to disect time information when parsing a raw_fact
.
The legacy client code however allows much more elaborate time specifications as well as providing a nice parsing function.
In order to avoid reimplementing this in every client, our Controler should provide a parse_time_info
method that takes care of that.
Note: This new method may also be utilized by our parse_raw_fact
method at a later point.
Command to list all Facts in a given timeframe.
If hamster_gtk
is present, provide a way to launch specific windows/interfaces/views.
If not, provide meaningfull feedback.
Right now, category names are case sensitive and unique. This in itself is not a problem.
However, if we later come to decide that search is to be case insensetive, we may up with several results for one search string despite the uniqueness constraint.
We will have to decide if this is desired behavior and we deal with multiple results or if it is preferable to enforce "case insensitive uniqueness" and avoid such subtleties.
store.facts
needs a way to retrieve the current ongoing fact. Should return KeyError if ther is none.
Pyhton arrow may be a simpler and more unified/tested solution to our time handling needs.
six, sqlalchemy and fauxfactory need to be added to isorts 3rd party modules
Due to legacy hamster-cli
our Controler provides a dedicated time_range_parsing function (#25) that features a more flexible time pattern. We should adjust our parse_raw_fact
method to make use of this extended flexibility as well.
In order to stay API compatible this should only happen once we are willing to break backwards compatibility.
Users can search existing Facts against a string within an optional timeframe.
The original implemenation has a rather convoluted concept of a Fact.date
and how this relates to __get_facts
. Also see legacy information.
The way the original implementation does this is by fetching all facts deemed relevant and assign them date
and delta
. this is no option for a pure lookup method. We clearly can not look facts up by those properties and in light of an unknown amount of return values this needs to be handled somewhere else. This is where our Hamster.Fact()-properties shine. However, that also means that we can no look up facts by date!
Our first incarnations simply this significantly. A fact.date
is the date of a facts startdate.
At some point we should investigate if/how we refactor this to satisfy original API requirements.
I suspect SQLAlchemy takes care of this, but we need to doublecheck.
The packaged version on pypi does not include the sqlalchemy backend.
storage.facts needs a way to cancel any present ongoing fact.
For obvious reasons this should be public.
Besides filtering by timeframe, we also want to allow to just match certain terms.
According to this we need to match it against the following:
by category.name
Add a command to list facts matching certain criteria ..
Note: How is this different from list command.
Add a command to stop the current 'ongoing fact'. That is to add an end date to a fact.
Originaly we wanted to keep any notion of 'ongoing facts' strictly on in the frontend/client-code.
This however, causes problems, for example with representing a Fact missing attributes at a given point.
Whilst we stick to our decission and will not store any ongoing facts
our hamsterli object itself will have a ongoing
property that allows for easy checks.
Throughout initial development we placed several # [FIXME]
Blocks to indicate issues that we need to have a look at later on, once the initial dust has settled.
These can only be short term solutions. We need to go through them and either turn them into proper issues or remove them if they have been rendered obsolete by now.
Right now, facts.save()
will be very accomodating and call _start_tmp_fact
if it recieves a fact without end
. This makes adding ongoing facts very transparent.
Is this bug or feature? The alternative would be to return an error, suggesting to client to use a dedicated public start_tmp_fat
method.
In the past we droped information about legacy hamsters 'API' and expected behaviour right into our codebase. With this release we should clean out those.
If we feel the information is still relevant it should be move into the regular documentation.
Maybe use jinja?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.