A few minor fixes I picked - mainly with rename action

[pjrobertson]

• Fix the rename action to work on folders with . in them. E.g. before renaming a.folder to a (i.e. removing the apparent folder extension) would fail.
• Fix the rename action to allow changing file case (e.g. moving file A.txt to a.txt). OS X is case insensitive (so the move previously failed) but is case preserving (so we should respect the case)
• Show an error message when assigning a mnemonic doesn't actually work. E.g. assigning abc as a mnemonic to the file /hij.txt (i.e. there are no matches). Other ideas: we could ask the user if they want to set up a synonym?
• In fixing above, pass the whole object to the assign abbrev method, and get the identifier there (so that we can do more useful things with the object)

[pjrobertson]

@tiennou seems like I had a stashed fix for that QSPluginUpdater.xib warning. See 3697bc6 for a hopeful fix.

@skurfer - see fe515df for a potential fix to #1030. It does what I just suggested on the issue thread, but it'll probably need a fair bit of testing first (plus on 10.7 to make sure things still work there)

[skurfer]

Doesn’t build for me as is. There’s still a call to addAbbrevMnemonic:forID:immediately: in - [QSSearchObjectView defineMnemonicImmediately:].

It seems to fix #1030, though.

[pjrobertson]

Xcode seems to be really buggy atm. (related to Etienne seeing different numbers of warnings)... I saw that error, did a clean and then a rebuild, and it went away... I'll take another look

[pjrobertson]

Alright, so I think one of our project settings must have changed at some point to treat warnings as errors. I checked the code, and I was only getting a warning, not a build error.

Changed now.

[pjrobertson]

P.S. Keep testing the fixes for #1030 - if you can think of any other ⇧'something' (like ⇧␣) key combinations that this might break, be sure to try them out ;-)

[skurfer]

I don't know if there's a clean and easy way to do it, but I think this and line 135 below need to do what “filter results” would do instead of “filter catalog”. As it is, this prevents you from assigning a mnemonic to anything that isn't in the catalog.

[skurfer]

⇧␣ seems to work. So does ⇧⌘letter. I can’t think of any other shortcuts that use Shift. I can already see it in the release notes: “Quicksilver’s dumbest feature returns!” 😉

Offering to add a synonym is a nice idea, but not necessary in the first pass. It’s probably sufficient to just add a note to the error message, like “You might want to create a synonym instead”. Also, I think the abbreviation in the error message should be in quotes.

The changes related to renaming look good.

[pjrobertson]

Your points have been taken aboard. I'll try and figure out the not-in-catalog object business.

So as it is, hold yer horses. Hopefully in the next day I'll have a commit which fixes single/double modifier activation in password fields/secure text mode. It's working right now, just needs some testing and smoothing out :D

[pjrobertson]

OK, that problem you mentioned should be fixed. I opted to just use the object ranker to check that the single object actually matches - more efficient and fixes your problem :)

There are also a whole host of new fixes for you to enjoy... not least, the single/double tap modifier business for password fields/secure text entry in Terminal. I told you (and @tiennu) I'd get round Apple's flimsy security measures :D

[skurfer]

OK. Any idea what the merge conflict is about?

[pjrobertson]

Hmm... maybe I had an old master lying about which I'd based this off. I've done a merge and fixed the problem.

But hang on a sec... now it seems like tapping a modifier for some keyboard shortcut brings up QS, which isn't right of course
(e.g. set single modifier activation to CTRL, then use CTRL+D or whatever in Terminal)

Looking into it

[tiennou]

Heh, I found https://developer.apple.com/library/mac/technotes/tn2150/_index.html, if you go to "Discussion", there's this interesting tidbit :

Recently, a security hole was found that made it possible for an intercept process to capture keyboard events, even in cases where secure event input was enabled and the secure event input process was in the background. The fix for this problem is to stop passing keyboard events to any intercept process whenever any process has enabled secure event input, whether that process is in the foreground or background. This means that a process which enables secure event input and leaves secure event input enabled for the duration of the program, can affect all keyboard intercept processes, even when the secure event process has been moved to the background.

