Just thinking that one of the common uses for setInput would be when you zip a file, or do something else with a file to reopen Qatapult with the ouput file focused.

Thanks for the example situation.

Along the lines of zipping / archiving, do you have any UI ideas how one might approach multiple files / folders being selected for zipping / archiving?  In QS, there was the "comma trick", but I'm wondering whether there might be better alternatives...

The comma trick seems good to me. I had a look to integrate that this WE. This is really a core change and there is well over 50 places where I must fix things, so I will really need some quiet time to plug that. I don't know what could make it better,

I don't know about the aesthetics of it, but the following display idea came up:

1. Press comma
2. Current pane extends vertically (like a stack?)

Just a random thought

---

I think that allowing Qatapult to be a drop target might be nice so that we could drop files directly from the explorer into Qatapult. I would certainly use that.

Same here!  Drop target would be great.  Also being able to drag from Qatapult would be nice too -- quickly find something with Qatapult for use elsewhere (until there's a plugin ).

---

One thing that I've wanted in FARR is the ability to drop items on to an individual result.  I have FARR configured to use "Blank search shows files from launch history..." -- and I've wanted to use that as a kind of dock to drop items on to, but last I checked, this doesn't work.  So certainly would be nice to have this in Qatapult!

---

As a status update, I'm doing two things right now :
- fix memory leaks (I unplugged my memory leak finder to find a bug and left it unplugged. Leaks are not easier to find in larger quantities )
- implementing a paste using the new DynaWrapper code. I have working clipboard code for text already. I'm also discovering that this is not a very easy environnement to develop into, but may be it will be easier as I write more wrappers.

Wishing you luck in these matters...

---

By the way, what do you think of the idea of a command history like in command line shells?  IIRC, in bash and other *nix shells, Control-P / Control-N is used for previous command / next command.

If there were hooks for a plugin to register to execute code upon certain key sequences as well as a chance to operate on command content before Qatapult executes the command, I'd be interested in writing a plugin for command history

I don't know about the aesthetics of it, but the following display idea came up:

1. Press comma
2. Current pane extends vertically (like a stack?)

I think, I'll let skins handle that. I was considering doing something similar to QS as a default : putting extra arguments icon under each items. But that's going to be totally customisable in others skins.

History is something you'd need probably more access that you currently have. The history I though was most interesting is an history of rules, I really think that objects are insufficient, you want to repeat an action usually, not get the previous object. However I totally like the idea, and this is going to find its way into Qatapult.

Collecter is a a mistake. Thanks.

FWIW, AutoHotkey.dll is what I've been using for at least one earlier Qatapult plugin -- the Calculate one.

For reference, below is a bit from Calculate.ahk:

; XXX: ScriptText should have #Persistent and a function def
;      Pass the script's text using ScriptText
;      Pass the name of the function in using FuncName
RunFuncInScriptWithInputText(ScriptText, FuncName, InputText)
{
  ; XXX: before didn't need to muck with path...
  AhkDll := AhkDllThread(A_ScriptDir . "\..\AHK\AutoHotkey.dll")
  ;OutputDebug, % "Script content: " . ScriptText
  AhkDll.ahkTextDll(ScriptText)
  OutputDebug, % "Value passing to script: " . InputText
  Result := AhkDll.ahkFunction(FuncName, InputText)
  OutputDebug, % "Script returned: " . Result
  AhkDll.Terminate()
  Return Result
}

Calculate(InputText)
{
  FuncName := "Calculate"
  ScriptText := "#Persistent`n`n"
              . "#NoTrayIcon`n`n"
              . FuncName . "()`n"
              . "{`n"
              . "  Result := " . InputText . "`n"
              . "  Return % Result . A_Space`n" ; XXX: convert to string
              . "}`n"
  Result := RunFuncInScriptWithInputText(ScriptText, FuncName, InputText)
  Result := RTrim(Result)
  ; XXX: consider whether to modify trailing zeros
  Return Result
}

AutoHotkey.dll aside

AutoHotkey.dll has some nice features and the developer (HotKeyIt) is usually pretty responsive about bug reports, but docs for his things are not always up-to-date.

I've uploaded a new version. This is the ground for the future settings ui that should be more usable. You can now enable and disable plugins from the UI. There is also a ton of less memory leaks.

Thanks for the new version!

Just a quick note -- I no longer see "Quit" or "Reload".  This is with a fresh install on Windows XP SP3.

Any ideas?

Oups, I forgot to say that I moved all Qatapult verbs under the Qatapult file : type Qatapult and look at the available verbs

...the missing plugins, they were still excluded from the package. The last version should contain all of them.

I see them now.  Thanks!

please use now collector.js for your plugins now.

FWIW, in the latest download, I see the following file names:

• jsmath.collecter.js
• putty.collecter.js
• snippets.collecter.js
• uninstall.collecter.js

Also, in Qatapult\Lib there is FileGetVersionInfo.ahk -- I think this is unnecessary.

There are new functions that you can use by doing a require("lib/clipboard.js") : they are clip and paste. Paste can optionally take a text to paste. You can also do a sendinput but it's currently limited to printable characters only. If you feel like improving it, I'll be happy to take your version and put it in Qatapult.

Both functions are built with direct call to win32 dll from javascript using the dynamic wrapper. Have a look to clipboard.js in lib if you want to see what it looks like.

I found clibpboard.js and test.command.js in plugins\commands -- taking a look now.

Thanks for this example code.

About the collecter plugins, I feared that people would copy plugins folder over the old one without deleting the previous one. That's what I do actually. I feared that it would lead to entries being duplicated so I just leaved collecter for the moment. However if you create a new plugin collector.js is the correct name to use. Just thinking about it, I think that I could let qatapult rename theses files for consistency.

Reload, Quit and Options should now appears under the Qatapult entry. Here is what I got :
[attachthumb=#]
Is it different from what you have ewemoa ?

I agree with you about the history ewemoa. I was considering doing a global history. May be there should be some way to narrow the history to things that have the same start as the current selection so that we could get an history of math results and an history of operations on some file.

You're right about clipboard.js. It should be there. It's actually useless as it's not loaded. It doesn't do anything. The whole code about clipboard is in test.command.js that I should probably rename. I probably considered that it should only be called by command plugins so there wasn't too much needs to put it available as a library. I'm not sure if that's a good choice.

this.length+=desc[t].size;

clipboard.js is actually useless, this code is incorrect.

for(var a in args) { break; }

This is a trick to have a take the value of the first available item. I iterate once then exits. It do that because I describe types of the Struct function as an array of object : [{key:value}]. This line allows me to get the name of the key. I don't know of any other way to get that in javascript.

I was considering doing a global history. May be there should be some way to narrow the history to things that have the same start as the current selection so that we could get an history of math results and an history of operations on some file.

Narrowing / filtering history sounds like an interesting idea.  May be it's worth trying if it's easy to implement.

Thanks for the explanations regarding the 2 bits of code.

No pb.

About the for in construct, yes it can be annoying if it match some extra properties defined on prototype object. I will avoid to do that, it is somewhat seen as a bad practice now because of such issues.