Re: Tasklist UI proposal

Hi Tor,




>> Hi Tor,
>>
>> Thanks for all you've already done on the task list module.  I use it a lot.
I
>
>^^^^^^^^^^^^^^^
>
>Uh oh. You're making occasional backups of the tasklist.xml file that lives
>in your {userdir}/system/TaskList directory right?

Yes, I regularly backup my userdir.  But I haven't had any problem yet (with the
tasklist, that is)...

>I should probably go and make sure that the saving routines are more
>industrial
>strength. I fear that if some error occurs during saving you'll lose
>your data
>(e.g. if an exception is thrown writing out a task, the rest of the save is
>aborted etc.)  I should do exception catching on a per task basis, and I
>also
>had a task filed for myself (in the tasklist, not issuezilla :-) to use
>a scheme
>where instead of just deleting the old version, I rename the current
>version to
>tasklist.xml~ and save as tasklist.xml. And only at session start - so
>if something
>fatal should happen, you can always go back to the version you had when
>you started
>the IDE.

Sounds like a very good idea.

>> have a couple of suggestions:
>>
>> For "Source Code Integration":
>> It would be nice if the mechanism for finding todo items in source was
>> extensible, so that other modules could add the ability to recognise todo
items
>> in the data types that they support.  The mechanism might typically be using
>> regexps as described for Java, but it would be good to allow for other
>
>Note -- it's not limited to java, it does the regexp matching on ALL files
>in the editor that provide a document.

While regexps should generally be sufficient, I suspect that you'd want to use
different regexps in different types of files.  For example, if someone created
HTML doco for the todo module you wouldn't want it to false recognise a
description of how todos appear in Java code as a real todo.  You only want the
ones appearing in HTML comments - you need a more specific regexp.

>> techniques that are appropriate to particular data object types.  For
example, I
>> might have an XML format that isn't primarily for storing todo items, but
that
>> can contain todo annotations as XML.  (e.g using a different namespace from
the
>> rest of the document).  I'd like to be able to recognise them and have them
>> appear in the to do list in exactly the same way as Java todos.
>
>Do you think the above would solve most of your problems, or do you have
>a more specific example of what you have in mind?

Most likely, this would suffice.

>
>I want to try to avoid "over-engineering" the tasklist APIs, since once
>other modules start depending on it, I can't change. I want to be able
>to let other modules open new category tabs (see the UI spec) so they
>can certainly add tasks, even to new tabs, but the question is should they
>be able to hook into arbitrary parsing for any source file?
>
>>
>> I think that it would be good if the todo list didn't just show the todos for
>> the current source file, but for all open source files.
>
>Hm. That was my initial thought, but seeing it (current sourcefile only) in
>action with studio.net seemed to work pretty well.
>
>The problem with showing ALL tasks is
>   -- when do I do the parsing? In the background?
>   -- when do I update the tasks? (To remove tasks that have been deleted
>       from the file, change line numbers, etc.)
>   -- how does the user navigate them? The filename and line number columns
>       aren't visible by default - and making them so would cut into the
>       width of the summary/description field which seems pretty important.

I see your point.

>
>> I think that it would be useful if the todo recognition functionality was
also
>> exposed as a search type in the "Find" dialogue.  That is, you should be able
to
>> find all todo items in the source files in a selected set of folders.  By
>> selecting all files in the search results and opening them, you would see all
>> their todo items (if the suggestion above is accepted).
>
>I'm not sure if the Find dialog allows me to plug in additional
>components, but
>even if it did, would it be appropriate for it to be there? Seems like a lot
>of "specialized search" functionality could go there.

Its pretty easy to add to add new search types to the find dialogue.  You create
a SearchType subclass, with an appropriate GUI panel for specifying the
criteria, and register it in your XML layer in Services/Search Types.  The
search dialogue already contains specialised searches (e.g. CVS status).  I
think its nice to see consistency like this in the IDE.  However, the display of
search results isn't that satisfactory, and wouldn't be what you particularly
want for todo items, so what you describe below also makes sense to me.

>
>My original though (under showing all files above) was to have a "Scan
>Sources..."
>context menu in the Tasklist which would bring up a search dialog where
>you can
>select filesystems to search.    This would add, update and remove tasks
>in the
>tasklist as appropriate. So there wouldn't be an automatic sync (as I do for
>"current source file", you would sync by running the Scan Sources command.


>
>I want to add a "Percent
>Complete"
>attribute

That'd be great.

Cheers,
Brett.