Inconsistent 2nd pane focusing when UI is set to re-appear

[pjrobertson]

Since the bug #232 has been fixed, and the user interface is showing up more consistently I've come across another bug/inconsistency.

This might be something @skurfer might know about, but if not it shouldn't be too hard to fix.

Tests:
If you have the Calculator module set to return the results to QS, when it does so the 2nd pane is focused.
If you use the 'get path' action, when the UI reappears the focus is on the 1st pane.
This is the same for things like copy to... and move to...

Should the default be to focus the 1st pane or 2nd pane? In my opinion, QS should skip to the 2nd pane on any action returning something to QS

[skurfer]

Related to #225

I obviously agree that it should go to the 2nd pane, but I wonder if it should be a preference since so many people will have years of habit doing it the other way.

[skurfer]

I’ve gotten it to reliably set focus to the action pane, but I haven’t figured out why this was already happening in some cases.

[skurfer]

Wait a minute. The Calculator module is the only known example of this, right? And what does it do that’s unusual? A preference for how to handle the result. So I’ll be there’s something about the way it chooses between Default, Large Type, and Notification that’s causing this. Looking into it.

[skurfer]

Well, that got me nowhere. Cancel excitement.

[pjrobertson]

I've just tested it (sorry, I'd completely forgotten about this 'bug') and I consistently get the 2nd pane focused.
If I disable the setting you (skurfer) made in the prefs, I consistently get the 1st pane focused.

Maybe it was miraculously fixed?

Feel free to close this if you feel this is the case. I can re-open if I come across it again. :)

[skurfer]

If I disable the setting you (skurfer) made in the prefs, I consistently get the 1st pane focused.

Another clue! I was always seeing the second pane get focused, even with the new setting disabled. I figured out that if you type a formula and choose the Calculate action, the correct pane gets focus. But if you start by typing ‘=’ to get the automatic behavior, the 2nd pane gets focus. So it must be something with the formula type. Something else to look into.

[pjrobertson]

Hmm... I'd previously only been testing it with the '=' in there. Typing e.g. '.5*5' (the . to get into text mode) then using the calculate action, I still get the correct focusing of panes.

[skurfer]

Maybe you’ve got something on an unmerged branch that fixes it? I can reproduce it every time using =, but if you can’t, feel free to close this.

[HenningJ]

Right. I'm with skurfer here: using .5_5 -> calculate I get focus on the first pane, using =5_5 I get focus on the second pane.

[pjrobertson]

Hmm... Just tested with 60 and it still works for me. Perhaps I'm using
another version of the Calc plugin.

I'll email you (both) the exact copy I'm using (from my plugins folder) so
you can test it.

On 12 July 2011 19:36, HenningJ <
reply@reply.github.com>wrote:

Right. I'm with skurfer here: using .5_5 -> calculate I get focus on the
first pane, using =5_5 I get focus on the second pane.

Reply to this email directly or view it on GitHub:
#283 (comment)

[HenningJ]

Hmm...it's the same with that one. Strange.

[pjrobertson]

Here's a video incase I'm doing something different:

http://patjack.co.uk/files/calculate.mov

That's the latest head in the movie, but I've tested with 60. I have been
fiddling more with some of the objectIconModified stuff (related to
Henning's asynchro stuff) so that may have changed something. Unlikely
though.

Could it be the inconsistencies with showing other matches (results list) we
keep getting? I have 'delayed' atm (just tried and still works for me
whateverI have it set to)

:/

On 12 July 2011 20:16, HenningJ <
reply@reply.github.com>wrote:

Hmm...it's the same with that one. Strange.

Reply to this email directly or view it on GitHub:
#283 (comment)

[skurfer]

Yeah, I downloaded the version you posted to qsapp.com yesterday just in case. I assume it’s no different from what you e-mailed. I really don’t think it’s the plug-in anyway.

Here’s an additional data point. If I enter a formula using =, but tab to the 2nd pane before hitting return, the focus goes to the first pane as expected. So I wonder if it’s something about hitting return from text entry mode. I can’t think of any other actions that return something from that state, so maybe that’s why we only see it here.

[pjrobertson]

This seems to have been fixed for me. @skurfer - can you confirm there was something you did that fixed this?!

[skurfer]

No, I didn’t and I can still reproduce it. (Although I always run with the “jump to action when getting results” option, so it doesn’t make a difference in my case.)

So you’re saying that if you type =3*3 and directly hit return, you go to the first pane?

[pjrobertson]

Yep. If I have 'just to action....' unticked, doing what you said I go to the 1st pane. I can reproduce everything perfectly now :/

[skurfer]

Interesting. Is this with just master, or do you have other stuff merged in?

[pjrobertson]

Just master! :)

