Re: Event Triggers (was Re: Quicksilver Interface Pops Up, then Disappears)

[Tim Visher]

On Thu, Jul 11, 2013 at 3:31 PM, Rob McBroom <mailin...@skurfer.com> wrote:
> On Thu Jul 11 2013 at 15:05:39, QuoinDesign.com wrote:
>> I had just installed several new plugins: Event Triggers being the most
>> suspect. But I disabled it and a bunch of others, restarted, and the problem
>> persists.
>
> Event Triggers are awesome. Use them! :-)

Woah, woah, woah, woah, woah.

Event Triggers completely slipped past my sensors! Tell me more about
these things. Who's using them? What are you using them for?

Give me inspiration because these sound awesome!

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

[1.61803]

The bible doesn't mention them (not that one, QS's by Howard Melman) — but there's some documentation in the plugin itself. Copy/paste from that source, just because it's worth mentioning.

Event Triggers

With this plug-in, Quicksilver can run actions automatically as things happen on your system. For example:

• When the screen saver activates, pause iTunes.
• When the computer wakes from sleep, open Mail.
• When the network changes, run a shell script.

You can assign triggers for the following events:

• Application Launched
• Application Quit
• Quicksilver Launched
• Quicksilver Launched (at Login)
• Quicksilver Will Quit
• Active Space Changed
• Computer Will Shut Down
• Computer Will Sleep
• Computer Woke Up
• External Display Changed
• Fast Login
• Fast Logout
• Ethernet Changed
• Disk Inserted
• Disk Ejected
• Disk Will Eject
• Screen Saver Started
• Screen Saver Stopped

Other plug-ins may define additional events.

Trigger Settings

Event

Choose the event you want Quicksilver to watch for.

Delay

When the event happens, wait a certain number of seconds before running the trigger. It doesn't need to be a whole number. For instance, 0.1 and 2.5 are valid values.

Ignore Repeats

For certain events, like "Application Launched", OS X might send multiple redundant notifications in rapid succession. Use this setting to prevent the trigger from running too many times.

If you enable this setting with a delay of n seconds, when multiple events occur within nseconds of each other, the trigger will only run once (n seconds after the last notification is sent).

It might take some experimentation to get this right. A tip is to initially set the trigger up to do something obvious, like show some text using the Large Type action or append some text to a file, and see how many times it runs.

[Rob McBroom]

On Fri Jul 12 2013 at 10:36:35, 1.61803 wrote:

The bible doesn't mention them (not that one, QS's by Howard Melman) — but there's some documentation in the plugin itself. Copy/paste from that source, just because it's worth mentioning.

Tragically missing is any mention of one of the coolest features: The “Event Trigger Object” proxy. Looks like I updated the documentation back in April, but never submitted the changes. I’ll work on that.

I’ve also been meaning to write a blog post about how to use that proxy. One example, to give you an idea: Set up a trigger for the “Screen Captured” event. The “Event Trigger Object” proxy will refer to the resulting file, so you could have the trigger do something like “Event Trigger Object ⇥ Move To… ⇥ Pictures”.

The good news is that a lot of new events were defined in various plug-ins earlier this year (like the Screen Capture ones). You’ll see quite a list when setting up a trigger, depending on which plug-ins you have installed. Most of them pass along an object you can use with the proxy in a trigger.

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

[1.61803]

On Friday, July 12, 2013 9:07:22 PM UTC+2, Rob McBroom wrote:

Tragically missing is any mention of one of the coolest features: The “Event Trigger Object” proxy. Looks like I updated the documentation back in April, but never submitted the changes. I’ll work on that.

I’ve also been meaning to write a blog post about how to use that proxy. One example, to give you an idea: Set up a trigger for the “Screen Captured” event. The “Event Trigger Object” proxy will refer to the resulting file, so you could have the trigger do something like “Event Trigger Object ⇥ Move To… ⇥ Pictures”.

I like others I think often find myself searching QS's user guide, qsapp.com, changelog, github.com, this forum and googling around for things whose knowledge sometimes belong only to the initiated ;-)

I don't use rss, fb, twitter nor other social networks and rely only on mail because of focus and time constraints — but I do follow this list as QS is my most used and useful application.

How can we not overlook changes and new features?

How can we contribute without increasing the dispersion mentioned above? 

[Rob McBroom]

On Sat Jul 13 2013 at 09:56:53, 1.61803 wrote:

