applescript that provides its own third pane items

[David Rees]

I had an applescript idea that I think could be very useful. What if applescripts could provide their own third pane items items?

Right now an applescript can indicate a subset of the global catalog by indicating the indirect types. But that is filtering against the global catalog without any awareness of the first pane object.

Instead, what if we added a "indirect choices" handler that allowed the applescript to indicate a list of third pane choices for the user. The script could build and return the third pane choices based on the first pane object. QS would show them in the third pane, allow the user to pick, then call the open handler normally with the items and selected indirect items.

For example, a script could allow copying text to a particular header inside a word document:

get indirect choices _items_

  -- cool applescript here that looks at _items_ to build a text list of choices

  return { "text list of headers in document" }

end get indirect choices

Or it could be used to handle variations on the action, for example for a "copy to server" script:

get indirect choices _items_

  return { "normal", "force" }

end get indirect choices

Or the script could filter the third/indirect items to the ones that mattered for the first pane object.

get indirect choices _items_

  return { "only folders/servers/URLs than make sense for _items_" }

end get indirect choices

d

 

 

[Jon Stovell]

That's a good idea. One might need to play with the syntax a little, but the ability to define a list of choices in the third pane would be great.

[Lucas Garron]

This is moving further in the direction of "Applescipt files as quick/dirty/simple/easy/custom/hackable plugins". I seem to remember some issues about this, but I can't find a general one right now -- does anyone know of one?

»Lucas Garron

--
You received this message because you are subscribed to the Google Groups "Quicksilver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blacktree-quicks...@googlegroups.com.
To post to this group, send email to blacktree-...@googlegroups.com.
Visit this group at http://groups.google.com/group/blacktree-quicksilver.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Rees]

Yes, that is really what I would like to do. Better script support could open up QS to a much wider range of developers. While optimally I would like to have ruby/python/bash, really just better AppleScript would be a great step since developers can then use it as a bridge to other languages.

The other thing I would like is the ability to add an object tree to QS from a script. For example, I can easily write a script to walk headers in google docs, word, orgmode, etc. What I am missing is an easy way to add these object/links into the QS catalog. Essentially I'm talking about a catalog entry type that allows you to bulk add objects. The most flexible would be an applescript that has a "get catalog" action that just returns them. That would allow bunding the catalog and "open" handlers in the same script file which would be very useful for sharing. 

You could then combine that with the existing Pane 2 scripts functionality to do all kinds of things. Even without having to introduce a new object type. For example, in a single script file using the "get catalog" action and an "open" action I could add the ability to navigate through all my orgmode headers and do refile/move/print/delete actions on them.

If you go one step further and say that the "get catalog" action or the catalog file can indicate what types the objects it returns are, then you can narrow the "open"  actions to only show up for those object types using "get direct/indirect types" action. Still all within a single script file.

A less flexible, but perhaps simpler approach to get custom objects into the catalog would be a catalog source that points to a file of objects/links (perhaps with object types as well). It sounds like Defaults Reader may be a specialized example of this, but I can't find any doc on how to use it.

d

»Lucas Garron

To unsubscribe from this group and stop receiving emails from it, send an email to blacktree-quicksilver+unsub...@googlegroups.com.

[1.61803]

On Sunday, January 12, 2014 11:49:19 PM UTC+1, David Rees wrote:

Yes, that is really what I would like to do. Better script support could open up QS to a much wider range of developers. While optimally I would like to have ruby/python/bash, really just better AppleScript would be a great step since developers can then use it as a bridge to other languages.

I think that would allow some of us to make more robust (applescript) actions which would never make it into the code for whatever reason and thereby filling some requests — or at least, trying to…:)

I guess you could add 'custom third pane items in AppleScript' and 'get catalog AppleScript command' to the tracker as feature requests.

[Jon Stovell]

I'm not a coder so much as a power-user, so I may be wrong, but I am pretty sure that trying to define things to add to the catalog inside of an AppleScript that is meant to be run as an action in QS's second pane wouldn't make sense. QS's logic starts with the catalog, not the actions. First the user must bring up an item in the first pane, and then on that basis QS goes and finds all the applicable actions to offer. So the items that the script applies to have to be in the catalog (or at least, in the first pane, since you can get things in there by various methods besides having them already in the catalog) before the script will ever be called.

That's not to deny that it could be very useful to have an AppleScript-based method for adding catalog items. It's just that adding items to the catalog is an entirely different function from executing actions on items brought up in the command window, so you'd need to use two separate scripts that were run at two separate times to do that. Specifically, you'd want to run your Add Items To Catalog script whenever it was time to update the catalog, and your action script whenever the user choose to run it.

[Rob McBroom]

On 12 Jan 2014, at 17:49, David Rees wrote:

Yes, that is really what I would like to do. Better script support could open up QS to a much wider range of developers. While optimally I would like to have ruby/python/bash, really just better AppleScript would be a great step since developers can then use it as a bridge to other languages.

I’d be far more interested in the ability to add to the catalog and write actions using one of those other languages.

Most of what you see in the interface can be expressed as a property list. So there could be some new thing that just needs the path to a command (or it could just run every script in a particular directory). You write the command and have it spit out a property list.

