I spent some time hacking together a few improvements to the “Send to kGTD” script.

This is a modest improvement to the Send to kGTD script that Ethan created. It has a few improvements over the included script:

1) The kGTD file is saved once the new task is added. Computers fail sometimes, and it would be a shame to have a lot of new tasks vanish in the midst of a weekly review. Especially given the new functionality in this release, this action is now my #1 way to add tasks. I’d hate to lose ‘em.

2) Closes kGTD file on completion if it was closed already. Keep the computer clean and memory available. If the kGTD file was open to begin with, it remains open.

3) LaunchBar support. This can be activated from LaunchBar. Simple enough. Still works with Quicksilver, too. (As the previous script I sent did.)

4) Correctly matches contexts. The version included in 0.83 will return the last match, not necessarily the best match. I submitted a bug report about this on the website. There might be a better way to handle this, but this seems quick and works well.

5) Rather than use the “new” flag when creating a context or project, this will actually create a new context or project if a match isn’t found. This might be better handled through an alert of some sort (e.g. “Are you sure you want to create context: New Context?”), but I prefer this behavior.

Download Send to kGTD ADVANCED


weave73's picture

What about Butler?

What about Butler?


Nik's picture

Added the ability to just

Added the ability to just “run” the script and it will display a dialog asking for the new task string. This will allow the Send to kGTD functionality to work in programs that only support running scripts, but that cannot pass text or other variables to the script. (e.g. Butler, Apple’s script menu, FastScripts, DragThing, etc…)

For that matter, you could save the whole thing out as an application and run it from the dock.

Nik: Improving kGTD a Script at a Time


weave73's picture

thank you! thats exactly

thank you! thats exactly what i needed! butler functionality makes this a dream.

i thought the action was supposed to show up in the Inbox, though. I looked there, but did not see it. however, when i synced my document it showed up in the correct project with the correct context.

now when i test an action without specifying project or context it shows up in the inbox.

or if i specify an action with a context, but no project it shows up in the inbox.

is this the way it was designed to work?


Nik's picture

Actions which aren’t

Actions which aren’t assigned a context or a project show up in the inbox, just as with the original action. The only difference in the core behavior is that if you enter a context or project that doesn’t exist, it will be created for you.

Nik: Improving kGTD a Script at a Time


Thanks, this looks like a

Thanks, this looks like a great improvement on the script! However, I have problems getting it to work from Launchbar. When I run it from Launchbar, I get in the Console:

NSAppleScript Error -43: File not found

Any suggestions?


Nik's picture

Haris, have you already

Haris, have you already sync’d kGTD at least once and saved the OoP file? If not, the script will not be able to locate the KGTD file. Same for if you’ve moved the KGTD file since you last sync’d.

If you’ve tried that, I’d give your computer a reboot (why not) and see how things go. If you STILL have trouble, let me know what version of LaunchBar, Mac OS X, and OoP you’re running.

Nik: Improving kGTD a Script at a Time


Nik, thanks for the quick

Nik,

thanks for the quick reply. Yes, I have already synced, and I am running the latest beta version of OOP, and Version 4.0.2 (v458) of Launchbar.

It turned out the problem was that I had used a trial license for OOP, which had expired, and though I could use the document normally, the script did not work with Launchbar, though it did work with Quicksilver. Once I got a new trial license, everything worked out just fine, almost:

It seems that in either case, the document will always close, regardless of whether I have it open in OOP or not (I always have it open these days).

I opened the script in the Script Editor to see what is going on, and found where you set kGTDclosed. Then I ran the following script:

tell application "OmniOutliner Professional"
   set ThisDocumentPath to do shell script "defaults read com.kinkless.kgtd lastpath"
   set ThisDocument to first document whose path is ThisDocumentPath
   get ThisDocument
end tell