No security cookie for you @pjrobertson ;-).

But here's the gold nugget : Boolean IsSecureEventInputEnabled(void), 10.3+, not deprecated. I think you can use that to stop listening for modifier altogether when some process enters the secure mode.

[pjrobertson]

I know it's late in La France… but IRC?

It'd be good to break Apple's security again :P
Upon reading that I thought we could just enable secure input for the lifetime of QS (even though that's frowned upon) but that's the security hole I guess they fixed.
Not quite sure why we'd want to:

stop listening for modifier altogether when some process enters the secure mode.

?!

On 8 Medi 2013, at 07:42, Etienne Samson notifications@github.com wrote:

Heh, I found https://developer.apple.com/library/mac/technotes/tn2150/_index.html, if you go to "Discussion", there's this interesting tidbit :

Recently, a security hole was found that made it possible for an intercept process to capture keyboard events, even in cases where secure event input was enabled and the secure event input process was in the background. The fix for this problem is to stop passing keyboard events to any intercept process whenever any process has enabled secure event input, whether that process is in the foreground or background. This means that a process which enables secure event input and leaves secure event input enabled for the duration of the program, can affect all keyboard intercept processes, even when the secure event process has been moved to the background.
No security cookie for you @pjrobertson ;-).

But here's the gold nugget : Boolean IsSecureEventInputEnabled(void), 10.3+, not deprecated. I think you can use that to stop listening for modifier altogether when some process enters the secure mode.

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

[pjrobertson]

P.S.

Good find, but I want my cookie! :P

[tiennou]

Heh, I'm going to sleep. I'm working on tiennou/Letters, and I just finished a good batch of the rewrite I'm doing.

Upon reading that I thought we could just enable secure input for the lifetime of QS (even though that's frowned upon) but that's the security hole I guess they fixed.

It's not even "frowned upon" reactions you will get, people are going to come at us with forks and flammable things if we do that ;-). I mean, I expect secure input to prevent stuff like copy/pasting when someone enables it (or else it would be too easy to game, wait until a process triggers the secure mode, and perform copy action like crazy until you get their password out). If that's the case and you lock the whole secure system all the time, you can kiss goodbye to that (and TextExpander, and so much things that my mind boggles). I'll be among the first to complain vehemently ;-).

The "stop listening" part was about preventing us from triggering in case we only see a modifier (like the ⌃C thing in Terminal) but can't get to the keys because the Secure Mode is active. At least we could bring up a notification or something, instead of the interface (since that's likely unexpected). That would a least lower the reports, and we could have a page on the Wiki giving a more complete explanation. For reference, here's TextExpander one. See the list of misbehavers.

Personally, I never used activation modifiers because of that : they're too easy to trigger inadvertently, what ever you set (except maybe ⌥, but the others are out of luck). I'm fine with my ⌃˽ ;-).

[pjrobertson]

Yeah, that's perhaps the better solution - keep things as they are and just ignore modifiers in secure inputs.

FYI, I've just looked into the private NSEvent methods to see if there was a way to get the delta between events. There's a method called - (double)_eventRecordDelta:(long long)arg1;

but I can't seem to get it to work, no matter what arg1 is (I've just tried a loop from i=0 to i=999999999999 and got 0 every time!)
There's an interesting method - (struct _CGSEventRecord)_cgsEventRecord;

That struct contains soooo much information, but I can't figure it out either. So I think it's a no-go
As another aside, I'm also looking into replacing the code in +[QSModifierKeyEvents regisiterForGlobalModifiers]

with

[NSEvent addGlobalMonitorForEventsMatchingMask:NSKeyDownMask & NSFlagsChangedMask handler:^(NSEvent *theEvent) { [self checkForModifierEvent:theEvent]; }];

But that doesn't seem to work at all for me, plus it needs 'Access for assistive devices' enabled in sys prefs.

Letters looks fun and crashy. Just like Quicksilver right? ;-) Or have you got bored of QS since it's not crashy enough :P
I'll have to try it out though, looks cool :)

