Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
pjrobertson opened this issue May 4, 2011 · 30 comments · Fixed by #784
Closed

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

pjrobertson opened this issue May 4, 2011 · 30 comments · Fixed by #784
Assignees

Comments

@pjrobertson
Copy link
Member

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
Copy link
Member

skurfer commented May 4, 2011

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.

@ghost ghost assigned skurfer May 5, 2011
@skurfer
Copy link
Member

skurfer commented May 7, 2011

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
Copy link
Member

skurfer commented Jul 11, 2011

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
Copy link
Member

skurfer commented Jul 11, 2011

Well, that got me nowhere. Cancel excitement.

@pjrobertson
Copy link
Member Author

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
Copy link
Member

skurfer commented Jul 12, 2011

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
Copy link
Member Author

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
Copy link
Member

skurfer commented Jul 12, 2011

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

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

@pjrobertson
Copy link
Member Author

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
Copy link
Member

skurfer commented Jul 12, 2011

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
Copy link
Member Author

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

@skurfer
Copy link
Member

skurfer commented Oct 20, 2011

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
Copy link
Member Author

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
Copy link
Member

skurfer commented Oct 20, 2011

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

@pjrobertson
Copy link
Member Author

Just master! :)

@skurfer
Copy link
Member

skurfer commented Oct 20, 2011

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
Copy link
Member

skurfer commented Oct 20, 2011

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
Copy link
Member Author

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
Copy link
Member

skurfer commented Oct 20, 2011

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
Copy link
Member Author

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
Copy link
Member

skurfer commented Oct 21, 2011

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

@pjrobertson
Copy link
Member Author

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
Copy link
Member

skurfer commented Oct 22, 2011

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
Copy link
Member Author

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
Copy link
Member Author

@skurfer - was this fixed a long time ago?

@skurfer
Copy link
Member

skurfer commented Mar 29, 2012

Narrowed down considerably, but not fixed.

@skurfer
Copy link
Member

skurfer commented Mar 29, 2012

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants