Re: Comments

Hi Tor,
see my comments below:

Tor Norbye wrote:
> Ok. I noticed that Studio .NET was doing it that way (only showing tasks
> for the current source file) and it was appealing because
> - I didn't know what to do about source tasks in the current file - should
>   they be moved up to the top when you enter the file?
> - Should the tasks be persisted between program runs, or only as you start
>   browsing files in the current session? (It sounds like you were 
> suggesting
>   the latter, which is a good idea; I was concerned that with the former
>   scheme the tasklist would grow to the point that it would become 
> useless.)
> - I didn't have to solve all the issues of scanning filesystems, cleaning
>   out, etc. I thought about only having a "Sync..." action which would
>   scan filesystems when explicitly asked to (and this would also remove
>   tasks which are noticed to have been removed from the source).

I understand the reasons. I also saw some other reasons reading through 
the list archive. However the way that I work is that sometimes I decide 
to fix some of my TODOs in source code. So I pop up the Find dialog and 
search for all occurencies of TODO and then I look for the one that I am 
in a mood to fix. I would expect that most people work like this. For 
this scenario, showing only TODOs present in an opened file is not very 
useful. Many files in my project do not contain any todo. I do not want 
to go through the all the files before I am able to find a source todo. 
That's why I thought it would be more valuable to have them persistent.
Maybe the transient approach is sufficient for C or C++ developemet as C 
files are usually bigger than Java classes?

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.

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).

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.

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".

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 
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).

Regards,
Martin