gtg-user team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Wed, Apr 14, 2010 at 01:51:33AM +0200, Tomasz Melcer wrote:
> Task requirements. Some tasks can only be done in specific places, like
> home or work. Other need specific facilities, like access to the
> Internet. Work view is a good idea, but it shows too much things for me.
> My solution for that is to make tags like @home, @work, @shop,
> @shop:grocery (subtag of @shop), @net (all things that need access to
> the Internet), @person:john_smith (subtag of @net, because I can contact
> him by email). But I still have some issues:
> * How to check which tasks can be done when being at home and having
> connection to the Internet? (@home, @net) I can browse through tags, but
> I'd like to simply see everything possible in one place.
> * How to make a task require both @home and @net?
> * How to identify things that don't have any of these tags (but might
> have other tags, like related to projects they belong to)? I.e. a task
> might already have a tag @journey_to_Japan, so it wont be visible in the
> category "Tasks without tags".

The new 0.3 codebase has added a functionality called "filters" which
provide for views into the task tree.  There are four stock filters
provided: workview, active, closed, and notag.  See filters_bank.py for
details.

The goal (as I understand it) is to expound on this functionality and
provide a user interface for creating custom filters, which would then
be added via FiltersBank::add_filter(filter_name, filter_func).

So you could imagine, for instance, specifying a tag filter such as 
"@home and @net" or "-@journey_to_Japan".  I don't know what the UI
would look like exactly, but there are a variety of other tools out
there with tag-based searching that could be modeled after.

The custom filters would then show up in your tag pane view.  Indeed,
'All tasks' and 'Tasks with no tags' are implemented as filters in the
0.3 branch (see taskbrowser/tagtree.py for where they plug in).

Currently the codebase only handles pre-defined hard-coded filters, so
some work would need to be done to make it take and use a user-specified
list of filters.  So as a near-term workaround you could do similarly in
a private branch of your own if you'd like to construct your own custom
filters.  Or, if you want something which could be considered for
upstream inclusion, work on modifying tagtree.py, browser.py, and so on
to use a list of filters instead of hardcoded active_filtered_tree,
notag_filtered_tree, and the like.

> Task templates. I run a series of lectures at my university. For each
> lecture I need to do a (fixed) set of tasks, there's almost 40 of them
> (http://files.exroot.org/dump/tasks.png) with a complex dependency
> relations. This set of tasks needs to be repeated for each lecture. I
> don't want to reenter all the tasks by hand each time. To solve this
> problem I wrote a simple python script to import a set of tasks from a
> custom text format. A better solution would be to firstly prepare a
> "template" inside GTG, then make a deep copy of it -- a good idea for a
> plugin, I guess. Is there another way to do this?

I'd love to see more discussion of this idea, as task templates is
something I'd really like to see myself as well.  Have you posted your
import code to a bzr branch?

We have an import-from-json plugin that I wrote, which might be a good
starting point for this.  My thought is that perhaps it should permit
some substitution parameters (so in the GUI you'd select the template
and then specify the lecture name, and the tasks would be constructed
on import to include the lecture name in the task title).

The export plugin already supports being able to emit tasks in multiple
formats, so one thought would be that it could have the JSON format
added as an output format.  This would permit you to construct a
template in gtg, export it to a file (in, say ~/Templates or
~/.local/share/gtg/templates), and then the import plugin could be used
to import them (and substitute in appropriate values).

Alternately, you could create a completely new plugin for Task-Templates
and just use the import and export plugins for reference.  This might be
best if you want to maintain the plugin yourself.

> Projects and tasks. My projects usually contain one or more tasks and a
> repository of data (documents, links). Going from a task to its project
> repository should be easy... but now it would involve making a link from
> each task by hand.

Interesting, yes this is a work flow that gtg doesn't address yet,
although there is a plugin for associating tasks to tomboy notes.

> Task names. My tasks are often very similar across different projects.
> For example I might need to make a reservation for a room for two
> different lectures. Now to distinguish both tasks I would have to place
> a project's name (in this case, a lecture name) into tasks' titles, but
> I often forget about that when creating tasks. From what I see, to
> identify which project a given task belongs to, I always need to place
> project's name into the task title. I don't want to use tags for that,
> because I use them now for task requirements (if I started doing so, I'd
> lose the possibility to list all tasks without requirements).

Yeah, I've run into this myself, even when I can use tags to
differentiate.  For example, I maintain several different computers and
while I give separate tags for each computer, if I write a task like,
"Check why X.org is not loading", it's not clear *which* computer that
applies to from a general glance, so I end up adapting to gtg by writing
it "Check why X.org is not loading on foobar" just to be extra clear.
In theory just knowing the tag should be sufficient, but when you have
an appreciable amount of tasks it really isn't.

Bryce