And I got back a result when the document is open in OOP, and an error when it is not open. So it seems to me that indeed the “on error” part should not be ran when the file is open, as is your code’s intention, but for some reason kGTDclosed is nonetheless set to false anyway.

I added set kGTDclosed to false right after the on run and that seemed to fix it. So I guess somehow the line property kGTDclosed : false does not actually set the value of kGTDclosed to false.


a11en's picture

Has anyone noticed their

Has anyone noticed their Quicksilver triggers have busted in the new release? I can’t seem to get mine working again.. :(


Ethan's picture

Thanks Nik, excellent stuff.

Thanks Nik, excellent stuff. The only item I might want to alter is the new project syntax. Currently I’m coding it to be “new:newproj” name. The only reason I’m doing this is that I, personally, am forgetful and a terrible typist and I not infrequently try to send a task to an existing project but get the initial string wrong.


With all due respect*, I

With all due respect*, I actually think Nik’s solution (without the “new:” required) is better. With it, you only need to consider what the appropriate project would be for the task, and the script will determine whether it exists or not and act accordingly.

With “new:” you have to figure out the appropriate project and then you have to remember if that project has already been defined or not. Seems like an extra thinking step (which may seem minor, but isn’t GTD largely about clearing these unnecessary things out of your head?)

I would prefer the burden of being careful with my spelling to the burden of having to think about which projects I’ve already defined and which would be new. Especially since, as I understand it, tasks with typos will still enter the system and should be easy to reclassify in kGTD when you catch them.

*which is a ton! Thanks so much for this wonderful tool.


Ethan's picture

There are pros and cons to

There are pros and cons to both methods. It’s important to me to be able to send to an existing project, but I’m leery of having a new project created off of misspellings. I’m likely to implement the same function using the “new:” prefix or an alternate modifier. This is still simple and ensures intent rather than accident.


Maybe we should just agree

Maybe we should just agree to disagree then. ;-) What will happen in the new system if someone puts in a task as new:projectname where projectname already exists? If it already exists (spelled identically), can that task simply go into the existing project? I ask because this would allay the reservation I expressed above, about having to think whether the project already exists or not: if I’m not sure, I can simply use the new: prefix and it will act appropriately.


Ethan's picture

Nothing’s set in stone

Nothing’s set in stone yet. Nik’s solution is superior to my vapor ware and he’s done a great job with it. I’m nervous by nature about losing tasks in my long list, which is the only reason for my hesitancy.

Basically, the “new:” prefix (actually not what I would likely use, I have some more elegant format in mind) would display the same behavior as the current “Send to kGTD” with the exception that if the project isn’t found, a new project would be created.


Nik's picture

Ethan, I share your

Ethan, I share your nervousness, and have in fact FAILED to create new projects on a couple occasions with my script (my new project name matched a partial project name) and have created a surprisingly large number of two or three letter contexts by mistake. Considering I wrote this thing, I’m going to consider it a bit too dangerous for my daily use. (Obsessive compulsive spellers and typists may, of course, find that it’s ideal. Knock yourself out!)

I’m thinking of two improvements to help keep this down, and I’m curious what you or others think about them.

  1. Add support for Growl so that I can pop up a little unobtrusive message reporting on what action the script took. (i.e. “Created projects X and added task Y with context Z”) Then, at the very least, if something went wrong, you could instantly see that it went wrong and fix the problem.

  2. Make it interactive. Pop up a list of all potential matches on a partial name match (but not on a full match) for projects or contexts, along with the option to create a new project or context. Similarly, when there appears to be a request for a new project or context, pop up a list of ALL available of each along with a button to go ahead and use the new one. Obviously, I cannot drive this through Quicksilver’s panes, so I’m stuck with Applescript’s default Ugly Ass Dialogs™, but it would fix the problem.

The latter suggestion potentially cuts down on speed (a primary reason for the action in the first place), and might be better served to only pop up when a new context or project is created. (The assumption being that it’s always okay to assign to existing categories.)

