Hmm, so if I followed the code correctly, no application activation/deactivation occurs, all that happens is that the Quicksilver window does an orderOut: . Heh, I didn't even realize you could "lose" your application's focus just by doing that.
What is really interesting is that after executing the Paste QS command while TextExpander's fill-in window has the text focus, the Paste goes to the menu-bar-owning application (the complaint), but text focus returns to the fill-in window. I think this may be a lost cause, though, because if I examine the Command-V event that Quicksilver generates like this: CGEventGetIntegerValueField(event, kCGEventTargetUnixProcessID) it tells me the window server has already targeted the event at the menu-bar-owning application :-( The only way I can think to solve it would be for Quicksilver to orderOut the window and return to the main event loop, then generate the Command-V after text focus has been sorted out. I can't think of anything that has a non-activating text focus window quite like TextExpander's fill-in window other than the Omni Focus window I mentioned. But you can demo TextExpander for free :-) Cheers, Brian On Wednesday, January 15, 2014 5:49:35 PM UTC-8, Patrick wrote: > > Good to have you here Brian :) > > The actual code that’s pasting from the clipboard is in the clipboard > plugin, see > https://github.com/quicksilver/elements.clipboard-qsplugin/blob/master/QSPasteboardController.m#L216 > The QSPasteboardStoreMode is the case that’s being used (although this is > pretty irrelevant). Basically we’re just copying the text/object to the > clipboard, then sending a CMD+V straight away. No sending to specific apps. > > Now what you’re saying about TextExpander being a Non Activating panel > raises some concerns. The QSDockingWindow (of which the clipboard window is > one) behaves similarly (with a few more confusions). > See: > > https://github.com/quicksilver/Quicksilver/blob/master/Quicksilver/Code-QuickStepInterface/QSDockingWindow.m#L135 > > As you probably know, non activating panels are really fiddly - I think > it’s taken us about 3 years of tweaking to get the QSDockingWindow to > actually work (just about!) > My guess is that when the clipboard is brought up, TextExpander is losing > its key window status and the Clipboard is getting it. This may well be > what’s causing the problem. The only option I can think of is to change the > option in the Clipboard preferences from “Hide after pasting” to “Hide > before pasting”, but I don’t think the OS will switch the key window status > back to TextExpander. > > Unfortunately I’ve never used TextExpander (or OmniFocus) - any > suggestions for other cases which may well be similar and so I could try > and reproduce? > > Thanks > > On 16 Ion 2014, at 07:08, Brian Bucknam <[email protected] <javascript:>> > wrote: > > Hi Patrick, > > Actually, my old theory is invalidated by the code there. My theory was > that Quicksilver was using CGEventPostToPSN, and getting > the wrong process. > Instead, Quicksilver is just using CGEventPost, so if TextExpander Helper > (which is presenting the fill-in window) still had the text focus, the > Paste should occur there. > > So my new theory is that just before generating the Command-V > event(s), Quicksilver must be re-activating what it thought was the > "current"/active application. It activates the app which holds the menu > bar, which is not TextExpander Helper. > > TextExpander Helper's fill-in window is a "Non Activating" Utility Panel. > When presented, it gets an orderFront: and then a makeKeyWindow call, > but TextExpander Helper never becomes the "active" app. (A lot > like Quicksilver in its normal usage!) > > I did grab the Quicksilver code, but I can't follow how/where > the QSForcePaste gets triggered to be able to confirm my new theory. > > TextExpander Helper does broadcast some distributed notifications when it > presents and removes the fill-in window, but that's not a very "pretty" > solution. > I'd be interested to know if the same issue occurs when using Quicksilver > in conjunction with, for instance, the OmniFocus "Quick Entry Window" > (which behaves similarly to TE's fill-in window). > > Cheers, > Brian > > On Wednesday, January 15, 2014 4:12:29 AM UTC-8, Patrick wrote: >> >> A quick update… I have looked into the ‘old’ way we used to do it and >> that is actually no longer possible* since the methods are deprecated >> I’d be interested to know if Brian has any boilerplate code for option A >> and option B. I can’t see (from a quick glance) how to use option A now (if >> you’re relaying this to him, it’s the `CGPostKeyboardEvent()` method >> that is deprecated) >> >> Cheers >> >> * OK, it’s still possible but they’re deprecated methods >> >> >> On 15 Ion 2014, at 20:08, Patrick Robertson <[email protected]> >> wrote: >> >> Thanks very much for the long explanation (and especially the info from >> Brian), that’s really useful and interesting. >> >> Just to fill in the details from our side of things: >> >> We used to use option B as Brian mentions (i.e. we used to just tell the >> keyboard directly to press CMD+V). Now, for some reason that wasn’t working >> with Gmail email fields (that is, when I tried to paste something from QS >> into a Gmail compose field using the ‘paste’ action, it didn’t work) >> So, instead I switched to option A. >> I guess this further proves Brian’s point about each option having their >> pros and cons. >> Unfortunately I don’t use TextExpander, so I’ve never come across the >> cons of option A (as you obviously have) so have never investigated >> further. Having said that, I’ll take a look again at whether or not Option >> B is still a problem with Gmail, if not we *could* theoretically switch >> back. >> >> For reference, the commit where I made the change (it may be of interest >> to Brian) is: >> >> https://github.com/quicksilver/Quicksilver/commit/0d8d178699865395444c5dca9076d7d29fb59e12 >> >> I hope this helps, and will update you when I’ve looked again at option >> A/B with Gmail >> >> On 14 Ion 2014, at 05:18, [email protected] wrote: >> >> Actually, I have been using the command window (the second screenshot), >> not the floating clipboard history palette. I set up my QS configuration >> quite some time ago now, but do dimly remember making a trigger in QS's >> preferences to run Clipboard History > Show Contents, which is be the way I >> have used to get it. >> >> I've thought about it and am sure I haven't been keeping the trigger keys >> held down. >> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/blacktree-quicksilver. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> > -- > 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 [email protected] <javascript:>. > To post to this group, send email to > [email protected]<javascript:> > . > Visit this group at http://groups.google.com/group/blacktree-quicksilver. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/blacktree-quicksilver. For more options, visit https://groups.google.com/groups/opt_out.
