Refresh the third pane when using triggers

[skurfer]

This fixes the same bug as #1582, but I think it's a little cleaner than claiming the search object changed (when it didn't) just to trigger a known side-effect. I'm not convinced I've tested every use case, but it seems to fix the bug without adding any.

[pjrobertson]

Cool, I'll test it later. Looks like it's better at making trigger interface activation more like normal activation

On 4 Medi 2013, at 04:14, Rob McBroom notifications@github.com wrote:

This fixes the same bug as #1582, but I think it's a little cleaner than claiming the search object changed when it didn't just to trigger a known side-effect. I'm not I've tested every use case, but it seems to fix the bug without adding any.

You can merge this Pull Request by running

git pull https://github.com/quicksilver/Quicksilver actionRefresh
Or view, comment on, or merge it at:

#1587

Commit Summary

show third pane in the correct mode when using a trigger
File Changes

M Quicksilver/Code-QuickStepInterface/QSInterfaceController.m (2)
Patch Links:

https://github.com/quicksilver/Quicksilver/pull/1587.patch
https://github.com/quicksilver/Quicksilver/pull/1587.diff

[skurfer]

Since you're obviously awake, if you have a few minutes to look at this (and assuming it's all good), we can get the next pre-release out. I'm thinking that will be the final one as well, but we can wait until the T-shirt thing is sorted out before we throw the switch. I can also then merge release into master.

[pjrobertson]

I went to sleep just before you sent this :P

I'll look this morning, I have a bit of downtime.

On 4 Medi 2013, at 22:43, Rob McBroom notifications@github.com wrote:

Since you're obviously awake, if you have a few minutes to look at this (and assuming it's all good), we can get the next pre-release out. I'm thinking that will be the final one as well, but we can wait until the T-shirt thing is sorted out before we throw the switch. I can also then merge release into master.

—
Reply to this email directly or view it on GitHub.

[pjrobertson]

I'm still a little worried we might be missing something. If you look at the only other place that calls updateIndirectObjects (QSSearchObjectView.m:L453) you'll see that there's also a call to [self updateViewLocations] - should we do that as well?

(That was my reasoning behind just saying the action object had changed - I was worried we would never be able to replicate everything that call does. Perhaps replacing your added line with a notification post for searchObjectChanged would be cleaner?)

[pjrobertson]

But seems to work fine of course.

[skurfer]

you'll see that there's also a call to [self updateViewLocations] - should we do that as well?

It looks like all that does is show or hide the third pane. Since we’re addressing the case where no selections have changed, it should already be in the right state (and it seems to work in practice). You think?

Perhaps replacing your added line with a notification post for searchObjectChanged would be cleaner?

If you check, there’s only one place observing that notification and it’s QSInterfaceController, so we could just call searchObjectChanged directly. Looking at that method is how I ran across updateIndirectObjects. I think that’s the only part of the method that matters.

[pjrobertson]

I think that pretty much answers that :)