I don’t really see a downside to the Growl notification, except that it adds yet another piece of software that has to be downloaded to make this whole thing work. Fine for me (since I use Growl extensively), but then you’re getting kGTD, OoP, Quicksilver/Launchbar, and Growl, each from different sources. The potential for something to break gets higher and higher.

Unless, of course, Growl notification was made de rigeur throughout Kinkless, and was used for all the messaging and notification. It could certainly be bundled with kGTD, and might serve as an elegant way to provide unobtrusive user feedback (such as sync’ing state and results) throughout the system.

Nik: Improving kGTD a Script at a Time


“vapor ware” - Oh Ethan,

“vapor ware” - Oh Ethan, I see my earlier snarkiness has stuck with you. I feel like an ass. Please forgive me and know that I am a huge fan and a thankful kGTD user, even though in my impatience I came off as a total ingrate.

And I have faith that your eventual solution to this particular problem will be elegant and practical, as has every improvement you’ve made to the scripts.


I’m trying to decide

I’m trying to decide whether I want to move from my existing ical <-> mail solution to this excellent gtd solution. Concerning syntax and usability for assigning things to projects and contexts in Quicksilver, I have a suggestion:

I have grown to LOVE the ical todo plugin for Quicksilver. This is how it works:

  1. Invoke Quicksilver in text mode and type the name of your todo
  2. Tab to action pane and select the ‘Create Ical To-Do’ action (I usually type to or todo and it does the trick)
  3. Tab to the third pane and select the name of the ical calendar you wish your todo to be put in.

The advantages are that you don’t have to remember what the ical calendar is called, and if you do remember what it’s called you only have to type a few characters instead of the entire name. There is one thing that could be improved about it: If the user enters text mode in the third pane, it would create a new ical calendar by that name and stick your todo in there.

How does this apply to kGTD? I haven’t ever looked under the hood at quicksilver plugins, but if it’s possible to use the third (and fourth if there is one) pane(s) to select and/or add projects and contexts, that seems ideal. The workflow would go like this:

  1. Invoke Quicksilver into text mode
  2. Tab to action and select ‘Send to kGTD’ (pressing enter at this time would send the item to the kGTD inbox)
  3. Tab to the third tab and select the context, or enter text mode and type a new context name (pressing Enter at this time would send the item to kGTD with the selected context in the !Single Tasks project or the inbox - not sure which makes more sense)
  4. Tab to the fourth pane and select the context, or enter text mode to type a new context name (pressing enter now causes our task to be filed in the selected or newly created project and context, all happy and such :)

The general theory behind this is to leverage Quicksilver’s intelligent searching as you type behavior to our advantage instead of having to remember what our projects are called and having to type them completely. Granted, this would probably require a dedicated quicksilver plugin rather than a simple applescript, but somebody here has to know how to do that, right? I’m also not completely sure of the feasibility since I’ve never actually seen a ‘fourth’ pane in quicksilver, so I don’t know if that is possible.

Thanks for the great system!


Vern's picture

Wow! As a QS addict, that

Wow! As a QS addict, that sounds great and especially as it harnesses QS’s workflow so well and correlates with the iCal To Do action. Hopefully, someone can make this happen!!! Thanks Ethan for kGTD!


Sorry for the NEWBIE

Sorry for the NEWBIE question - How do I get Qicksilver to work with kGTD? I have both installed?????? Help


phow4rd's picture

NEWBIE: Here’s how I do

NEWBIE:

Here’s how I do it:

1) Verify that you have a file called “Send to KGTD.scpt” at ~/Library/Application Support/Quicksilver/Actions/. This should have been installed along with kGTD 0.8.

2) Invoke QS, then bring up the Preferences.

3) Choose the “Action” section, then click on “Text” in the Type column.

4) Verify that “Send to KGTD” is in the list of available actions and that its checkbox is checked. It’ll probably be at the bottom of the list. If you’re like me, you’ll want to drag it to the top instead.

