No report with umlauts on ubuntu-11.04

I have the same problem with text in Lithuanian.

From my comment on the merge proposal:

I'm having trouble reproducing this, though admittedly it's a bit difficult for me to enter non-ascii characters.

I did add this text as a timelog entry:

¿ÀÁÂÃÄÅÆ

and then tried to generate a daily report. It worked fine for me: it fired up mutt, and seemed to send the non-ascii message. Is there something else I should be doing to try to reproduce this bug?

Hi Berry!

I copied the characters from your post and inserted them as a new entry in TimeLog.
After committing the entry, I couldn't generate any report containig this entry.

Perhaps I should mention, that I don't use mutt as mailer. I prefer a text editor to pick some information from the generated report
Some of my config-entries:
mail = gedit %s
spreadsheet = localc %s
editor = gvim
gtk-completion = True

Could that cause the problem?

Sincerely, Björn

Hi,

I also seem to have this problem with Lithunian characters.
The behaviour is a bit funny though, I seem to be able to enter any unicode characters in the first entry, but the subsequent ones break gTimeLog, with the character 'ą' for example.

> cat .gtimelog/timelog.txt:
2011-09-25 14:33: ą

^^^report works fine.

> cat .gtimelog/timelog.txt
2011-09-25 14:33: ą
2011-09-25 14:40: ą

^^^results in:

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/gtimelog/main.py", line 1633, in on_daily_report_activate
    self.mail(reports.daily_report)
  File "/usr/lib/python2.7/site-packages/gtimelog/main.py", line 1786, in mail
    write_draft(draft, self.settings.email, self.settings.name)
  File "/usr/lib/python2.7/site-packages/gtimelog/main.py", line 744, in daily_report
    format_duration_long(duration))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 0: ordinal not in range(128)

oh and:
> file .gtimelog/timelog.txt
.gtimelog/timelog.txt: UTF-8 Unicode text

Same here, but with different error (Portuguese language, using gedit as mail sender/editor):

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/gtimelog/main.py", line 1616, in on_daily_report_activate
    self.mail(reports.daily_report)
  File "/usr/lib/python2.7/dist-packages/gtimelog/main.py", line 1771, in mail
    write_draft(draft, self.settings.email, self.settings.name)
  File "/usr/lib/python2.7/dist-packages/gtimelog/main.py", line 752, in daily_report
    if categories:
UnboundLocalError: local variable 'categories' referenced before assignment

And, resolving the categories issue (I add an categories = {} before verification), the same error has arrived:

-------

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/gtimelog/main.py", line 1746, in on_monthly_report_activate
    self.mail(report)
  File "/usr/lib/python2.7/dist-packages/gtimelog/main.py", line 1772, in mail
    write_draft(draft, self.settings.email, self.settings.name)
  File "/usr/lib/python2.7/dist-packages/gtimelog/main.py", line 704, in monthly_report_plain
    estimated_column=estimated_column)
  File "/usr/lib/python2.7/dist-packages/gtimelog/main.py", line 664, in _plain_report
    (entry, format_duration_long(duration)))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 39: ordinal not in range(128)

-------

Ubuntu: 11.04
Gtimelog: v0.6.0dev

I can reproduce this in trunk.

(Sorry for ignoring the bug report for so long.)

This bug was introduced in r198.

It looks like PyGtk used to quietly change sys.getdefaultencoding() to 'utf-8' behind my back, which hid this bug for so long!

PyGI, sensibly enough, leaves sys.getdefaultencoding() with the default value of 'ascii'.

I would like to switch to storing the data in Unicode internally. PyGTK can handle this fine. Can PyGI?

>Can PyGI [handle unicode objects]?

Documentation is silent on the topic, but experiments show that it can. In Ubuntu 11.10, at least.

Fixed in trunk, will be in the 0.7.1 release.

Ignas: if there's only one entry in a day, gtimelog prints 'No work done today' and doesn't try to write the entry text to the report, so you don't get an error. The first entry of a day indicates when you started working. To get a duration of your work there must be at least two timestamps, i.e. two entries.

Fl1ppeR, the 'categories' bug is fixed in 0.6.0 final (see bug 778285).

GTimeLog 0.7.1 with this fix is now available from http://pypi.python.org/pypi/gtimelog

It'd be nice to get the 0.7.1 bugfix release into Precise, assuming it hasn't missed the deadline yet (I'm not paying attention to Ubuntu freezes).

Barry?

A gtimelog 0.7.1 .deb is available from https://launchpad.net/~gtimelog-dev/+archive/ppa for precise and oneiric.

This bug was fixed in the package gtimelog - 0.7.1-0ubuntu1

---------------
gtimelog (0.7.1-0ubuntu1) precise; urgency=low

  * New upstream release.
    - Fix reporting problems with non-ASCII characters (LP: #785578)
    - Fix panel background color detection. (LP: #924390)
  * debian/control:
    - replace X[SB]-Python-Version with X-Python-Version
    - remove ${python:Provides}
 -- Gediminas Paulauskas <email address hidden> Mon, 16 Apr 2012 10:53:52 +0200