[skurfer]

Not for me. This is master running from Xcode with the Debug config.

http://dl.dropbox.com/u/2214419/Quicksilver/2nd%20pane.mov

Maybe I should send you my build, or you send me yours?

[skurfer]

Total brain transplant, eh? Feels like a violation. :)

But you’re right. It stays on the first pane. Even if I run my local copy of QS with your files. So, I’ll see if I can figure out what’s different. I’ll also test with a clean account and see which behavior I get.

[pjrobertson]

Aaaargh!

My guess is there's something in the prefs... have you tried with my Calc
plugin but your prefs? Could be the calc plugin!?

Gotta love the QS :D

On 20 October 2011 21:08, Rob McBroom <
reply@reply.github.com>wrote:

Total brain transplant, eh? Feels like a violation. :)

But youre right. It stays on the first pane. Even if I run my local copy
of QS with your files. So, Ill see if I can figure out whats different.
Ill also test with a clean account and see which behavior I get.

Reply to this email directly or view it on GitHub:
#283 (comment)

[skurfer]

No, it’s not the plug-in. It’s something in the prefs. I trashed preferences and Application Support, downloaded the plug-in fresh, and I still see the problem. If I drop your prefs into place, it goes away. Same app, same plug-in.

So it’s something in there. I dropped my prefs in that folder if you want to try them out/look at them. I’ll keep playing on my end.

[pjrobertson]

I see your prefs :)

I'll do a diff on them!

Thanks for doing the initial hard work of narrowing down. I'm sure we'll get
there in the end!

On 20 October 2011 21:22, Rob McBroom <
reply@reply.github.com>wrote:

No, its not the plug-in. Its something in the prefs. I trashed
preferences and Application Support, downloaded the plug-in fresh, and I
still see the problem. If I drop your prefs into place, it goes away. Same
app, same plug-in.

So its something in there. I dropped my prefs in that folder if you want
to try them out/look at them. Ill keep playing on my end.

Reply to this email directly or view it on GitHub:
#283 (comment)

[skurfer]

I GOT IT! “Run tasks in background” fixes it somehow. So there’s a place to start.

[pjrobertson]

Did you miss my email 2 days ago?! :(

I said exactly the same thing!

I'm glad we both came to the same conclusion though!

On 21 October 2011 21:08, Rob McBroom <
reply@reply.github.com>wrote:

I GOT IT! Run tasks in background fixes it somehow. So theres a place to
start.

Reply to this email directly or view it on GitHub:
#283 (comment)

[skurfer]

Did you miss my email 2 days ago?! :(

I have a message from then, but I see no mention of this. Anyway, I think it’s around line 590 of QSInterfaceController.m. Still haven’t figured out why though.

[pjrobertson]

I didn't get that far, looking hopeful! :)

On 22 October 2011 05:20, Rob McBroom <
reply@reply.github.com>wrote:

Did you miss my email 2 days ago?! :(

I have a message from then, but I see no mention of this. Anyway, I think
its around line 590 of QSInterfaceController.m. Still havent figured out
why though.

Reply to this email directly or view it on GitHub:
#283 (comment)

[pjrobertson]

@skurfer - was this fixed a long time ago?

[skurfer]

Narrowed down considerably, but not fixed.

[skurfer]

Found it.

If you enable the “Run tasks in background” pref, [[self window] isVisible]is NO, so that line is never run. If you hit ⎋ to get out of text mode before running the action, the entire textView:doCommandBySelector: method is skipped, thus avoiding the problem.

I suppose we could just remove that line (and the one above it), but I’d kinda like to figure out why it was there first to make sure it doesn’t break anything.