Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.

You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.

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 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. If you have some other usage ideas, I'm listening.

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.

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 comma2. Current pane extends vertically (like a stack?)

Just a random thought

Quote

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!

Quote

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 comma2. 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.

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.

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.

There is a new jsmath plugin that eval javascript as a way to evaluate mathematical expression. Start a query with = on the first pane to trigger it. It work well but doesn't handle the display exactly the way I would like : The perfect thing ihmo would be to have a custom display on the first pane that display both the expression and the result, then a second pane with the operation. The current thing use 3 panes. I think that it might be worthwhile that we use some specially named values that skins could detect and handle display for a large number of types instead of handling types individually like we do today : skins could be more versatile that way ihmo.

I've also fixed the collecter things as ewemoa suggested => please use now collector.js for your plugins now.

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.

There is a new jsmath plugin that eval javascript as a way to evaluate mathematical expression. Start a query with = on the first pane to trigger it. It work well but doesn't handle the display exactly the way I would like : The perfect thing ihmo would be to have a custom display on the first pane that display both the expression and the result, then a second pane with the operation. The current thing use 3 panes. I think that it might be worthwhile that we use some specially named values that skins could detect and handle display for a large number of types instead of handling types individually like we do today : skins could be more versatile that way ihmo.

Looking forward to checking these bits out...however, I don't see them in the latest zip. I tried downloading with 2 browsers but didn't notice any difference. For reference, the MD5 of what I ended up with was:

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.

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 :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.

Quote

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

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

Quote

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.

Regarding the "for in" construct, I remember something about possible problems in some circumstances if hasOwnProperty is not used to check that an iterated key is not inherited. I'm not sure of what the precise details are, but FWIW, the following is from the Options page of jshint:

Quote

This option requires all for in loops to filter objects' items. The for in statement allows for looping through the names of all of the properties of an object including those inherited throught the prototype chain. This behavior can lead to unexpected items in your object so it is generally safer to always filter inherited properties out as shown in the example:

for (key in obj) { if (obj.hasOwnProperty(key)) { // We are sure that obj[key] belongs to the object and was not inherited. }}

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.