I like others I think often find myself searching QS's user guide, qsapp.com, changelog, github.com, this forum and googling around for things whose knowledge sometimes belong only to the initiated ;-)

You will never know everything it can do. None of us will.

I don't use rss, fb, twitter nor other social networks and rely only on mail because of focus and time constraints — but I do follow this list as QS is my most used and useful application.

How can we not overlook changes and new features?

The release notes should cover all that for the application, but not the plug-ins. Plug-ins are pretty well documented these days, but finding out what’s changed isn’t necessarily easy. The latest changes should be visible under each one on the web site.

In the next release, there’s a new plug-in updater that will detail the changes in each one.

The blog is usually pretty good about fleshing out some of the changes, though unless you want to manually check it, RSS is probably the best way to follow that. There’s also an RSS feed for plug-in changes, but that should be less of an issue after the next release.

[1.61803]

On Tuesday, July 16, 2013 8:45:40 PM UTC+2, Rob McBroom wrote:

The blog is usually pretty good about fleshing out some of the changes, though unless you want to manually check it, RSS is probably the best way to follow that. There’s also an RSS feed for plug-in changes, but that should be less of an issue after the next release.

Yeah for the moment maybe I can restore RSS with if this then that.

You will never know everything it can do. None of us will.

I was thinking more of converting QS's excellent but outdated user guide into a wiki integrated in qsapp.com so that it could be updated with the latest improvements, and dynamically (per keywords in subject) link each topic with related posts in this forum and issues at github. And that wiki could send updates via RSS or mail. It'd be nice to also hear Howard Melman's opinion.

[Howard Melman]

A wiki is often discussed and originally there was one. It fell out of date and was one of the reasons I wrote the manual. I also used a creative commons license for the manual so it could be repurposed.

QS has a lot of inter-related parts and is very hard to describe in a linear manner so linking is really nice. However IMHO the tools typically found in a wiki make it hard to keep up-to-date. Something like Find & Replace that you'll find in a word processor like Pages is remarkably useful. One of the problems I had when first writing the manual was that many features in QS didn't have consistent names so it was hard to write about. Part of the work was agreeing on terminology and getting it incorporated into QS. While there are a few outstanding examples, that's much better now than its ever been.

And FYI, at the time I went through all 100+ plugins reading their .plists to find all the features and trying just about every one to see if they worked. I felt like I knew about 95% of QS at a user level. The new plugin help files that have been added are very helpful, but I still go through the .plist files while updating the manual.

Howard

[1.61803]

On Wednesday, July 17, 2013 5:28:34 PM UTC+2, hmelman wrote:

A wiki is often discussed and originally there was one. It fell out of date and was one of the reasons I wrote the manual. I also used a creative commons license for the manual so it could be repurposed.

I'm no MediaWiki user but I googled around for ways to convert PDF files to MediaWiki's format. What is the original file format of the manual? Would you make it available?

 

QS has a lot of inter-related parts and is very hard to describe in a linear manner so linking is really nice. However IMHO the tools typically found in a wiki make it hard to keep up-to-date. Something like Find & Replace that you'll find in a word processor like Pages is remarkably useful. One of the problems I had when first writing the manual was that many features in QS didn't have consistent names so it was hard to write about. Part of the work was agreeing on terminology and getting it incorporated into QS. While there are a few outstanding examples, that's much better now than its ever been.

I don't use wiki tools but I doubt that such functionality is missing — but above that, we wouldn't need to unify terminology since fortunately you've done already.

but I still go through the .plist files while updating the manual.

So, the user guide is undergoing updates after all?

Mmh, maybe I'm poking my nose in bound territory and things are just fine as they are for most. I do think though that a wiki would be much better than scattered scripts, guides, videos and blog posts. I'd be willing to eventually collaborate — I don't know how the hosting and maintenance of qsapp works either.

[Tim Visher]

On Wed, Jul 17, 2013 at 3:49 PM, 1.61803 <iam...@gmail.com> wrote:
> Mmh, maybe I'm poking my nose in bound territory and things are just fine as
> they are for most. I do think though that a wiki would be much better than
> scattered scripts, guides, videos and blog posts. I'd be willing to
> eventually collaborate — I don't know how the hosting and maintenance of
> qsapp works either.