Here’s an example (in Python) that uses actual items from Quicksilver’s catalog and turns them into something you can manipulate.

import os
import plistlib
from pprint import pprint

catalog_entry_id = 'QSPresetHome'

index_path = os.getenv('HOME') \
    + '/Library/Caches/Quicksilver/Indexes/' \
    + catalog_entry_id + '.qsindex'

tag_objects = plistlib.readPlist(index_path)

pprint(tag_objects)

So you’d just reverse the process in your script. That is, do what needs to be done to create an array of objects and dump it out as a property list.

Actions can also be defined in this way, including the types that should be allowed in the first and third panes. (In fact, most of them are defined in property lists.) But then what would the action do and how? Getting it to run some arbitrary code in a script is a bit trickier.

There’d be a similar problem when it came time to actually get objects for the third pane. How would it ask for a list and how would you build up the list? More often that not, you want to use existing objects from Quicksilver’s catalog, but an external script wouldn’t have access to them since they’re only in memory. That would be a problem for AppleScript as well.

It used to be possible to create plug-ins that used Python for most things. I’ll see if I can find some and figure out how it worked.

--
Rob McBroom
http://www.skurfer.com/

[David Rees]

Using property lists sounds like a cool approach if that is how QS already thinks. And data formats are even easier than defining an API/data format. Perhaps the catalog source could just define a directory where QS could find the files. And as you said, the scripts are run on their own using cron or whatever is appropriate.

For third pane my thinking was that 3rd pane objects can be in two categories. Some are arbitrary, but some are tied to the first pane object in a way the script could figure out the options. 

--
You received this message because you are subscribed to a topic in the Google Groups "Quicksilver" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/blacktree-quicksilver/lUmYHXEaGvs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blacktree-quicks...@googlegroups.com.

[David Rees]

Hi Jon,

Not to distract from Rob's property list suggestion, but you can do multiple things in a single AppleScript. Interestingly each script actually supports multiple actions, which the caller can use at different times.

QS already takes advantage of this because it calls the "get types" action at startup (so it knows when to make the action available) and then calls the "open files" action when the action is actually used. More info here - http://qsapp.com/wiki/AppleScript_Actions.

I am suggesting a third action type "get catalog" which would be called each time QS does a catalog scan. So there would actually be three different ways the script is called, all within the same AppleScript.

d 

--

You received this message because you are subscribed to a topic in the Google Groups "Quicksilver" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/blacktree-quicksilver/lUmYHXEaGvs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blacktree-quicks...@googlegroups.com.

[Brian Bucknam]

On Monday, January 13, 2014 6:12:37 PM UTC-8, David Rees wrote:

I am suggesting a third action type "get catalog" which would be called each time QS does a catalog scan. So there would actually be three different ways the script is called, all within the same AppleScript.

"+1"

Cheers,

Brian

 

[1.61803]

On Monday, January 13, 2014 8:29:02 PM UTC+1, Rob McBroom wrote:

Most of what you see in the interface can be expressed as a property list. So there could be some new thing that just needs the path to a command (or it could just run every script in a particular directory). You write the command and have it spit out a property list.

From Quıcĸsıɩⅴεʀ User’s Guide 0.14, p 33

'The Defaults Reader allows you to index some keys from preferences files (.plist), though it’s a little flakey (doesn’t deal well with paths), is difficult to configure (you must manually specify each key) and doesn’t let you change the plist file, so it doesn’t seem useful.'

I haven't tried it yet and I couldn't find any details nor issues in the tracker. Does it still work?

Would specifying an AppleScript Object Type be a feasible workaround?

For instance, if I could specify a (custom) 'qs.object' for AppleScript actions, I could use any form of preset source or run a script with cron to update a file with something QS can parse.

on get direct types

return {"qs.object_Custom_MyCatalog"}

return {"qs.object_Custom_MyDefaultsReader"}

return {"qs.object_Custom_MyGroup"}

return {"qs.object_Custom_MyCustomCatalog.txt"}

end get direct types

on get indirect types

return {"qs.object_System_Devices"}

end get indirect types

on get argument count

return 2

end get argument count

I think, it'd be just redirecting or making existing objects available for AppleScript (and everything you could bridge with it). 

[Rob McBroom]

On 23 Jan 2014, at 4:54, 1.61803 wrote:

> From Quıcĸsıɩⅴεʀ User’s Guide 0.14, p 33
> 'The Defaults Reader allows you to index some keys from preferences
> files (.plist), though it’s a little flakey (doesn’t deal well
> with paths), is difficult to configure (you must manually specify each
> key) and doesn’t let you change the plist file, so it doesn’t seem
> useful.'
>
>
> I haven't tried it yet and I couldn't find any details nor issues in
> the tracker. Does it still work?

Yes, and it’s even been enhanced slightly in the past year or so. The
internal Core Support and Finder plug-ins are using it for a few things
right now, so you can check there for examples. Search the property
lists for “QSDefaultsObjectSource”.

[David Rees]

FYI, I added https://github.com/quicksilver/Quicksilver/issues/1831 for this. I looked at some of the code, and I must admit I still don't see how to use Defaults Reader to import catalog items. If someone could pull a simple example together I think that would really help. As I mentioned above, I think this could enable a lot of interesting integrations. 

d