projecthamster / hamster-gtk Goto Github PK

Instead of showing the following dialog window:

the input field should be auto-filled with a time-stamp, with the option for the user to later change the time-stamp to another name for the tracked activity.

What do you think?

Reference: https://hyp.is/lmnxRFx2EeaD4ydxN4EGyw/developer.gnome.org/hig/stable/design-principles.html.en

Warmly,

~Robert

:-)

hamster.widgets.activityentry.ActivityEntry employed some some custom logic to collect a ranked list of relevant activities and presents them as a drop down in the raw fact entry (via the custom CompleteTree widget).

It may be feasible to delegate the "create ranked suggestions" method to hamster-lib.

Instead of using a simple gtk.Box as main layout container we can use a gtk.Stack but without the usually employed gtk.StackSwitcher. Instead the switch is goverend by our self._on_button ...
methods.

Benefits:

• cleaner
• allows for fancy transition effects

Notes:

• Unlike with regular stacks where one want to keep individual stacks state, we need to make sure that we reset the old stack when switching.

version: 0.10.0

Changes to the preferences are only active after restarting hamster-gtk.

Whist the main apps config attribute is in fact changed right away, it is not possible to update the backend config at runtime as of now. Once hamster-lib has been improved this should be possible.

Right now overview_widgets.Totals tries to make sure there is a label hinting to the user there actually is something to be clicked in order to reveal the totals.
Besides the label often not shown due to wrong dimensions, the more general issue is that the StackedBar
should provide an optional label itself anyway.

Blocked by:

• #3

This new method allows for transparent controler config updates at runtime. Using this should help applying preference changes at runtime.

As part of our i18n and l10n effort we should localize the way date/time/datetime representations are generated. Babel seems to be the way to go.

We should provide a very rough and basic way to export a csv dump of all stored facts to a given location. For now this would not need to be fancy at all. This may be done in later iterations.

For cases where we want to disable the "parse time info" step (for example because the desired activity name includes substrings that look like time) we should allow for that. In that case, timeinformation needs to be passed explicitly.

Hamster should confirm with general gnome design/interface guidelines. In order to respect those, it would be great to have someone familiar with the relevant resources (provided below as reference).
This task does not really require any programming capabilities. Instead one would have to read into the guidelines and check where the hamster gui complies or conflicts them. Once this is documented, we can address those issues much more efficiently.

Reference:

• https://developer.gnome.org/hig/stable/

People may got used to the existing keybindigs, make sure we stick to them where ever possible.
Particular POIs:

• hamster.edit_activity
• hamster.widgets.activityentry.ActivityEntry

Right now attributes of an ongoing fact can not be changed. One needs to stop it and access its regular edit dialog for a normal fact.
It would be nice to have a more direct way to do this.

Related Error:

Traceback (most recent call last):
  File "/home/elbenfreund/projects/hamster-gtk/hamster_gtk/hamster_gtk.py", line 61, in _on_overview_button
    overview = OverviewScreen(self._parent._app, self._parent)
  File "/home/elbenfreund/projects/hamster-gtk/hamster_gtk/screens/overview.py", line 56, in __init__
    self._grouped_facts, self._totals = self._group_facts()
  File "/home/elbenfreund/projects/hamster-gtk/hamster_gtk/screens/overview.py", line 114, in _group_facts
    facts_by_activity[fact.activity].append(fact)
TypeError: unhashable type: 'Activity'

Under python 3, our hamsterlib instances which have a custom __eq__ method are no longer hashable without being given a custom __hash__ method. As a consequence building grouped dictionaries fails.

An issue with hamsterlib has been created.

Reference:

• Issue with hamsterlib

The original edit dialog featured some eye candy representing the a particular date and its facts present so far. The widget itself utilizes Toms custom drawing widgets but should be possible to reimplement with custom GTK3 classes.

Optionally it appears tis widget used to be able (in hamster-applet) to be used to select (date?)times directly as opposed to just represent the date.

One basic core functionality has been implemented, we need to address i18n and l10n.
It is advisable not to postpone this for two long in order to minimize duplicate effort.

It appears we can not simply use gettext for direct GTK related translations. This needs to be investigated!

Task related to i18n:

• Provide i18n for all GUI labels.
• Decide on a solution for i18n within the logging.
• Provide i18n setup for documentation.

Tasks related to i10n:

• Localize datetime representation #41

Over time, there has been significant class- and method creep within various submodules of the package. Now that we start to get a clearer idea about the general application structure it seems important to address the project layout again before it will require even more work do adjust it.

It is recommended to call gi.require_version(...) before importing Gtk and such. This however is prevented/'corrected' by isort as it will move those calls after the actual imports. According to this this is known and a solution is being considered. For now, our best shot is to run isort localy to maintain some order but not force it as part of our CI.

We opted for reimplementing legacy hamsters custom widgets as proper gtk subclasses instead of recycling the old custom codebase. As part of that effort we need to reimplement the StackedBar class.

According to the docs Gtk.Box whilst not deprecated is advised against in favor of all out Gtk.Grid based layouts. For migration tips refer to this.

This should not be a big deal and is of rather low priority right now, but should be done before the first proper release none the less.

We disabled the docs testsuite on the CI server due to some unidentified SSL handshake issues that were not reproduceable localy. At the end of the day, those need to be reactivated of cause.

Currently handle information about widgets parents manually by ourself. Not surprisingly GTK already has provisions in place for that. We should use them :)