8 Medi 2013, at 10:55, Etienne Samson notifications@github.com wrote:

Heh, I'm going to sleep. I'm working on tiennou/Letters, and I just finished a good batch of the rewrite I'm doing.

Upon reading that I thought we could just enable secure input for the lifetime of QS (even though that's frowned upon) but that's the security hole I guess they fixed.

It's not even "frowned upon" reactions you will get, people are going to come at us with forks and flammable things if we do that ;-). I mean, I expect secure input to prevent stuff like copy/pasting when someone enables it (or else it would be too easy to game, wait until a process triggers the secure mode, and perform copy action like crazy until you get their password out). If that's the case and you lock the whole secure system all the time, you can kiss goodbye to that (and TextExpander, and so much things that my mind boggles). I'll be among the first to complain vehemently ;-).

The "stop listening" part was about preventing us from triggering in case we only see a modifier (like the ⌃C thing in Terminal) but can't get to the keys because the Secure Mode is active. At least we could bring up a notification or something, instead of the interface (since that's likely unexpected). That would a least lower the reports, and we could have a page on the Wiki giving a more complete explanation. For reference, here's TextExpander one. See the list of misbehavers.

Personally, I never used activation modifiers because of that : they're too easy to trigger inadvertently, what ever you set (except maybe ⌥, but the others are out of luck). I'm fine with my ⌃˽ ;-).

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

[pjrobertson]

In fact, addGlobalMonitorForEventsMatchingMask:handler: does work, another bit of tidying up there :)

n 8 Medi 2013, at 11:08, Patrick Robertson robertson.patrick@gmail.com wrote:

Yeah, that's perhaps the better solution - keep things as they are and just ignore modifiers in secure inputs.

FYI, I've just looked into the private NSEvent methods to see if there was a way to get the delta between events. There's a method called - (double)_eventRecordDelta:(long long)arg1;

but I can't seem to get it to work, no matter what arg1 is (I've just tried a loop from i=0 to i=999999999999 and got 0 every time!)
There's an interesting method - (struct _CGSEventRecord)_cgsEventRecord;

That struct contains soooo much information, but I can't figure it out either. So I think it's a no-go
As another aside, I'm also looking into replacing the code in +[QSModifierKeyEvents regisiterForGlobalModifiers]

with

[NSEvent addGlobalMonitorForEventsMatchingMask:NSKeyDownMask & NSFlagsChangedMask handler:^(NSEvent *theEvent) { [self checkForModifierEvent:theEvent]; }];

But that doesn't seem to work at all for me, plus it needs 'Access for assistive devices' enabled in sys prefs.

Letters looks fun and crashy. Just like Quicksilver right? ;-) Or have you got bored of QS since it's not crashy enough :P
I'll have to try it out though, looks cool :)

8 Medi 2013, at 10:55, Etienne Samson notifications@github.com wrote:

Heh, I'm going to sleep. I'm working on tiennou/Letters, and I just finished a good batch of the rewrite I'm doing.

Upon reading that I thought we could just enable secure input for the lifetime of QS (even though that's frowned upon) but that's the security hole I guess they fixed.

It's not even "frowned upon" reactions you will get, people are going to come at us with forks and flammable things if we do that ;-). I mean, I expect secure input to prevent stuff like copy/pasting when someone enables it (or else it would be too easy to game, wait until a process triggers the secure mode, and perform copy action like crazy until you get their password out). If that's the case and you lock the whole secure system all the time, you can kiss goodbye to that (and TextExpander, and so much things that my mind boggles). I'll be among the first to complain vehemently ;-).

The "stop listening" part was about preventing us from triggering in case we only see a modifier (like the ⌃C thing in Terminal) but can't get to the keys because the Secure Mode is active. At least we could bring up a notification or something, instead of the interface (since that's likely unexpected). That would a least lower the reports, and we could have a page on the Wiki giving a more complete explanation. For reference, here's TextExpander one. See the list of misbehavers.