FWIW, I also find it difficult to follow updates to QS. The blog is
great, but there's so much that 𝑄uıcĸsılⅴεʀ does that it would be
very interesting to have some sort of aggregate updates reporter
(maybe that's some of what Rob's been mentioning).

I'm thinking of something like https://twitter.com/melpa_emacs

Some sort of Planet 𝑄uıcĸsılⅴεʀ blog aggregator might also be useful.

Then again, as Rob said, we'll never know everything it does. :)

[1.61803]

On Thursday, July 18, 2013 5:34:55 PM UTC+2, Tim Visher wrote:

Some sort of Planet 𝑄uıcĸsılⅴεʀ blog aggregator might also be useful.

I agree with that except for the blog term. I explain.

My idea is to reuse the user's guide in a wiki and expand it putting e.g. a howto of some shell command in the Terminal section, an applescript action for iTunes in the iTunes' plugin section, or new features, and so on.

And get the changes made to this wiki delivered via rss.

[Patrick Robertson]

We've tried in recent years to improve the info on updates (RSS for plugins, blog, change log, twitter), but it's still too fragmented.

QS is an open community and project, so if any of you guys are in the mood to suggest alternatives or even to implement that would always be appreciated. The Achilles heel for almost every developer is that they're always too interested in developing to bother with the other stuff (I actually think we have some amazing devs here who do support, development, blogs, wiki updating… everything so we're really lucky!)

Phil's been great of late helping us out on the Twitter/blog front, but if anybody else wants to help out, we're always open…

:)

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

[Rob McBroom]

On Thu Jul 18 2013 at 22:03:57, Patrick Robertson wrote:

QS is an open community and project, so if any of you guys are in the mood to suggest alternatives or even to implement that would always be appreciated. The Achilles heel for almost every developer is that they're always too interested in developing to bother with the other stuff (I actually think we have some amazing devs here who do support, development, blogs, wiki updating… everything so we're really lucky!)

I think this question should be (and perhaps was) directed at the community, and not the devs specifically.

My attitude for any project like this where I’m on the outside looking in (which I was with QS for many years) is this: Given the small number of people willing and able to do the programming and the limited time they have, what would I like them to be working on? :-)

Phil's been great of late helping us out on the Twitter/blog front, but if anybody else wants to help out, we're always open…

I’ve said it before, but what Phil does is worth 4 programmers. And don’t overlook users like Jon Stovell that answer tons of questions here.

[1.61803]

On Friday, July 19, 2013 3:49:43 PM UTC+2, Rob McBroom wrote:

I think this question should be (and perhaps was) directed at the community, and not the devs specifically.

If you mean these questions, those were directed at the devs and host of qsapp.com. But I appreciate any feedback.

 

My attitude for any project like this where I’m on the outside looking in (which I was with QS for many years) is this: Given the small number of people willing and able to do the programming and the limited time they have, what would I like them to be working on? :-)

Clubbing keyboards of course, methinks :D — and I hope in a far future to contribute with a line of code or two.

I didn't mean the devs or host of qsapp to implement the idea I outlined in the previous posts. I would give it a try in the spare time of my spare time. In order to do that I'd need 1. feedback from the devs/community (real feedback like great! / ok, but… / just leave it as it is / no, your idea sucks!), 2. ideally the user's guide source, 3. qsapp account, 4. some kind of commitment that new content would expand the wiki.

Is does too much asking, right?

[philostein]

Thanks for the support guys, I'm just glad there's a Quicksilver to write about. :)

@1.61803

Regarding a new Quicksilver information source, I think the best way is to get stuck in, set something up yourself, and then see if others would like/be able to help out. There's a fair amount of cross-cooperation in Quicksilver, but most contributors have their primary focus, be it developing, writing manuals, blogging, troubleshooting or filing bug reports/feature requests. Perhaps aggregation can be your speciality. :)

It is very easy to miss new info on Quicksilver (I missed this thread), so I would really appreciate a gathering of all the threads, issues, commits, wiki updates and so forth into one place.

[1.61803]

@philostein, lack of _real_ feedback from the devs or the community a.k.a. the usual suspects was a no-go for me. 

[Etienne Samson]

Le 8 sept. 2013 à 18:19, 1.61803 <iam...@gmail.com> a écrit :

> @philostein, lack of _real_ feedback from the devs or the community a.k.a. the usual suspects was a no-go for me.

