Re: Tasklist UI proposal

Tor Norbye <[email protected]>
Newsgroups gmane.comp.java.netbeans.modules.tasklist.devel
Organization Sun Microsystems
Message-ID <[email protected]>
[email protected] wrote:
> 
> 
> 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?

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.

I haven't seen any errors in this area yet but I get a little nervous if 
you're
actually trusting the tasklist with real data.

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

In other words, it's going to recognize   <!-- TODO --> in HTML,
<%-- FIXME --> in JSP's, XXX in .txt files, etc.

> 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?

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

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.

> Additional task attributes:
> One thing that I would like to have is the ability to put estimated durations
> against todo tasks and time remaining for tasks, and an action that could
> display the total estimate (time or time remaining) for a list, or for user
> categories (subcategories) in a list.  Alternatively, perhaps the todo list
> could have a status bar that shows the number of items, estimated total
> duration, number over-due, etc.

Yes. I forgot about this in my UI writeup. I want to add a "Percent 
Complete"
attribute - which would be hooked up to the Done toggle (e.g. modifying 
percent
complete to < 100 sets done to false, else true, and vice versa).

I also really want the due date. I've been holding off on this because 
(well,
honestly, I haven't had time to work on the tasklist lately, but also 
because)
I'm waiting for Hanz' "office" code since he has this functionality already.

-- Tor
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.