|
|
When I load a tasklist, the list is set to sort by priority, which it does. However, it sorts the completed tasks in with the incomplete tasks, forcing me to click the sort button twice in order to get the proper order. So, instead of putting the completed tasks at the bottom, they are just sorted by priority, period.
Two things I notice. I use "Treat tasks whose subtasks are all completed as also being 'completed'". This means I don't actually have a check in the completed checkbox. This seems to be the root of the problem. When the item is checked it is properly placed at the bottom on the initial load-sort. Without explicitly checking it, only relying on all the subtasks to be complete, I have this behavior.
|
|
|
|
|
|
Found a couple more bugs which are probably related. Create a new task, then split it. The new subtasks created don't have a checkbox. The only way to get the checkbox to show is to either reload the tasklist or to set the completion percentage manually to 100%, which strikes out the task and cause the box to show up and be checked.
The other bug will probably be fixed the same way. Simply move a task "left" or "right" in the hiearchy. The same problem occurs of no checkbox and the same solution of manually changing it to 100% fixes it.
On the positive side, I like the new tools showing up as icons in the toolbar and I like the more Windows-like multiple selection.
|
|
|
|
|
thanks for the extra hints, but i've hit a snag with the original bug: i can't get it to happen on my dev box, although i did see it on my work machine.
could you possibly do me a 'step-by-step' starting with an empty tasklist.
as for the other bugs, they relate to adding support for showing parent tasks like folders (forgot to add this to the release notes) and should be easy to fix.
rgds
.dan.g.
AbstractSpoon Software
|
|
|
|
|
its okay valik, i managed to reproduce the original bug and fix it, the others too, in RC2.
rgds
.dan.g.
AbstractSpoon Software
|
|
|
|
|
* bug fix for initially incorrect sort when 'treated tasks with completed subtasks as completed' preference is enabled (thanks to Valik)
This bug is fixed. Thanks for such quick work on it.
* bug fix for missing checkboxes when using custom checkbox image (thanks to Valik)
This bug may be fixed, however, it doesn't help me. I don't use a custom checkbox image. I'm sorry that I failed to mention it or if what I said made you think that I was (I really just forgot about the feature). So, I still have the same issue as before when splitting/moving a task.
|
|
|
|
|
its funny the number of bugs i've found by misunderstanding someone's bug report. makes me wonder sometimes just how many bugs can easily exist in a non-trivial piece of software.
i'll look at it again tonight, valik, and thanks for the prompt feedback.
ps. do you have the checkboxes in the tree or in their own column?
.dan.g.
AbstractSpoon Software
|
|
|
|
|
Another option I forgot about. "Display completion checkbox next to task's title" is checked, so its in the tree and not in a seperate column.
|
|
|
|
|
All fixed now, .dan.g. Thanks.
|
|
|
|
|
Hi,
sometimes the expansion buttons of my tasks disappear.
This happens when I resort the tasklist with clicking on certain column headers. What actually happens is that the task titles shift a little bit to the left, eventually hiding the expansion buttons partly or sometimes entirely.
I have not been able to find a reproducable schema for this yet, but maybe someone else has seen this before.
-tafkat
|
|
|
|
|
hi tafkat
you may find that this is standard tree control behaviour when there is a horizontal scrollbar. the tree control is attempting to make as much of the item text visible as possible so it scrolls right until the left hand edge of the text is flush with the left border of the window.
to test this theory try the following:
1. find an item with a long title and select it
2. resize TDL until some of the text is clipped on the right
3. sort any column
one possible solution is for TDL to save and restore the horizontal scroll position when doing a sort (although i'm not sure how easy this will be)
.dan.g.
AbstractSpoon Software
|
|
|
|
|
Ahhh, yes that's it.
I didn't even realized the scrollbar - stupid me
.
I think this is a too minor issue to invest too much time in it.
-tafkat
|
|
|
|
|
Part II - the TDL I need.
preface: Sorry if I come off demanding, not grateful, and too long. But that's me when I like a tool. Also, uplease nderstand that the following is a hodgepodge between use case, specification, demand, and dream
Post-scriptum-preface: in the following, when talking about "times", I mean a duration (minutes, hours, weeks,...). Only a "date" means a time point, which is fine for me with resolution of one day.
I'm currently using TDL for planning software implementation details: it is a guideline to break down tasks (house rule: tasks for which are planned more than 4h have to be split up), as a tool to calculate times for milestones and completion times, and a "red alert" button when the schedule is slipping. The latter requires to keep the list up-to-date. TDL by far beats previous tools: Project on simplicity and price, Excel on hierarchy and commenting, and Word on tabulating and automatic calculation.
So here's the setup I need (much of this is possible with TDL, not everything would have to be exactly like this, this is my idea/spec/use case):
(1) Tasks.
Task hierarchy + comments as it is now.
Each task has estimate, time spent, completion checkbox, priority.
I can filter out all tasks below a given priority, which also means they are excluded from all calculations (aggregated times, due dates, etc.)
Order of tasks gives order of execution. If the schedule is slipping, but my release date is fixed, I can filter out uncompleted low priority features (I assign a lower priority only to features that can be kicked from the release, and that's the only real need I have for priorities.)
times can be entered as 2w1d3h20m (wwek/day/hour/minute), and are displayed as such. I can configure how many hours in a day, days in a week, weeks in a year. (I would avoid month as a unit of time, as a variation of 10% is not acceptable)
Parent tasks can not have no individual time associated, but they atomatically aggregate the time of all children (recursively), and are complete if and only if all children are complete. If there is a child task which is not complete, and has a zero estimate, a "+" is appended to the parent's estimate to indicates that the total time may be longer, since estimates are missing. This "+" bubbles up, of course
I have a shortcut that allows me to split up a leaf task into two two sub tasks: Task A is split into A1 and A2, where A retains onl the name, A1 inherits all properties of A (comment, times, dates, etc.), and A2 is a completely new task.
optionals track for each task *when* time has been spent on it (but I see that as a separate tool).
"Completion" date, which works as a fixture for the milestome calculation below. Or, alternatively (thinking about, I prefer it), I can insert "away from project" tasks, which go into date calculations, but not into duration aggregates. This can acocunt for holidays, sickness, and "the server caught fire" days.
(2) Changes
This schedule does change. New entries are set to blue. For a task tree, or the entire list, I can select "accept schedule", which turns all items to black, but new items will be blue again. How to handle changes to existing items?
(3) Milestones
Milestones handle dates and aggregate times, but no time can be allocated to them directly. Currently I could live with "milestones" only on the top level, I have some ideas/uses for nested milestones, too.
Technically, A Milestone is the parent of a task tree that are required to compleate this milestone. Visually, however, I'd like to have them *below* the tasks to complete. I think the "nicest" implementation would be:
mark a parent task as milestone, which enables the "special behavior", and display aggregated times below the milestone (and all sub tasks)
A milestone works differently from tasks. It has the following dates assigned:
- planned start date
- planned completion date
- actual start date
- estimated completion date (calculated)
- actual completion date
Estimated completion date is calculated as follows:
- for completed tasks, the total time used on them is taken into account.
- for incomplete taks, the max of estimate and spent is taken, and multiplied by the "slip rate" of completed tasks of this milestone.
- total time is adjusted by the slip rate of previous, complete milestones
- (slip rate is max(1, sum of time spent / sum of stime accumulated))
- start date is actual start date if given, expected start date otherwise.
Milestones have aggregates: subtotals for the Milestone itself, and total aggregates for all milestones. Numbers: Original Estimate, Estimate for changes, Total estimate adjusted for slip rate, total time spent.
Other things
I have some problems with "unexpected automatic" handling (automatic setting of dates, etc.) Generally, I would make times and dates either (a) entered by user, or (b) calculated automatically without possibility for the user to enter. Only on a few chosen places I would add automatic, but when in doubt, rather leave it empty/unmodified.
(e.g. when clicking the start clock, and the corresponding milestone has no start date set yet, it is set to the current date).
There is a dozen minor things in the current TDL, independent of all this drivel. But maybe this is a third post
Phew. Thank you for reading. It's not that I didn't have anything better to do. I just... don't like cleaning.
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
thanks peter. i've printed it out so that i can read it slowly and understand it fully.
rgds
.dan.g.
AbstractSpoon Software
|
|
|
|
|
thanks again, peter.
whilst i ruminate on the more structural issues, i propose to implement the following simpler items for the forthcoming release:
1. split task (only into 2 subtasks? or 3, 4, 5...?)
2. if time tracking and the start date is undefined, then set to current date
3. change some of the default preferences to be more 'useful' (you're welcome to more precisely define your 'ideal' setup).
4. append '+' or '-' to accumulated values if subtask attributes are undefined (note: '-' would be used if 'earliest due date' was specified but some due dates were missing)
rgds
.dan.g.
AbstractSpoon Software
|
|
|
|
|
[edit]: general: just keep in mind that this is a "typical customers wish list". You have to make me fight for every feature, why I really need it, or if we find a simpler solution [/edit]
(1) yes, just two. a third, 4th etc. task can be added normally using Ctrl-N
The problem I am trying to solve with the "split" is this:
To split a task, I typically create a new task above, then indent the task to split up (so it retains it's original estimate, etc.). That's most effective, but not intuitive.
A few times I added a child task, noticed the estimates were gone (hidden, actually), unindented the child task, transferred the settings, and indented it again.
Maybe it would even be enough to offer a "make current task child of a new task", but that's an awkward action noone understands.
Q: would it be possible to some kind of macros for things like these? I could set it up myself, and not bother you. But that depends on your code base.
(2) Main point was: mostly disable the automatic time assignment (e.g. when I start a new task, current date is assigned a "start date", and I have to remove it) You already have many users, it's not easy to change such policies, I know...
(3) OK, I'll go through the preferences in general, seeing what can be renamed to make it more obvious (or even removed. I'm a big fanatic on "no options" - but that doesn't work with your app I know...)
Some minor things:
the dime displayed in the estimate has maaaany digits, the display is awkward, and input length is limited. so when I have the chess clock running, and want to add some 10 minutes I forgot to have it "on", I first have to do an awkward calculation, then delete the lesser digits auf the auto value, so I can edit at all.
The return key, to get back to the list. Any other key would be fine for me I'll dig into your code base...
I can't get rid of the "due date is earlest" option. top Task has no date assigned child 1 has 24th, child 2 has 30th. Tp task alwas displays 24th or earlie, no mater how I set the "due dat is earliest.." option, or assign a date to the top task
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
(1) you can also try copying the selected task (ctrl+C or by context menu) and then pasting it onto itself (ctrl+V or context menu).
with this in mind i propose to do a 'real' split for the split task functionality. ie split time estimate, make first subtask due in half the time, etc
(2) there is a preference on the Tasks>Defaults page to disable this. do you think it should be disabled by default?
i'll look into the "due date is earlest" issue.
.dan.g.
AbstractSpoon Software
|
|
|
|
|
(2)
My bad, I never made it to that page
(1)
perfect! (if you make Ctrl-V to paste "after item".)
I don't think a split is necessary then. while it looks like a cool feature, times never distribute evenly. Maybe ask others what they think.
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
actually, the split feature is trivial to implement so i'm going to do it anyway.
on a related point, peter, splitting a task automatically raises the idea of linking subtasks, such that changing the due date of one would change the start date of any siblings which began on the original due date.
eg.
task 1 starts on 11/11/04 and is due on 14/11/04
task 2 starts on 14/11/04 and is due on 17/11/04
if i change task 1 to be due on, say, the 15/11/04 then this would bump all the remaining sibling tasks on by one day.
your thoughts?
.dan.g.
AbstractSpoon Software
|
|
|
|
|
I wouldn't 'mess' with user choices more, except when he says so explicitely.
When running a project, there's always the question "why did it take longer than the plan", and you want to compare the planned schedule with the actual.
For that, I would keep the original due dates, and *never* modify them automatically (except perhaps when the user says "recalculate due dates now"). In parallel have a column "expected completion date", which includes all time exceeds.
For me, TDL is an important tool *not* to simply readjust the due dates when one part of the project slips.
I hope to find the time to look at the code base any time soon. I have no feeling for what can be done, what not, and at which effort.
For the save/load prefs:
A first step would be:
- Save all settings to an (XML) file
- Load all settings from an (XML) file
Now, the next question is: can any combination of settings be applied to any task list? Or is there any data that changes it's meaning when you change settings? (this would be bad)
Can we move *all* settings to the todo list file? (I am not sure, maybe you still need the "global" options, maybe you should split up options - UI configuration and "processing" configuration. That seems more poerful, but less transparent)
In this case, any todo list could act as a template. I could configure it, and give it to my coders.
"Load settings" could accept either a specific setting file, or another ToDoList. Or maybe the separate config files are not needed at all.
Another thing: Is there a reason you named the files ".xml"? I thought picking a nice extension (like ".todo"), and associating TDL with it would be the way to go.
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
>> wouldn't 'mess' with user choices more
sorry, i didn't make myself clear. this would only ever be a user preference (another one! )
>> For the save/load prefs:
todolist can already save/load settings from an .ini file courtesy of MFC, and you can enable this functionality simply by dropping an empty .ini file into the same folder as the executable.
>> Is there a reason you named the files ".xml"?
yes. initially i used '.tdl', but when i came to try and parse this in a web page in one of the popular browsers it failed because the extension was _not_ '.xml'. and since this was part of the 'selling' point (that the raw tasklist' could be parsed and display by the same javascript in all browsers) i stuck with '.xml'. one thing i was thinking was adding a preference (!) to allow users to save tasklists to a custom extension which would then be associated with TDL on their machine.
.dan.g.
AbstractSpoon Software
|
|
|
|
|
(1) as said, I'd rather have it as separate column, or make this an explicit command. It's one of the preferences that makes it less transparent what's happening. But maybe others see it important enough to make i automatic.
(2) good to know. per-TDL-options, Save/Load/Load from TDL would be cool though
(3) You can associate TDL with an extension, when saving, allow to chose between "xml" and ".todo" (or .tdl or whatever you like). "Associate with [extension] is a setup option.
Yes, I am "anti-option". This thought is not by me, but pretty much sums it up: Every option is a design decision, that was avoided.
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
>> Every option is a design decision, that was avoided.
do you also think that keyboard shortcuts should be hard-coded ?
.dan.g.
AbstractSpoon Software
|
|
|
|
|
eh!
It's an opinion, not a rule. And your app *needs* to be configurable. (But I *do* think less is better.)
But, thinking about it, hardcoded keyboard shortcuts have their benefits. Sitting down on my coworkers PC I can edit the TDL with the same keys as at my PC. How do I get my "improved" assignments from my home PC to my work PC? You can much easier embed keyboard shortcuts in all documentation/UI feedback. Macro recorders will work much better with TDL, I can take my macros with me.
No, don't hardcode them... I'm just playing devils advocate
The problem is: you have to think long and hard about every such decision, and most of them are cast in stone.
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|