Maybe I'm gonna feel a little rude, but I can't even begin to *understand* what you mean by "_real_ feedback", and "the usual suspects was a no-go for me". I'm gonna give you a bunch of feedback ;-).

You're asking questions in that thread about how cool it would be to have the user manual converted to a Wiki. I find that to be a wonderful idea, as it could decouple the *huge* amount of work it represents from (poor) @hmelman who's the only one with the master files. But, as was pointed out repeatedly, we *do* not want that to be useless — the Wiki has already disappeared once when blacktree.org disappeared, along with the complete forum and the bunch of people that were around, the only "face" I recognize from that time is Howard — so porting that guide and verifying the info (especially the missing one) means a huge investment from a bunch of us, you (hopefully) included. Let's say that right now, I feel more-or-less status-quo-ed with having the Manual a PDF maintained by somebody else (Sorry Howard :-S).

And now, you jump out of nowhere with that weird sentence, and I don't get it, you've had a response from Patrick, Rob, Philostein, and now me. You've been read by pretty much the complete developer team (even those that are just lurking), and even though everyone said that converting the manual was a great idea, you were warned that unless you have *very* specific problems (I can write scripts that do all sorts of ugly things — I converted 3000 Word files to HTML to CSV using Ruby not too long ago — yeah ugly) you won't get much hand-holding. Personally, I never touched the Wiki — apart in doing some proofreading on the Plugin Development guide — and I can't even remember the password for qsapp.com. I absolutely miss time to work on QS*, like most of the others devs. I mean, if you want to help, and want to work on converting the Guide**, then GO FOR IT ;-).

Sorry if I felt harsh, but that thing is kind of hard to hear (for me at least).

* Well that's not exactly right, I'm having fun on Letters, it's just that QS's code is old (dating back from 10.1/2, that's before there were iPhones !) and even though we do what we can to keep it working, it is a hard and daunting task because we have no safety net in the form of tests to protect us from our good ideas (like I would have wanted to have multiple arguments by action => a mess, cleanup the views and stuff part of QS => a mess).</rant>

** I'm not even sure what's Howard opinion on that one, though the part on Creative Commons let me think it's ok with that.

Peace,
Etienne Samson
--
samson....@gmail.com

[1.61803]

@Etienne, I think you read too much into my post and those of others in this thread...and maybe a read too little :)

I never asked for help to convert it to a wiki. Check the four points in my third to last post.

I mean with real feedback to make a plan as to how documentation could be done if I came up with a nice and tidy wiki. Then, why convert it if no one's gonna use it after all?

Well, never mind.

[Etienne Samson]

Le 8 sept. 2013 à 23:04, 1.61803 <iam...@gmail.com> a écrit :

> @Etienne, I think you read too much into my post and those of others in this thread...and maybe a read too little :)

Yeah, that's what I suspected, sorry ;-).

> I mean with real feedback to make a plan as to how documentation could be done if I came up with a nice and tidy wiki. Then, why convert it if no one's gonna use it after all?

I think I handled feedback already. Also, I'm a developer, I don't need no manual ;-). But, in the interest of the many users of QS, I find this is a good idea.

> I never asked for help to convert it to a wiki. Check the four points in my third to last post.

This one :

>> 1. feedback from the devs/community (real feedback like great! / ok, but… / just leave it as it is / no, your idea sucks!)

As I said, I'm ok with that, so "great!" from me.

>> 2. ideally the user's guide source

That depends on Howard.

>> 3. qsapp account

That depends on Patrick (or Rob) maybe.

>> 4. some kind of commitment that new content would expand the wiki.

Hmm ? More content => expansion ? I think I see what you mean though. I'm not much a Wiki person though, maybe if I find the time, I will help ;-).

Cheers,
Etienne Samson
--
samson....@gmail.com

[1.61803]

On Monday, September 9, 2013 12:35:34 AM UTC+2, Etienne wrote:

>> 2. ideally the user's guide source
That depends on Howard.

He never answered. He pointed out the PDF's CC license though. I started converting it with Acrobat but then left off for the reasons mentioned. From source file should come better.

Also, I don't know if he's actually updating the guide, see last sentence of his post in this thread.

 

>> 3. qsapp account
That depends on Patrick (or Rob) maybe.

Patrick handled this one last week.

 

>> 4. some kind of commitment that new content would expand the wiki.
Hmm ? More content => expansion ? I think I see what you mean though. I'm not much a Wiki person though, maybe if I find the time, I will help ;-).

