|
Hi H,
Thanks for the advice.
I just tested the script. Great work, works like a charm and definitely fills a gap!
1.) The offered GUIs:
a) It will be necessary (for me) to adapt it a little to my needs. I do not need 'risk' and 'cost', but that's easy to change, isn't it? E.g. by not simply offering the GUI like 'Gui, Add, Text, xm y+10 , Cost' by using ';'. This way it's easier re-change it if 'risk' and 'cost' suddenly get important for me, too. Or will a problem occur if I handle it like this?
b)) The more difficult part will be to ad GUIs that are not offered at present. Frankly, I'd like to leave that in your hands
I would like to suggest that you ad all the editing controls that ToDoList offers. Thanks in advance.
2.) 'Due Date'
These are the only little "bugs" in your script. If I create a new task and do not check the checkbox of 'due date' I still get a task with a 'due date' = today. Another "problem" regarding the creation of a 'due date' is that it always put in the time.
Would it be possible to have two different GUIs for that? ToDoList differs, too and the user can choose the time.
3.) You wrote: "Creation and modification dates are not user editable (well it can be - but I cannot see why you would want to)"
There are very good reasons to offer an editable "creation date'.
a) Everyone who starts working with ToDoList will probably transfer her/his old and older lists or general tasklist into a ToDoList tasklist. Maybe even tasks that are completed. Doesn't make much sense for them to have a completed date 09-10-2007 and a creation date 12-05-2011, right?
b) Another example is my own work. If I'm on a business trip I'm carrying my ToDoList on a write-protected SD-card around but I'll never edit my tasklists on another computer because I don't want to have some contagious virus etc. on my computers. The creation date (for me) is the date when the tasks steps into my life. So If I come back from a business trip I always have to go through the process to change the date on my computer to the past and then create the task to get the right 'creation date'.
This first version of the script is not only a good start. It's really good. Thanks again.
Cheers,
Jochen
P.S.
Would you like to get future replies regarding your script here or should I use the AHK forum?
|
|
|
|
|
TCP_JM wrote: a) It will be necessary (for me) to adapt it a little to my needs. I do not need 'risk' and 'cost', but that's easy to change, isn't it? E.g. by not simply offering the GUI like 'Gui, Add, Text, xm y+10 , Cost' by using ';'. This way it's easier re-change it if 'risk' and 'cost' suddenly get important for me, too. Or will a problem occur if I handle it like this?
Sure. My intention in to add an option dialog where you can choose which fields you wish to include in the GUI. My main goal at this point was to ensure that all the types of inputs were covered.
Should you comment lines out in GUI Creation - just make sure that you comment it out as well in the "save:" subroutine as well (should not be a huge problem - will be overwritten by a blank, but if there is a default value then you will lose the field).
TCP_JM wrote: b)) The more difficult part will be to ad GUIs that are not offered at present. Frankly, I'd like to leave that in your hands
I would like to suggest that you ad all the editing controls that ToDoList offers. Thanks in advance.
I agree, and with a field selector - this should cover both a and b of your request.
TCP_JM wrote: These are the only little "bugs" in your script. If I create a new task and do not check the checkbox of 'due date' I still get a task with a 'due date' = today.
Thanks - easy fix for this - I am not checking the status of the checkbox field.
TCP_JM wrote: Another "problem" regarding the creation of a 'due date' is that it always put in the time.
I will see what I can do. Dan represents time+date in a single variable - and this was easiest for me to do. For consistency it is probably best to keep it the same as for TDL (though perhaps with an option to hide the time). Alternatively I can add an option as well where the user can specify one of three formats (date/time separate, joined, or date only) - should not be too hard (I hope!)
TCP_JM wrote: a) Everyone who starts working with ToDoList will probably transfer her/his old and older lists or general tasklist into a ToDoList tasklist. Maybe even tasks that are completed. Doesn't make much sense for them to have a completed date 09-10-2007 and a creation date 12-05-2011, right?
I agree - but do you actually use creation date for any filtering/reporting/display purposes? Would it not make more sense to set start date here? I would (once this project is filtered) write a change log for TDL which will heavily use creation date and modification date to report on tasks that has changed.
Adding it will be quite simple though (but once introduced I will disable it by default)
TCP_JM wrote: b) Another example is my own work. If I'm on a business trip I'm carrying my ToDoList on a write-protected SD-card around but I'll never edit my tasklists on another computer because I don't want to have some contagious virus etc. on my computers. The creation date (for me) is the date when the tasks steps into my life. So If I come back from a business trip I always have to go through the process to change the date on my computer to the past and then create the task to get the right 'creation date'.
Again - start date makes more sense to me in this use case - but I will add it in any case, even if it is just to say thanks for your beta testing!
TCP_JM wrote: Would you like to get future replies regarding your script here or should I use the AHK forum?
Either is fine for me - I will add updates there and receive e-mails automatically here (as long as you reply to a post of mine!) and there. I copy your comments for offline use as well, so it really does not matter that much for me.
This raises another question for me: Should I post a message about updates here (or only on AHK forum)? It is still in the testing phase - so I would not want a permanent link yet at the top of the page (if it ever does get to that phase that Dan feels comfortable in doing so).
|
|
|
|
|
capital H wrote: Should you comment lines out in GUI Creation - just make sure that you comment it out as well in the "save:" subroutine as well (should not be a huge problem - will be overwritten by a blank, but if there is a default value then you will lose the field). Thanks a lot. This sort of thing is exactly why I was asking
capital H wrote: I will see what I can do. Dan represents time+date in a single variable Thanks again. Interesting. Two editing fields in ToDoList but only one variable.
Creation date, start date, due date, completion date are all serving another purpose.
At first, when I started to work with ToDoList two years ago I used 'due date' more than once where 'start date' would have been correct. The main reason for this was that the menu 'view > filter' didn't have the option 'show > tasks started by...'
But Dan was kind enough to implement that filter when I requested it.
'Creation date' is simply the day when the task steps in my life, when I become aware that something has to be done.
'Start date' is when I have to start working on something to get it done in 'due time'.
A correct 'creation date' is a very valuable information for me.
capital H wrote: but I will add it in any case, even if it is just to say thanks for your beta testing! My pleasure.
capital H wrote: This raises another question for me: Should I post a message about updates here (or only on AHK forum)? It is still in the testing phase - so I would not want a permanent link yet at the top of the page (if it ever does get to that phase that Dan feels comfortable in doing so).
It depends on the update. I suggest:
If it's a very big one -> ToDoList message board -> Details in the AHK forum.
If it's just a small update -> AHK forum only.
Your script provides something big like the calendar or the gantt viewer. Therefore it deserves a link at the top the page when you finished the work on that script and everything will be fully operational. But that is obviously up to Dan to decide.
In the meantime (and later on) -if you agree- I would like to add a permanent link on the AHK page of ToDoList that lead to the AHK forum. If you would like to have a specific text describing your script, no problem at all.
|
|
|
|
|
Hi H,
capital H wrote in the AHK forum: Requirements
Requires AHK_L.
Although it is not a requirement, it is recommended to run with TDL v6.3.7 or above - as the frequent reloading of tasklists may cause increased memory usage (fixed in 6.3.7)
It could be that AHK_L is a must be for your script.
I have AHK_L on my notebook and AHK on my netbook. I ran into problems when I tried to use your script on the netbook.
E.g.
Error: Parameter #2 invalid
Specifically ProcessPath
...
---> 009: Winget, PathToTDL, ProcessPath, AbstractSpoon
The program will exit
At first I thought that the reason for that might be a "complicated" path to the folder of ToDoList (Umlaute etc.). But that is not the reason.
You are runnig AHK_L v1.1.03.00 and it took me a while to find out that a new sub-command was added in version 1.1.01.00 / July 30, 2011: WinGet, OutputVar, ProcessPath. This error is easy to solve by telling the script where to find ToDoList.
After that I ran into:
Error at line 98.
The following variable name contains an illegal character:
".childnodes"
The program will exit.
I couldn't find a reason for that. Any idea would help. I would very much like to stick to the "normal" AHK on my netbook.
I can't tell if a another error message will pop up after the the ".childnodes-problem" is solved.
What I would like to ask is if it would be possible to make sure that the script runs on AHK_L and AHK?
If I'm asking too much, just tell me. Thanks for understanding.
Cheers,
Jochen
|
|
|
|
|
The .childnodes is part of the XML processing. Unfortunately there is no way to do this in AHK that I am aware of except if I write my own XML library. I am not willing to do this as (1) this would be an insane amount of effort and (2) Dan uses MSXML as well, and for data security I would rather use exactly the same library as Dan.
Alternatives
1) Compile the script to exe and run as exe (with AHK then your default installation)
2) Keep the AHK_L exe somewhere (just unzip from the install - do not install), and write a loader script (in vanilla AHK) that runs the script (one line of code - run %PathToAHK_L% %PathToScript%)
3) I can also see if I can find a place to upload binaries - which you can run directly - once in a more stable state this will probably be a good idea in any case.
|
|
|
|
|
capital H wrote: I am not willing to do this as (1) this would be an insane amount of effort and (2) Dan uses MSXML as well, and for data security I would rather use exactly the same library as Dan. That's understood and especially if it's such an amount of work.
capital H wrote: 1) Compile the script to exe and run as exe (with AHK then your default installation) Exactly. That "workaround" came to my mind, too. I run all my scripts as exe files whether I call a call a script once or if it runs all day long.
At present (in the testing phase) I will try this:
capital H wrote: 2) Keep the AHK_L exe somewhere (just unzip from the install - do not install), and write a loader script (in vanilla AHK) that runs the script (one line of code - run %PathToAHK_L% %PathToScript%) Thanks for your help.
Last but not least a little suggestion:
Would it be possible to offer different options regarding the creation of a new task like ToDoList offers that in the menu 'new task'? I suggest a dropdown field and the option "new task below selected task" could be the default. Just an idea...
|
|
|
|
|
TCP_JM wrote: I run all my scripts as exe files whether I call a call a script once or if it runs all day long.
Me too - trying too figure out which instance of autohotkey.exe relates to a rogue script in task manager is too difficult (and I have rogue scripts far too often!).
TCP_JM wrote:
Last but not least a little suggestion:
Would it be possible to offer different options regarding the creation of a new task like ToDoList offers that in the menu 'new task'? I suggest a dropdown field and the option "new task below selected task" could be the default. Just an idea...
Well, yes and no.
No because the new task creation is actually handled by ToDoList.exe, and not my script. This means that wherever TDL creates the task, will be where the task is.
Yes, because I can handle new task creation myself (and if you can remember this is the way I did it initially), but I am not keen to go back to this approach (mostly because of the lack of knowing what the default values for fields will be).
Yes (and this is the current plan) because I can intercept *any* of the TDL new task creations - and work from there. It is on my Todolist, but will be limited to the new task options with keyboard shortcuts (as I cannot intercept menu commands - though once this tool is more complete I may make a feature request to Dan - but I first need to figure out what the feature request will look like).
Yes (this is probably better, but I need to think about possible consequences) I can delay the task creation (via the postmessage command) until after you have pressed save. I can then have the default dropdown correspond to whatever shortcut key you used.
|
|
|
|
|
Three times YES and only once NO. Promising.
My next idea might be not the best one on earth but...
How about this:
At first your script creates a new task in ToDoList and after that your script starts to work on that task outside of ToDoList if I'm not mistaken.
Now. If your script would offer the droplist it would offer different options. The idea would be to code the script in a way that it first sends the postmessage code for that particular 'create task' option that the user has chosen in the dropdownlist.
E.G.
PostMessage, 0x111, 32799,,, AbstractSpoon (for 'new task below selected task) or
PostMessage, 0x111, 32807,,, AbstractSpoon (for new subtask at bottom of selected task) and so on.
ToDoList will create then the task according to the PostMessage (or SendMessage) Code and after that you script can start working on that task outside of ToDoList.
Droplist
Option 1 Option 2 Option 3 Option 4 ...
| | | |
Postmessage Postmessage Postmessage Postmessage ...
Code for Code for Code for Code for
Option 1 Option 2 Option 3 Option 4
| | | | |
---------------------------------------------------------
|
all the other commands in the script
because they are the same for every option
|
|
|
|
|
TCP_JM wrote: At first your script creates a new task in ToDoList and after that your script starts to work on that task outside of ToDoList if I'm not mistaken.
Correct
TCP_JM wrote: Now. If your script would offer the droplist it would offer different options. The idea would be to code the script in a way that it first sends the postmessage code for that particular 'create task' option that the user has chosen in the dropdownlist.
E.G.
PostMessage, 0x111, 32799,,, AbstractSpoon (for 'new task below selected task) or
PostMessage, 0x111, 32807,,, AbstractSpoon (for new subtask at bottom of selected task) and so on.
ToDoList will create then the task according to the PostMessage (or SendMessage) Code and after that you script can start working on that task outside of ToDoList.
I will consider it.
The problem is that currently I do not load the task (with say existing values for Risk, priority, colours, due date, start date, etc) - but I plan to someday. With this approach I cannot ascertain what the default values would have been (for the ones that are customisable/inheritable). If I can find a way around this - I will implement it - if I cannot - data accuracy trumps ease of use every time in my book (since you can move the task to where you want it).
|
|
|
|
|
capital H wrote: I will consider it. Thanks. Highly appreciated.
capital H wrote: ...data accuracy trumps ease of use every time in my book Absolutely!
|
|
|
|
|
Can you have a look at the newest version posted
It is not where I wanted it to be - but I think it is closer. Unfortunately I have a bunch of stuff for work that I have to do this weekend - so no progress will be made in the next week or so.
|
|
|
|
|
capital H wrote: Can you have a look at the newest version posted Yes, of course.
capital H wrote: so no progress will be made in the next week or so No problem. That gives me more time to test the new version of the script
We are not under pressure here, are we? Haste makes waste.
"Have a nice WE" - I have to work, too.
|
|
|
|
|
First of all:
Thank you very, very much for "creation date". That is such a big help !!!
1. It is a very (!) good solution to offer the script as a download. It makes it a lot easier to get the script.
2. Another very good idea is to offer it with a name that shows the date, like 'TDL New Task Creator upload 2011-12-09.ahk'. Makes it a lot easier to identify the version.
Beta - Test (v0.2 )
1.) The script works like a charm. I love 'File link'.
2.) "Made Dropdown arrow bigger". Sorry, but I like the smaller ones better. Reason: Everything looks very "filigree", the height of the WinTitle, the close button in the WinTitle, the little arrows in the time fileds etc. These big drowdown arrows are "breaking ranks" optically.
3.) "ComboBox width now pixel aligned". Good work, looks very professional.
"Little things":
a) The description text of the fields is not shown completely, e.g 'TDL Filename' is 'TDL Filena' , 'Creation Date' is 'Creation Da'.
b) I suggest to give 'TDL Filename' a whole line. I suggest the same for the field 'Title' with 'Task' in it.
If you agree to that I suggest that you expand the "create New Task' window (by or 50, 60%). That would make it easier to see the whole path to the *.tdl file. Another reason is that the 'create New Task' window can be embellished on a grand scale. This window is the new 'control center' for creating new tasks, isn't it?
c) It would be very useful if the word 'task' in the field 'Title' would be highlighted by default after calling the 'create New Task' window.
d) It's a logical thing to offer 'creation time', too but the user cannot see the time he has chosen in ToDoList because ToDoList doesn't offer the view. Question is: do we need it? I think we should keep it. You never what ToDoList offers in the future.
e) 'Category' and 'Status' (not present yet) could be put in the same line. Ditto for 'Allocated to' and 'Allocated by'.
f) After the script has made ToDoList create a new task ToDoList saves the list. And only after that the 'create New Task' window appears. This can slow down things if you have a large tasklist. I assume that this can't be totally changed, right? I assume the saving routine is necessary because the script needs "a stable" tasklist before working on that tasklist outside of ToDoList.
A solution could be to let ToDoList save the list in the backround and presenting the 'create New Task' window while ToDoList is saving. This way the saving of the list wouldn't be interrupting the workflow.
A little "inconsistency":
The script makes ToDoList create a new task. After ToDoList has done that the 'create New Task' window of your script appears.
Let's assume that the user clicks on 'cancel'. Result: the script doesn't work then on the tasklist outside of ToDoList.
But there is an inconsistency here: I'd expect the new task (created by ToDoList) to disappear after I click on cancel but the new task remains in the tasklist although the user has chosen to cancel the creation of a new task.
It's obvoius why we get this result; ToDoList creates a new task but the script doesn't take care of that task anymore when the user cancels the operation.
I would like to suggest that the script sends a PostmessageCode to ToDoList that makes ToDoList delete this new (useless) task it just has created if the user clicks on 'cancel' or on the 'close' button in the WinTitle.
An idea for a distant future of this script (I'd rather call it 'tool').
How about adding the option 'number of tasks'. That is to say that the script could ask the user how many tasks he would like to create in a row. E.G. if the user chooses '3' the script could present the 'create New Task' windows three times (one window after the other). The user can always choose between 'save' and 'cancel' to get to the next 'create New Task' window.
|
|
|
|
|
TCP_JM wrote: a) The description text of the fields is not shown completely, e.g 'TDL Filename' is 'TDL Filena' , 'Creation Date' is 'Creation Da'.
Sorry - I made the width narrower to test something and forgot to change it back - easy fix though.
TCP_JM wrote: b) I suggest to give 'TDL Filename' a whole line. I suggest the same for the field 'Title' with 'Task' in it.
If you agree to that I suggest that you expand the "create New Task' window (by or 50, 60%). That would make it easier to see the whole path to the *.tdl file. Another reason is that the 'create New Task' window can be embellished on a grand scale. This window is the new 'control center' for creating new tasks, isn't it?
Agree - the code is actually there to provide an option to give file link a whole line or not - just need to expand it
TCP_JM wrote: c) It would be very useful if the word 'task' in the field 'Title' would be highlighted by default after calling the 'create New Task' window.
I know why this is happening - and I have just thought of a fix - will add to my long list...
TCP_JM wrote: e) 'Category' and 'Status' (not present yet) could be put in the same line. Ditto for 'Allocated to' and 'Allocated by'.
I am not going to manually put stuff on the same line or not
You will see there is code to hide some fields (which means if it is hidden I cannot put it on the same line), and a setting for number of columns. I will at some time consider putting in custom order, and putting in blank placeholders.
TCP_JM wrote: f) After the script has made ToDoList create a new task ToDoList saves the list. And only after that the 'create New Task' window appears. This can slow down things if you have a large tasklist. I assume that this can't be totally changed, right? I assume the saving routine is necessary because the script needs "a stable" tasklist before working on that tasklist outside of ToDoList.
A solution could be to let ToDoList save the list in the backround and presenting the 'create New Task' window while ToDoList is saving. This way the saving of the list wouldn't be interrupting the workflow.
I will need to make a choice:
1) Have TDL create default/inheritable values and load from there (my code is geared towards this at the moment - although I am not loading it yet).
2) Ignore inheritable/default values - which means I can delay new task creation
TCP_JM wrote: A little "inconsistency":
The script makes ToDoList create a new task. After ToDoList has done that the 'create New Task' window of your script appears.
Let's assume that the user clicks on 'cancel'. Result: the script doesn't work then on the tasklist outside of ToDoList.
But there is an inconsistency here: I'd expect the new task (created by ToDoList) to disappear after I click on cancel but the new task remains in the tasklist although the user has chosen to cancel the creation of a new task.
It's obvoius why we get this result; ToDoList creates a new task but the script doesn't take care of that task anymore when the user cancels the operation.
I would like to suggest that the script sends a PostmessageCode to ToDoList that makes ToDoList delete this new (useless) task it just has created if the user clicks on 'cancel' or on the 'close' button in the WinTitle.
I agree
TCP_JM wrote:
An idea for a distant future of this script (I'd rather call it 'tool').
How about adding the option 'number of tasks'. That is to say that the script could ask the user how many tasks he would like to create in a row. E.G. if the user chooses '3' the script could present the 'create New Task' windows three times (one window after the other). The user can always choose between 'save' and 'cancel' to get to the next 'create New Task' window.
Interesting though - I had an idea where I parse the clipboard, and use each line as a new task title and let the user fill in the rest.
Will consider it - though only once the rest is stable, and I can think of a clear and concise way to present the choice to the user (this will be made easier with the principle decision above if I choose the second option of delaying task creation)
|
|
|
|
|
capital H wrote: I am not going to manually put stuff on the same line or not ... which means if it is hidden I cannot put it on the same line Understood.
capital H wrote: I will need to make a choice:
1) Have TDL create default/inheritable values and load from there (my code is geared towards this at the moment - although I am not loading it yet).
2) Ignore inheritable/default values - which means I can delay new task creation
Another thought regarding default values:
I understood that it's difficult (or not possible) to "read out" the default values set in the ToDoList preferences.
I'd like to suggest therefore that the default values in your script should be "a blank" for every field then (exception 'Title' with 'task' in it and the 'TDL Filename', of course).
Another theoretical option could be that your script and ToDList are storing different "preferences". This way your script wouldn't have to read out the default settings of ToDoList (it would have it's own settings then).
BTW: I' using an AHK script that is writing it's own ini-file. Maybe that's an option for your script, too.
Thanks for all your work!
|
|
|
|
|
|
I should have been more transparent - but with the new commandline options in 6.4, I suspended the development until it was more final.
Using the commandline options is easier, and better (since the whole delay saving/loading the tasklist issue is avoided).
I have not played much with the 6.4b1/6.4b2 (and I cannot remember why I did not want to to it with the alpha version), but I suppose I can start work on the beta version (i.e. I can probably assume that the switches/format will not change - and if there is a bug then Dan will probably fix it in 6.4 final/6.4.1/6.5)
|
|
|
|
|
Thanks for your reply.
capital H wrote: Using the commandline options is easier, and better (since the whole delay saving/loading the tasklist issue is avoided). I agree, but I liked your approach, too.
Thank your for working on the script in advance.
Cheers,
Jochen
|
|
|
|
|
Good day, .dan.g., do we have any hope to have the features discussed some time ago implemented (http://www.codeproject.com/Messages/2261873/Feature-Request-Quick-Task-Entry-Date-Parsing.aspx, http://www.codeproject.com/Messages/3299392/inline-parsing-for-fast-entering-of-tasks.aspx)? Or, probably, there some AHK scripts that can be shared by you, guys?
|
|
|
|
|
I don't know how MLO does it but it strikes me as being quite tricky to get get reliably right.
First there's the issue of multi-language support: It's hardly appropriate to make users write in English if they're working with a full translation of ToDoList in their native language.
Secondly, even if we were to force them to use English (and with proper support for translation in 6.3 English speakers may become a minority), non-English speakers often construct their sentences according to their own language's syntactic rules.
Thirdly, how do we give appropriate feedback to users when they inevitably make a mistake.
|
|
|
|
|
As for task parsing, you are absolutely right, it's not an easy issue taking into consideration support for non-english users (btw in MLO there are only two options for parsing, in English and Russian, operands for both are fixed, i.e. cannot be changed and reassigned by users). Anyway, my suggestion is to initially make it in, say, English with the possibility to reassign the triggers in your native language (Ex. -d or *d stands for date, a user can reassign this combination, it can be like reassignment of shortcuts) In such a case you do not oblige people to use only English, what is to be translated later is only the description of parsing commands.
Regarding construction of non-English sentences. Well, generally speaking notions in all languages are all the same (start, due, Saturday/sat, remind, etc). You as a maker of this program can limit the quantity of commands, because the main target of this topic is to facilitate work not vice versa.
The third point, this one I didn't get well enough, what kind of mistakes do you mean, if change of parsing rules is restricted to reassignment of "shortcuts", nothing is going to happen.
Btw, what is your position towards quick task entry, is it feasible?
P.S. I do use mostly MLO at the moment but there only a few things that restrain me from switching completely to TDL and I will definitely do this because of their feedback.
P.P.S. Did you ever consider introduction of logical operands?)
|
|
|
|
|
Perhaps what I'll do is to extend the existing commandline options to allow the specification of more task attributes and then we cn see if we need to also provide a new interface.
|
|
|
|
|
I consider implementation of quick task entry in Things to be a good one (culturedcode.com/things/wiki/index.php/Quick_Entry_and_Autofill) especially with options to paste into a new task/existing task. As for commandline options, I didn't quite get how to do this, because there's kind of lack of documentation on this, or at least I wasn't able to find it..
|
|
|
|
|
Thx, that looks like a much better model.
I particularly like the idea of grabbing the clipboard text and allow the user to drag'n'drop from the clipboard text into various fields.
Imaging a dialog displaying edit fields or droplists for a task's attributes together with a multiline edit field below displaying the clipboard text.
The user can drag-highlight bits of the clipboard text and then drag the selected text into any of the attribute fields, including dates. This would be especially handy for creating tasks from emails.
Your thoughts?
modified 6-Dec-11 0:23am.
|
|
|
|
|
For me it looks a bit compicated, the simplier - the better. First of all, we need to define the purpose of use of QTE, in my opinion, that is to 1) make part of information (clipboard text, email, etc) a task, an action, 2) grab your inspiration and immediately inscribe it (eg you are struck by an idea, don't have time to open a program, find an appropriate field to fill in, etc, you just hit a shortcut and add your vision - hey, that's the action, and this one is a sub-action, and another one, and here I would put deadline, say, 25/12/2011 (that is why I consider text parsing useful, applicable for QTE only). After you are done, just send your geniuous ideas to limbo (in terms of GTD, Inbox folder) and get back to them as soon as you are ready to revise them and make your ideas really actionable).
There can be even more tricks to play with QTE, I like the Gyroq, addon for Mind Manager (http://www.gyronix.com/gallery/browse.php?home=Gyronix-Video-Library.txt&help=this), the idea and implementation rock, unfortunately I was not able to find a similar standalone application for accumulation and further processing of your prompt ideas/thoughts/tasks, it can be very useful, for example, when you are brainstorming a project.
As for GUI, my vision of necessary elements is as follows: 1) option to choose a tasklist to go if you have more than one, 2) option to add subtasks 3) display of link (if you drag highlighted text from a browser window, you'll have an URL in comments, if an email from an email client - link to the body in it), 4) option to parse text, eg, pr10 would mean priority 10, etc, in such a case GUI will not duplicate the main window and will not be overloaded by lots of input fields and buttons.
What do you think about such implementation?
|
|
|
|
|