Personally, I never used activation modifiers because of that : they're too easy to trigger inadvertently, what ever you set (except maybe ⌥, but the others are out of luck). I'm fine with my ⌃˽ ;-).

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

[pjrobertson]

Lots of progress here this morning. I've fixed another merge conflict (with the minVersion branch) and fixed the modifier only activation to work super properly :)

Take a look everyone

[tiennou]

No newline at end of file, says GitHub ;-)

[pjrobertson]

Bonjour :)

Is that the best you can come up with? :P
Hehehe. On IRC if need be

And if you really want it, I can add it in :)

On 8 Medi 2013, at 17:04, Etienne Samson notifications@github.com wrote:

In Quicksilver/Code-QuickStepCore/QSMacros.h:

@@ -18,3 +18,11 @@
#define QSLog(s, ...)
[MLog logFile:FILE lineNumber:LINE
format:(s), ##VA_ARGS]
+
+#define SuppressPerformSelectorLeakWarning(Code)
+do {
+_Pragma("clang diagnostic push")
+_Pragma("clang diagnostic ignored "-Warc-performSelector-leaks"")
+Code;
+_Pragma("clang diagnostic pop")
+} while (0)
No newline at end of file, says GitHub ;-)

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

[skurfer]

Heh, I'm going to sleep. I'm working on tiennou/Letters, and I just finished a good batch of the rewrite I'm doing.

Nice! I always wanted to see Letters go somewhere.

[tiennou]

Somewhere might be a little too far though ;-). I'm trying to test what I did this weekend, and I get back "A stable connection to the server could not be established" errors. Either MailCore sees that I'm on an iPhone, or it sees that I'm doing debug-level things ;-).

[skurfer]

I've got a server running Dovecot and Postfix. Those are probably closer to a standard implementation than a lot of the big online services. Plus, I can see error logs on the server side, which was pretty helpful when adding MailCore to the E-mail Support plug-in. Contact me privately if you want a test account.

[skurfer]

Is this good to go? Renaming and abbreviation stuff seems fine.

I can use ⌘⌘ in Terminal now. What else needs checking? Should I maybe change that to a single modifier and run it for a while to make sure there aren't any weird side effects?

[skurfer]

Why call this if the result isn't captured/used at all? Does it update something internal to QSLib?

[pjrobertson]

Fixed now

[pjrobertson]

Yes, I've done lots of testing, but single modifier and caps lock modifier are the two to play with.

Also checking the capitalised keys change action business. Otherwise, it's good. I discussed the screwy indentation with Etienne on IRC, Xcode's fault, so ignore it!

On 11 Medi 2013, at 05:10, Rob McBroom notifications@github.com wrote:

Is this good to go? Renaming and abbreviation stuff seems fine.

I can use ⌘⌘ in Terminal now. What else needs checking? Should I maybe change that to a single modifier and run it for a while to make sure there aren't any weird side effects?

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

[pjrobertson]

Oh, and check it when you have triggers that use CTRL+key hotkeys, as well as stuff like on release, after delay… settings :)

On 11 Medi 2013, at 07:40, Patrick Robertson robertson.patrick@gmail.com wrote:

Yes, I've done lots of testing, but single modifier and caps lock modifier are the two to play with.

Also checking the capitalised keys change action business. Otherwise, it's good. I discussed the screwy indentation with Etienne on IRC, Xcode's fault, so ignore it!

On 11 Medi 2013, at 05:10, Rob McBroom notifications@github.com wrote:

Is this good to go? Renaming and abbreviation stuff seems fine.

I can use ⌘⌘ in Terminal now. What else needs checking? Should I maybe change that to a single modifier and run it for a while to make sure there aren't any weird side effects?

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

[skurfer]

Small bug. When I change between ⌥ and ⌘ (single or double), it still recognizes the other until a restart. Not sure if it also affects others but definitely those two.

[pjrobertson]

Good spot. Looking at the code, this seems it was always a bug... funny nobody ever came across it.

The fix is simple(ish) - to observe the old value of the modifier key before the change, disable that hotkey, then observe the new value after the change event and enable that hotkey.