I meant using the guide as the backbone for (future) documentation.

If you've already dealt with ugly conversions, AFAIR in this case text-format>html>media-wiki is the passage or use Acrobat for pdf>html.

[Patrick Robertson]

Just a quick chime in - I think what philostein actually said is spot on, and I'll reiterate!

> Regarding a new Quicksilver information source, I think the best way is to get stuck in, set something up yourself, and then see if others would like/be able to help out. There's a fair amount of cross-cooperation in Quicksilver, but most contributors have their primary focus, be it developing, writing manuals, blogging, troubleshooting or filing bug reports/feature requests. Perhaps aggregation can be your speciality. :)

The best thing (and perhaps the worst from some perspectives…) about Quicksilver is that (like all open source projects) it's completely open (license = Apache, manual = CC). Anybody can 'get stuck in' and join. Not receiving any feedback from devs or the community (incidentally - something you are a part of, so you have a say!) means just go for it.

As Etienne says, for lots of us time is limited (because we're all dealing with Letters.app :P ), so we'd often rather do, since actions speak louder than words (doesn't mean to say we don't discuss things though).

So… not hearing anything? Just go and get stuck in. Post to the community about what you've done and people might thing "that's cool" and help out. Who knows, 

Being managed by a group of volunteers means there's not much leadership (although I like to think we do well) or hand holding, so you're FREE to do what you want!

That's it from me, I want to get back to coding and not blabbering here ;-)

P.S. I believe Howard has said recently that he's updating the manual. Maybe ask him over on IRC. He doesn't (normally) bite.

[Howard Melman]

Hi all. :)

I have made updates to the manual. There are a lot to make.

I've gone through the release notes and have notes of various changes and lists of all the supported plugins. As a result of that I've updated the Quick Reference and have posted it and as far as I know it's up-to-date and accurate.

I've made inroads into the manual. I think the structure is still right. I'm very unhappy with the quality of the original writing and think it basically all needs to be rewritten (there are a lot of "you"s that need to come out). So Part I is mostly done. I've gone through and globally removed "enable advanced features" from the whole manual and some similar things. Part II is all about configuration and that needs extensive changes (and some of it was never finished). I think most of Part III (the plugins) has been rewritten (language wise) but I don't think it's been updated for the modern plugins. I have to check that. I've found lots of the examples need updating (things have changed in OS X) and that takes time too. There are still 60 references to B51 and the like.

I do make progress and then put it down for all too long. I was in fact going to get back to it this week. I know that all the images really need to be updated and that's a lot of work.

My current thoughts are to finish Parts I and III and put a draft out. And then go back for Part II (and ultimately Part IV).

I think a wiki would be great addition, though if I were doing it, I'd start from the new plugin documentation rather than the manual. It's more up-to-date, it's easier to get the list of things currently supported from it, and it's already in a wiki-like format.

Howard

[1.61803]

On Monday, September 9, 2013 3:08:40 AM UTC+2, Patrick wrote:

So… not hearing anything? Just go and get stuck in.

I might have considered that possibility — at least until I learned…

On Monday, September 9, 2013 4:38:18 AM UTC+2, hmelman wrote:

I have made updates to the manual.

Fortunately I didn't commit to the old version :-.

 

I think the structure is still right.

I agree with that.

 

I'm very unhappy with the quality of the original writing and think it basically all needs to be rewritten

I agree with that, too. I like the more concise plugin documentation's style better — which btw you could reuse in your guide I guess.

 

I know that all the images really need to be updated and that's a lot of work.

If you need, or want any help just put out a list of what's to be done.

I think a wiki would be great addition

There's already a fine wiki by philostein I guess. But your guide is more comprehensive and could be used, as I already said, as the backbone for future documentation — in a wiki format, maybe moderated, from which one could generate the whole guide or part of it as a PDF, easier to maintain, that could integrate the plugin doc and perhaps be integrated in QS itself.

A wiki started by me based on an outdated guide that's ongoing updates (!) would only add to the existing fragmentation of sources for QS — which is the opposite of what I was trying to undertake.

[1.61803]

On Monday, September 9, 2013 4:38:18 AM UTC+2, hmelman wrote:

I have made updates to the manual.

Howard, since you're the author, would you mind uploading the current version and eventually the updated one of the User Manual to Google Books (not Google Play) so that it's indexed and searchable?