version : 0.10.0

opening the edit dialog from within the overview fails if the fact to be edited has no category assigned.

Hamster-GTK started.
Traceback (most recent call last):
  File "/home/elbenfreund/.virtualenvs/hamster-gtk/local/lib/python2.7/site-packages/hamster_gtk/overview/widgets/fact_grid.py", line 105, in _on_activate
    edit_dialog = EditFactDialog(self.get_toplevel(), row.fact)
  File "/home/elbenfreund/.virtualenvs/hamster-gtk/local/lib/python2.7/site-packages/hamster_gtk/misc/dialogs.py", line 249, in __init__
    self._mainbox = self._get_main_box()
  File "/home/elbenfreund/.virtualenvs/hamster-gtk/local/lib/python2.7/site-packages/hamster_gtk/misc/dialogs.py", line 294, in _get_main_box
    self._raw_fact_widget = self._get_raw_fact_widget()
  File "/home/elbenfreund/.virtualenvs/hamster-gtk/local/lib/python2.7/site-packages/hamster_gtk/misc/dialogs.py", line 318, in _get_raw_fact_widget
    category=text_type(self._fact.category.name)
AttributeError: 'NoneType' object has no attribute 'name'

Behind the scenes there is some logic involved in for when the user provides information in the raw fact entry as well as in dedicated attribute entry fields. It would be good to provide some optional elaboration to interested users.

Possible solutions:

• Plain labels
• Add icon to entry widgets and provide tooltips to those icons
• Maybe tooltips can be connected to the entry widget itself?
• A dedicated 'help' button

The docs recommend so use Gtk.FileChooserNative for improved native look and feel.
We need to investigate if this class is indeed preferable and if there are any obvious downsides.
Once this is done and confirmed, it should be implemented accordingly.

When closing the client while still running an ongoing fact it may be preferable to warn the user.
This warning probably should be optional (set via preferences).

hamsterlib will change the layout of Fact.serialized_name. Once this has happened we need to adjust our EditDialog accordingly.

Blocked by:

• hamsterlib issue

Initially autodocs failed as they could not import gi. Once we have setup proper sitepackages on the CI server this should not be an issue anymore.

Dear all,

I wanted to add a new time entry but it was refused as being in the wrong format.

Can someone please tell me why the following text entry is not valid?

Thankfully,

~Robert

We should be consistent with our signal names. Right now there is tracking-stopped as well as facts_changed. Choose one style!

Dear all,

Is it possible to provide an icon file that can be displayed in Ubuntu Unity?

It seems reasonable to publish pytweener as a stand alone module instead of shipping our own custom version.

Benefits:

• Centralized maintenance and issue tracking.
• Transparent dependencies
• Easier for legacy hamster to incorporate any improvements

Pre-requisites:

• Double check that Toms version is actually superior to Bens.
• Get in touch with tbaugis if he intends to release 'pytweener' as a stand alone package himself.

Resources:

• Original version by Robert Penner in Action Script. Used to be here but as far as we can tell has moved to this github repo.
• Python implementation by Ben Harling. Corresponding discussion can be found here
• Tom Baugis rewrite for Project Hamster

Throughout our codebase we used controler when the proper spelling is controller.
This issue is more laborious than difficult.

Whilst it is perfectly fine for our library to raise Exceptions when things go south, our frontend should catch those and render them in an error dialog so the user is aware of them.

Dear all,

I would love to provide my feedback on the rebooted Hamster code base.

However, I am not able to build a deb package for an installation on Ubuntu 16.04 myself.

Has anyone already built package that he might want to share with me?

Thankfully,

~Robert

According to this Stock buttons are deprecated since 3.10. The new solution however is unclear.

Some people may use the following pattern:
issue@project to log their work.
It would be a great luxuray feature if we could provide a way clickable links to the relevant issue tracker url.

hamster-time-tracker provides a dedicated edit dialog to change a Facts attributes.
This should be reimplemented.

Questions:
Is it desirable to use the raw_fact entry to modify the fact (but for the description?)
It strikes me as rather cumbersome. Wouldn't it be preferable to have dedicated widgets for each
fact attribute? What do you think @projecthamster/devs ?

Version: 0.10.0

Clicking "Apply" in the editfact dialog gives the following:

Hamster-GTK started.
Traceback (most recent call last):
  File "/home/elbenfreund/.virtualenvs/hamster-gtk/local/lib/python2.7/site-packages/hamster_gtk/overview/widgets/fact_grid.py", line 112, in _on_activate
    self._update_fact(edit_dialog.updated_fact)
  File "/home/elbenfreund/.virtualenvs/hamster-gtk/local/lib/python2.7/site-packages/hamster_gtk/overview/widgets/fact_grid.py", line 120, in _update_fact
    helpers.show_error(self, message)
  File "/home/elbenfreund/.virtualenvs/hamster-gtk/local/lib/python2.7/site-packages/hamster_gtk/helpers.py", line 74, in show_error
    dialog = dialogs.ErrorDialog(parent, message)
  File "/home/elbenfreund/.virtualenvs/hamster-gtk/local/lib/python2.7/site-packages/hamster_gtk/dialogs.py", line 41, in __init__
    self.set_transient_for(parent)
TypeError: argument parent: Expected Gtk.Window, but got hamster_gtk.overview.widgets.fact_grid.FactListBox