...however, the bindings thing doesn't seem to be working. Setting NSKeyValueObservingOptionPrior in QSMainPreferencePanes.m:L65 doesn't mean the observeValueForKeyPath:ofObject:change:context method (in the same file) is called twice: before and after the change. So the cleanest solution doesn't seem to work :/

[pjrobertson]

Thanks Apple, useless. A bug that's going to be fixed 'soon' after 2009 right?

http://www.cocoabuilder.com/archive/cocoa/242764-observevalueforkeypath-returns-null-in-the-change-directory.html

[pjrobertson]

(P.S. Sorry, I had to force push. If you want to test (it's probably worth it since there were lots of conflicts) then you'll need to force pull)

[skurfer]

I was just about to say the conflict wasn't a big deal, but OK. I'll pull again. :-)

[skurfer]

Are you sure you picked the right commit for VDKQueue? I think master got a new one when #1598 was merged, but if I check this out, it wants to change it again. (I assume it's trying to go back to what it was before #1598, but for all I know, that's the correct one.)

[pjrobertson]

VDK Queue was funny for me. I tried a git submodule sync and git submodule update but it still didn't work. I probably got it wrong :(

On 20 Sep 2013, at 00:30, Rob McBroom notifications@github.com wrote:

Are you sure you picked the right commit for VDKQueue? I think master got a new one when #1598 was merged, but if I check this out, it wants to change it again. (I assume it's trying to go back to what it was before #1598, but for all I know, that's the correct one.)

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

[skurfer]

I think that's all that's holding this up. Can you confirm which commit we should be pointing to, @tiennou?

[pjrobertson]

Yeah, sorry. Me and submodules don't go nicely together.

If you could let me know what I need to do to update, I'll go ahead and make the changes. Lots of tasty things (minor - hehe) things in this pull ;-)

On 28 Sep 2013, at 04:36, Rob McBroom notifications@github.com wrote:

I think that's all that's holding this up. Can you confirm which commit we should be pointing to, @tiennou?

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

[pjrobertson]

Oh, and one more thing - has anybody tested the #1030 bug on 10.7? If not I think I have a copy of the Lion install still lying around so may be able to install it .

And I've just fixed the VDKQueue thing. I cd'ed to the submodule folder and did a git pull. I'm not sure why a git submodule update didn't work...

[pjrobertson]

FYI I have no 10.7 install lying around so if anybody else has a running 10.7 that'd be handy

[skurfer]

I’ve got VMWare Fusion. I should be able to install 10.7 there. Downloading it from the App Store now. I’ll let you know what happens.

[pjrobertson]

Cool, I appreciate it. I could have gone through the trouble myself - so thanks for saving me the hassle (except now you make me feel bad!)

[skurfer]

At 4.72 GB, I don't know that you could have. It's already done downloading for me. :-)

[pjrobertson]

What you saying about Korean internet? ;-)

Although I only have 50GB of my SSD left :(
I need some cleaning up…

On 30 Sep 2013, at 23:45, Rob McBroom notifications@github.com wrote:

At 4.72 GB, I don't know that you could have. It's already done downloading for me. :-)

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

[skurfer]

Difficult to test since the prefs window just spins without showing anything. I'll look into it some more after lunch.

[skurfer]

OK, installed 1.1.0, which allowed me to enable the right preferences, then tested the ⇧ key behavior and it still appears to work correctly with these changes. I should probably open a separate issue on the prefs hanging.

[skurfer]

This’ll be change log hell. Lots of good treats in here, though. :-)

[pjrobertson]

Merged #1586.

Wahey!

This’ll be change log hell. Lots of good treats in here, though. :-)

Yeah, apologies. Lots to discuss though :)

I guess it's kind of a good thing we found a 10.7 bug :)

On 1 Oct 2013, at 03:14, Rob McBroom notifications@github.com wrote:

This’ll be change log hell. Lots of good treats in here, though. :-)

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

[philostein]

4008: 'Assign Abbreviation…' works for me for the first time since… ß54? Thanks!