Re: Comments

> Here are my opinions regarding the proposal on the web:
> 1) Project specific tasks:
> I agree that tasklist should support both. Source Tasks (possibly also 
> issuezilla query) would IMO always be project specific. I don't think 
> that Project specific source task list would grow to the useless big 
> list if it was persistent.
> However I see that the source tasks are "derived". Their primary source 
> is application source code. So the persistent store for them would 
> function more like a cache for these tasks. MDR could be a good place 
> for storing and managing them.

Ah, perhaps you can contribute the code for that :)


> 2) Discoverability problem (how to add source tasks?):
> I think that on-line help for task module would be sufficient. 
> Additionaly if the user uses TODO/PENDING/etc. in their source code, 
> they will find out how it works intuitively (tasks will appear in task 
> list and after clicking on them user finds out where it came from), if 
> they don't use TODO in source, source tasks list remains empty. You can 
> add a new action ("New task?") to the context pop-up menu opened when 
> right-clicking on the empty list which opens the help page (IMO users 
> intuitively right-click on the empty list if they try to figure out how 
> to add a new task).

Yes, I would like to add something to the context menu when there
are no tasks - but haven't figured out how.   (The Explorer hides
the popup handler for me so the only way I can add menu items is
to add them to nodes themselves - but when there are no nodes it
doesn't work. You can see the "List Options" action, but that's
special code written in TreeTableView; it's not possible for my 
module to add additional actions. I should file an Enhancement request
if I haven't already done so (I remember discussing this a while back).

> 
> 3) Suggested tasks:
> Context pop-up menu item like "Autofix" seems natural to me. Another 
> possibility is to have a column (next to Done) with "Autofix" button for 
> each task.

Ok. Perhaps if the exact name for the "Autofix" action was done on a per
action basis (by the providing module) it would make more sense, e.g.
for an import tool action, it could be named "Import".

> 
> 4) Categories:
> Another approach would be to have only one task list for user tasks by 
> default (named User Tasks as now) and give users option of creating 
> custom task lists of the same type. So that someone could create a new 
> task list (based on User Tasks task list) and name it e.g. "Issues".

Yes, I've thought of this possibility - it makes a lot of sense in
the issuezilla view case: I'd like to be able to create multiple
windows, one for each query (e.g. one window for my open bugs, one
window for all unassigned bugs in a category I work on, etc).  The
alternative is to use the subtasks mechanism to create query nodes
in the bug view, and have the bugs under each query. This means fewer
windows (good) but not as user friendly (more scrolling, more node
expansion).

> 5) Transient tasks:
> I think you don't need to care about this issue. Let modules that add 
> tasks manage the tasks persistence themselves. You can provide some 

Yes, this is an older issue when I had all tasks (source scanned 
tasks, user entered tasks, compiler error tasks) all going into a single
tasklist window. Then it was an issue that I didn't want some of
these tasks showing up in my tasklist files.

However, this has probably been rendered obsolete now with the
dedicated task windows.


> helper classes for doing that/ create some persistence SPI for tasks and 
> provide default implementation (or 2 default implementations - XML based 
> and memory only) for it and let other modules to provide their own 
> implementation of this persistence SPI for their tasks if they wish. 
> This modules could then implement the SPI to store the tasks e.g. in MDR 
>   or some other persistent store).
> 
> 6) Annotations:
> I think that annotating all tasks would be better. It is similar to "// 
> TODO " concept in the source - you can always see all places in the 
> source which are associated with some task. When moving mouse over the 
> annotation you could show a tooltip containing the short description of 
> the task (similarly to showing parse error on error annotations).

Ok, noted.

Thanks for your feedback!

-- Tor