|
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?
|
|
|
|
|
mugrrrr wrote: What do you think about such implementation? I will take your comments into consideration and follow my intution.
ps. If you want to send me some screenshots of other products, feel free.
|
|
|
|
|
.dan.g. wrote: If you want to send me some screenshots of other products, feel free.
Here we go.
Firstly, for me the neatest HUD design I've ever seen is of Things, and now I'll explain why.
Screenshots: http://www.laketa.com/wp-content/uploads/2011/03/Things-quick-entry.png, http://jetplanejournal.com/jetplanejournal/wp-content/uploads/2009/04/picture-20.png.
Fields in QTE of TDL:
1. Task name.
Input of multiple tasks should be allowed, as well as subtasks, so, this field will be extendable depending on how many tasks/subtasks you add. Subtasks can be added like in, eg, MLO (via blank space) or via any other dividers.
2. Categories.
There you can choose a proper category.
3. Comments.
Simple text comments, no drums and whistles, because you need to grab your task in a fast/quick/rapid way, not create a masterpiece.
4. URL/link.
It's not actually a field, a line, that displays a source of a task (email, webpage).
5. Due date.
My second link is to show a calendar, very convinient to choose a certain date.
6. Task goes to a folder that you can choose (eg, if no folder is chosen, a folder "Inbox" is created at top level and the task goes there).
Now some comments.
1. If there's text parsing, fields like "Due date" or "Priority" (I didn't mention that one because I think it to be redundant) are not obligatory, you can make a report ^due 20/12/2011 ^pr 6.
2. If you work with more than one tasklist at a time, you need to choose a proper one, there's should be a separate field for it, probably, after a "Folder" field.
|
|
|
|
|
|
No, thank you
|
|
|
|
|
Hi Dan,
Thank you !
1.) I just copied a few icons (with different file extensions and sizes) in the folder 'recources' but the result is a little hit-and-miss.
Some are shown by ToDoList, some are not and some others are shown partially (the upper left corner of the icon).
I would like to ask you if could describe the exact specifications of an icon file that will be accepted by ToDoList: size, file extension, colour depth ...
2.) Is it possible to exchange the standard ToDoList icons with others?
I'm not asking because I do not like them, but because I do not need them all and I would like to limit the amount of icons presented in the 'select taks icon' window to those I need.
Thank you for your answer in advance.
Cheers,
Jochen
|
|
|
|
|
TCP_JM wrote: 1.) I just copied a few icons ToDoList optionally supports a single user-defined bitmap of 16x16 images called TaskIcons.bmp and/or individual 16x16 icons having the extension .ico .
32x32 icons with no 16x16 version will still be interpreted as 16x16 resulting in only the top-left quadrant appearing.
[update] I will fix these issues for 6.4. [/update]
TCP_JM wrote: 2.) Is it possible to exchange the standard ToDoList icons with others? Not at present.
And this raises the whole issue of how to handle shared tasklists. Suppose you and I share a tasklist but I have a different image-set to yours => the icons will display incorrectly. One possibility would be to always load icons from a folder relative to the tasklist as that will be the same for both.
modified 29-Nov-11 20:01pm.
|
|
|
|
|
Hi Dan,
first of all thanks for your reply and your explanations.
.dan.g. wrote: ToDoList optionally supports a single user-defined bitmap of 16x16 images called TaskIcons.bmp and/or individual 16x16 icons having the extension .ico . 32x32 icons with no 16x16 version will still be interpreted as 16x16 resulting in only the top-left quadrant appearing.
[update] I will fix these issues for 6.4. [/update]
I wouldn't have called it an issue. Icons that include 16x16 are obviously working.
1.) The question is: Is it possible for ToDoList to display icons that do not include a 16x16 version correctly?
I'm not referring to the abilities of ToDoList here. I'm talking about what can be displayed in this little square in 'Tree View' and 'List View' "correctly".
Assuming that it would technically be possible for ToDoList to display a 48x48 icon in that square: Will it be possible for the human being in front of the monitor to recognize the picture of the icon if ToDoList minimizes the picture of that icon from 48x48 to 16x16 by scaling down optically? The bigger the monitor the bigger gets the chance that the answer is 'yes', but on a small monitor?
At the end of the day it will be the responsibility of the user to use icons that can be displayed in a way that he can recognize them. Icons should have the format 16x16 or 24x24 or should include these versions IMO.
2.) Format
BMP and ICO file extensions are good, but I would like to suggest that ToDoList should support other formats, too.
Especially PNG files. The amount of designers that are using PNG files to create icons has grown significantly.
(e.g. I just found the website of a Japanese designer who provides 3.300 [not a typo] 16x16 high quality icons [png].These icons are available under a Creative Commons Attribution 3.0 License.)
3.).dan.g. wrote: And this raises the whole issue of how to handle shared tasklists. Suppose you and I share a tasklist but I have a different image-set to yours => the icons will display incorrectly. One possibility would be to always load icons from a folder relative to the tasklist as that will be the same for both. There are two options:
a) Every user can use his own icons (stored in a folder of his choice). That is to say that user A can have e.g. 'two little footsteps' (=move) for 'actions' and user B can have 'a letter' or 'a telephone' because he likes to categorize his actions although they use the same tasklist (stored somewhere on a server).
This would call for an ability of ToDoList to store the information about "which user is using which icon for which task".
b) Your suggestion to always load icons from a folder relative to the tasklist as that will be the same for both.
This is - I think - the only way to handle this. Option a) may be nice but I doubt that is is possible.
4.)
.dan.g. wrote: TCP_JM wrote: 2.) Is it possible to exchange the standard ToDoList icons with others? Not at present.
Hmm... Sorry, but this is in a way a 'must be'.
I would like to suggest the following solution to avoid problems.
ToDoList should look at first in that folder relative to the tasklist (or a standard folder) if TaskIcons.bmp exists. If 'yes' the icons of TaskIcons.bmp should be diplayed first like it is handled by ToDoList right now.
This way it will not be necessary for user who are using the standard icons of ToDoList to choose new icons after ToDoList offers a complete exchange of icons.
If TaskIcons.bmp doesn't exist ToDoList should show only the icons that the user provides in an alphabetical order (or if the user decides to number them in an order according to that).
It is very important that ToDoList stores the name of the icon in relation to a sprecific task not the position of the icon in the list!!
Let's assume the user has three icons
Sport_Soccer
Work_Meeting
Work_Telephone
The user chooses 'Work_Meeting.ico' for a task 3046
Then he decides to add an icon: Work_Letter.ico
The list would be:
Sport_Soccer
Work_Letter
Work_Meeting
Work_Telephone
Task 3046 should still show the icon 'Work_Meeting' and not suddenly 'Work_Letter' because ToDolist goes for the position of the icon in the alpabetical order, right?
Thanks for all your work!!!
Cheers,
Jochen
|
|
|
|
|