5) Close the QS Prefs.

6) Verify that your kGTD document has been synced at least once in its present location. (This is so that the QS script knows where to find it on your hard drive.) This is the last “set-up” step.

7) Invoke QS, press the period key to go into “text” mode, and write something.

8) Tab into the Action field. If you moved the kGTD script all the way to the top in step #4, you just need to press Return, otherwise, type “sen…” or “kgt…” or whatever until the script is selected, then press Return.

9) Go to the Inbox section of your kGTD document and verify that your new entry is there.

10) Use QS to empty your head (and keep it empty) more efficiently that you ever thought possible.


taxman's picture

Thanks for the write-up.

Thanks for the write-up. How do I use QuickSilver to add a “to-do” to a specific project that already exists in y kGTD file?


philologos's picture

[quote]phow4rd said, Wed,

[quote]phow4rd said, Wed, 2006/03/29 - 8:03pm Verify that you have a file called “Send to KGTD.scpt” at ~/Library/Application Support/Quicksilver/Actions/. This should have been installed along with kGTD 0.8.[/quote]

I don’t have this file. I had problems with QS which made it necessary to trash my QS application support files. When I relaunched QS it created a new /Library/Application Support/Quicksilver/Actions/ file but the “Send to KGTD.scpt” is no longer there.

Can I download it from somewhere?


George Crump's picture

Sorry to resurface this but

Sorry to resurface this but I have installed the script and it always closes the file on me. I have synced more than once. Any ideas?


George Crump's picture

Never mind I fixed it in the

Never mind I fixed it in the script.


Nik's picture

It closes the file if it

It closes the file if it wasn’t already open. If your kGTD file was open already, it keeps it open.

Is that not the behavior you saw?

Nik's Latest Crappy Software


mandarinfish's picture

I’m finding that it is

I’m finding that it is always closing my kGTD file, even if I already have it open.

Is there a fix for this?


texcrowbar's picture

I had the same problem as

I had the same problem as have others. The following solution worked for me….

  1. Open the script using Script Editor.
  2. Click the Compile button in the toolbar.
  3. Save.

Hope this helps.

Cheers,
Tex


Nik's picture

Applescript: Thy name is a

Applescript: Thy name is a royal pain in my butt!

Yeah, this is my fault. I ran the script once prior to uploading it to my site. End result: the property is saved (invisibly) in the script itself.

Set a property, I tells it! Noooooo! Responds Applescript! I already did that once! You can’t fool me!

Sometimes I hate Applescript soooooooooooooo much!

Thanks for finding the fix, texcrowbar. I hope to have this fixed in the next release… Coming… someday.

Nik's Latest Crappy Software


texcrowbar's picture

No prob, Nik. I love your

No prob, Nik. I love your script. Keep up the great work.

Cheers,
Tex


Nik's picture

I just launched version 2 of

I just launched version 2 of Send to KGTD Advanced. This is a complete re-write of the original script, and is much more flexible, easier to use, and more powerful.

I’ll be posting details to these forums, but I thought I’d let users of this script know first.

Nik's Latest Crappy Software


umop's picture

I just edited the Send to

I just edited the Send to GTD Advanced to include quick-jumps to contexts and projects. The format is:

@Context (or @Cont)
and
>Project.Subproject (or >Proj.Sub)

This will drop you into OO / kGTD in the correctly selected and hoisted context or project. Kinda handy when you have a million of either. Hope I haven’t duplicated anyone’s code here but I haven’t found anything like this yet.

Just replace your Send to KGTD Advanced.scpt file with this one:
Send to kGTD Advanced Advanced


Nik's picture

This change would, of

This change would, of course, eliminate the ability to use the script to just create a project or context. (The default behavior if you just type @context or >project.)

