Comment 3 for bug 1185041

Attaching updated diff file (for v0.9.1) and samples.
gtimelog-0.9.1__subcats_withdate__20140102.diff
gtimelog-0.9.1__subcats_withdate__usage__20140102.txt

"""Some sort of per-project subdivision sounds like a useful feature..."
I'm aware of that. I'm just sending features that i'm using for some time now (6months?) and are quite important and makes gtimelog even more usable to me.

"""I'm not a fan of configuration options that change the interpretation of data files..."""
Feature 'subcategories_enabled' if enabled unfortunately changes interpretation of data. For me used solution seemed quite logical. IMHO category levels have to be distinguishable prior character ':' that separates category and task description is found on the line. So all category levels are at the beginning of the line - near to each other. And IMO it breaks fewer data than other notation I was able to think about.
What character separates cats levels is configurable by users. So if somebody wants to use the feature he/she can decide what character to use.
What can be improved is better integration to 'Tasks' panel - so that subcategories are tree-like unfoldable.

I added 3 configuration parameters. See some comments in settings.py:
+ """If True then timestamp of the event will be present in categorized report"""
+ report_categorized_withdate = False
+
+ """If True then treat categories with 'subcategories_separator' as multi-level categories"""
+ subcategories_enabled = False
+ """Separator for levels in multi-level categories"""
+ subcategories_separator = '_'

Defaults are set so there is no change in reports after applying patch.

It is necessary to enable features in gtimelogrc to use/see features/changes:
report_categorized_withdate = True
subcategories_enabled = True
subcategories_separator = _

See also attached file 'gtimelog-0.9.1__subcats_withdate__usage__20140102.txt' and tests:
doctest_Reports_monthly_report_categorized_with_subcats
doctest_Reports_monthly_report_categorized_with_subcats_date

"""I'm not very comfortable about passing the entire settings object to the TimeLog/Reports classes..."""
I used it this way to get an access to all available settings from one place and to me it seemed that it was easier to set tests this way. It's possible to split parameters again and pass all used settings values separately.