I would probably think a better approach would be a “navigate to context/project” script which uses that syntax but simply navigates. Mixing a script which adds data with one which handles navigation strikes me as a very confusing way to work.

I have asked OmniGroup to change the Applescript “select” function so that a selected row is scrolled to in the OOP window, which would make this kind of navigation script even easier. (Currently, Send to KGTD Advanced does select newly created projects/tasks, but they aren’t necessarily visible in the window, depending on the window’s size and where it’s scrolled to.)

Nik's Latest Crappy Software


umop's picture

I was thinking about it this

I was thinking about it this morning, and I think that a good way to work this would be to keep the notation as it is in mine, but if the context exists, navigate to it, and if not, create it. The only thing we’d need to add would be a * to indicate wildcard, so:

>Project.Subproject, >Project.Sub, >Proj.Sub would all navigate to Project->Subproject, but >Proj.NewSub would create a new subproject within project (I nest my projects and rarely create top-level projects). I’m envisioning that in this case, a dialog would ask if you really wanted to create a new project. I don’t think this would be a pain because, how often do we really create new projects?

Two other thoughts:

  1. I wonder if the / to separate projects would be more natural, and
  2. Wildcards could be required for partial matches (though, I think that would get time consuming after awhile

I also changed my main kGTD script a while back so that projects are listed by only their first name (with a heirarchical description afterwards). I can’t remember how it used to be, so this may not be appropriate for users of the original script.


Nik's picture

I don’t think this

I don’t think this would be a pain because, how often do we really create new projects?

I create new projects almost as frequently as I create new tasks! I have a fairly small set of contexts, but I work on dozens of projects in parallel at work and at home. According to canonical GTD, projects should be kept pretty granular, as The David suggests that he’ll often have 100+ projects. I tend to have closer to about 30-40, but they finish quickly and start up frequently.

1.I wonder if the / to separate projects would be more natural, and 2.Wildcards could be required for partial matches (though, I think that would get time consuming after awhile

My design goal with this script was twofold: One, to maintain the same syntax as Ethan’s original script; and two, to make it a rapid data entry tool that didn’t require a lot of thought. The point of the partial match is to make it easy for me to just kind of flail at the keyboard in order to get an idea stored for later review. (Hence it goes into the inbox.) I do not want to force the user to think about which contexts she has or what projects are currently active. Hence the partial match. (I can’t take credit for this, it was Ethan’s idea.)

I can see why your method would be more precise, and especially more useful for somebody with a large number of nested projects. However, precision was not my goal. The GTD workflow is capture -> organize -> act. This tool fills the first slot, and that’s all it’s designed for. Yes, you can get down to organize with it if you want, but that’s sort of “frosting” on the cake. Everything dumps into the inbox for the simple reason that you can then easily fix up anything that didn’t go right prior to your next sync.

I don’t want to dampen your enthusiasm for creating your own modifications. Please do! Personally, though, I prefer tools that do one thing well, without any ambiguity in their function. Thanks to LaunchBar, I can select among the dozens of little helper scripts quickly and easily and use precisely the one I want, without becoming encumbered by the quantity on my Mac. As a result, I have plenty of scripts that do one very, very, small task, and which could reasonably be combined with other scripts. But I prefer to keep them small, easy to read and edit, and focused.

And heck, as it is, the Send to KGTD script is already dangerously bloated. On my aging AiBook, it takes a good 10-20 seconds to add a task to my KGTD file. I’m VERY hesitant to introduce anything at all that might slow it down.

Nik's Latest Crappy Software


Vern's picture

Ethan or Nik, the only

Ethan or Nik, the only problem I’m having with kGTD right now is the context matching. I have different Mac and Errand contexts and unfortunately, it sticks to the default despite spelling out the entire context. Is there a simple fix for this? I’d give your advanced script a try Nik but don’t want to add more apps to my workflow. Thanks!


Nik's picture

Vern, I’m confused by your

Vern, I’m confused by your question. First off, are you using Send to KGTD Advanced or Ethan’s “Send to KGTD” script?

Assuming you’re using ‘Advanced, can you please tell me EXACTLY what you’re sending to the script via Quicksilver and which context it’s actually putting it in? (e.g. I type “do this @ home” and it puts it in the Homefry context instead of the Home context.)

If you’re using Ethan’s script, there are some known problems with its context matching. I’d recommend switching to the ‘Advanced script if it works acceptably for you.

Nik's Latest Crappy Software


RandyChev's picture

I’m trying Send to KGTD

I’m trying Send to KGTD Advanced and get Send to KGTD Error; Can’t get columniddatedue of ColumnIDContext:”[garbage]”, ColumnIDProject:”[more garbage]”. Then a second growl notification of Send to KGTD Error -2753.

This happens with text “test” only as well as “Buy milk @ errand”

The regular Send to KGTD script works fine.


RandyChev's picture

Yesteray, Yep. That was it.

Yesteray,

Yep. That was it. You also have to set start date to true as well. I’ve been thinking about checking out start and due date usage so this will probably through me into it.

Thanks for pointing out the need for that setting.


Nik's picture

Yup, the script insists that

Yup, the script insists that you have all the columns enabled. If it’s a real killer, I might try to work around that limitation…

Frankly, with repeating/recurring tasks, having start/due dates is extremely worthwhile.

Nik's Latest Crappy Software


Nik's picture

Send to KGTD Advanced

Send to KGTD Advanced Version 3.0 has been released!

Now supports international character sets, KGTD documents without date columns, and no longer requires any scripting additions.

Go get it!

Nik's Latest Crappy Software


avartan's picture

Hi there, I just downloaded

Hi there,

I just downloaded the Advanced script, and I’m hoping I can get some help modifying it so it better fits my needs:

1) Is there a way to set up a default context, or to turn off context processing in general? I don’t really use contexts and find that if I don’t enter one and just use a project, like “task > project” the task doesn’t get added to my Actions list, instead it sits in my inbox, which I do not use.

2) Is there a way to automatically sync after every task addition? I want to be able to perform a Quicksilver action and know that the next time I visit OO all my tasks are completely synced up.

Thanks, this is a great script!


Nik's picture

Both of those suggestions

Both of those suggestions run very much counter to the design and methodologies inherent in Kinkless GTD. If all you want is a list of actions and projects, you may be better off with a simpler system.

In any case, I’ve halted development on these KGTD scripts. You are, of course, free to modify them as you see fit. The KGTD Remote Sync script on my site will point you in the right direction to fire off a sync every time you send a task.

Nik's Latest Crappy Software


avartan's picture

THanks for the pointer. I

THanks for the pointer. I modified your script to accomplish my goals. Not sure I understand why both of my desires run “very much counter” to the design and methodologies? I only use GTD for “Work”, and it doesn’t make much sense for me to have a bunch of empty contexts. Maybe I’m just not a hardcore GTDer yet.

Can you explain why auto-Syncing is “bad”? Am I losing something in terms of working the system optimally?

Thanks, Alex


Nik's picture

Glad you got the scripts

Glad you got the scripts working properly for you.

As for why it runs counter… Kinkless GTD has a very long sync process that does more than just sort out tasks into their own section. It also archives things, sends ‘em to iCal, etc. So firing a sync every time is just slow. If you don’t mind, though, that’s not a problem.

As for the one context approach you’re using, it’s not “canonical GTD,” but neither is Kinkless in many ways. All I was thinking is that really you’re just making a list of projects and their associated actions, and then looking down your list of actions. That’s fine and well (and is actually how I deal with my own work responsibilities, since my only context is really “at work”), but it seems to me that Kinkless may be a bit “heavy” for such a simple system. I can think of other list makers that would eliminate the need for all the scripts and software and associated bugs.

But hey, if it works for you, enjoy it. :)

Nik's Latest Crappy Software


avartan's picture

Thanks for the response,

Thanks for the response, Nik. I’ve got everything working, except for the auto-sync. I copied what I thought to be the important part of the Remote Sync script to the Advanced script, but I’m getting an error firing in OO whenever the modified Advanced script runs:

Failed to Run Sync Script: NSReceiverEvaluationScriptError: 4(1)

I added the snippet of code to the end of insertIntoKGTD function:

— Save so we don’t lose data, and close the file if it wasn’t open to begin with try — OOP gets an error if this runs from the toolbar, this catches it, and no harm is caused save end try

        if KGTDClosed is true then tell kDoc to close

    end tell

    set kWindow to name of window 1 -- Use to identify document to System Events
    try
        tell application "System Events"
            tell process "OmniOutliner Professional"
                activate
                tell window kWindow
                    tell tool bar 1
                        click button "Sync"
                    end tell
                end tell
            end tell
        end tell
    on error errMsg number errNum
        display alert "Failed to Run Sync Script" message errMsg & "(" & errNum & ")" as critical
    end try
end tell

return insertTaskResults & InsertOtherResults

end insertIntoKGTD

And I also tried inserting the snippet of the remote code just above the ‘save’ code (within the tell kDoc block), which generated a Growl reported error “can’t make name of window 1 of document id=’fasldkjfsd9023’ into type reference”.

As you can tell, I’m no AppleScript coder, so I’m not sure what i’m doing wrong here. Any tips?


Nik's picture

The kDoc block is actually

The kDoc block is actually talking directly to the window itself.

You might want to move the sync part out to its own handler, something like

on runSync() end runSync

Then at each point that you want to run it, all you need to do it put in “my runSync()” and it will fire off the handler. That should also force it to be talking to the right objects or whatnot.

Nik's Latest Crappy Software


millerj's picture

Hey Kinkless

Hey Kinkless Community,

I’ve been using Kinkless for quite some time, and I just ran into a first BIG problem. When I run the script itself, everything works fine - the syntaz for context, project, note, and task all functions as advertised. But when I call the script from Quicksilver, not only is the syntax not recognized, but the task is put into the Archives by default.

This happens with both the Send to kGTD script and the Advanced script by “Nik’s Crappy Software”.

I’ve looked through the scripts, I’ve looked through on-line archives and forums, but I haven’t seend this problem reported anywhere. I’ve restarted OOP, I’ve restarted my computer, I’ve rescanned by Quicksilver catalog, all to no effect. Is this a known problem? Is there a known fix?

I’d appreciate any help the kGTD community can throw my way.

Best, Jason


Paul's picture

I use Send to kGTD to drop

I use Send to kGTD to drop something in my inbox to process later, so I don’t usually use the full syntax. But the full syntax has worked correctly when I’ve used it.

You’ve had this problem with either of two scripts, but only when you run them from Quicksilver, so your problem may be in how your script is set up in QS.

For Send to kGTD Advanced, I set a trigger for the script with:

  1. the Send to kGTD Advanced script selected in the first pane,
  2. Process Text… selected in the second pane, and
  3. then the third pane will open for text input.

This might need a QS plug-in to work, probably Text Maniputlation Actions or Process Manipulation Actions.


philologos's picture

I had problems with my QS

I had problems with my QS and had to trash the Application Support file. I then ran QS and it created a new Application Support file but it does not have the Kinkless QS scripts. Can I download them from somewhere? and if so where do I put them? Thanks.


Post new comment

The content of this field is kept private and will not be shown publicly.
  • You can use Markdown syntax to format and style the text.
  • Each email address will be obfuscated in a human readble fashion or (if JavaScript is enabled) replaced with a spamproof clickable link.
  • Images can be added to this post.

More information about formatting options

Captcha Image: you will need to recognize the text in it.
Please type in the letters/numbers that are shown in the image above.