rossbennett

Goodness! Really? I guess that just goes to show how good my uninterrupted uptime generally is. I've always thought it was preserved. Please go ahead and close this and we'll attribute this to User Misunderstanding. Thanks very much! Ross

Hello! This morning I noted that a new upgrade for Alfred was available to download and install. So I updated this morning. I've been working on networking cache issues, so I've had to reboot my system repeatedly today. Whenever I do, I find that my command history in the main Alfred window has been wiped or is otherwise not coming up. When I execute commands, they do accumulate in the history, so they're available to recall—until I restart Alfred or reboot. This happens whether I actually reboot or if I use the Activity Monitor to force Alfred to quit and then restart Alfred. I'm running the 12.3.1 Monterey. I'm happy to run any tests you'd like to see. Thanks! Ross

Splendid! Sounds like you're way ahead of us, per usual! :-) I'll just roll with it as it evolves. Thanks!

I almost didn't post this as a bug, because I'll leave it to Alfred's parents to decide. It's quite possible a "behavior subtlety" which has "evolved." But on the chance it was an unintended change: Build 875, Monday 25th September 2017, although this seems to have been a behavior since the new bookmark search behavior instead of something peculiar to this build. I'm still holding off on installing High Sierra until we get the all-clear with Adobe Illustrator and a few production tools. So this is in the current Sierra. For a long time I've organized browser bookmarks using full names and unique abbreviations in parentheses, e.g. National Hurricane Center (NHC) Storm Prediction Center (SPC) National Weather Service (NWS) Then I would recall such things using the abbreviation. "<Search box> NHC " or "<Search box> SPC" In earlier versions, the search would return links including the above examples. In the current version, the pattern does not return as a match unless I also type the first parenthesis. Now required: "<Search box> (NHC" or "<Search box> (SPC" I don't know that I have any objection to this, but I mention it in case it was unintended. Or perhaps the unlikely case where it has changed the way a script behaves. I certainly don't mind changing my scheme if the new behavior is preferred. :-) Thanks very much for the ongoing improvements and support of Alfred!

One more clue: IN the past 48 hours, there are some new items which have appeared in my ~/Library/Safari/ area. One is a directory called ~/Library/Safari/CloudBookmarksMigrationCoordinator/. In it is a /Logs/ subdirectory. And in MY installation, there's a file for today and a file for yesterday called "migrationEligibility_2017-07-13.log" (or -14.log). I won't post its contents, as there are a bunch of device UUIDS and such—but it appears there's a new entry for every machine restart in the form: <timestamp> Updating eligibility with 1 cloud tab devices <timestamp> Encountered non-migratable device (uuid=long string, lastModified=<timeDateUTCOffsetFormat> <timestamp> Not ready to migrate because non-migratable devices are present So…something's being moved. Just thinking: I wonder if this is prompted by the new file system update. (I've done this change on my MBP, but not on the production machine.)

My bookmarks are appearing in Spotlight results (High Sierra Beta 2), but there is no ~/Library/Caches/Metadata/ directory anymore. Just supports Andrew's hypothesis. But since my spotlight is finding them, I suspect it's safe to say that new location exists somewhere already, so I'm guessing a deliberate design choice rather than a bug.

Good morning, Andrew! Ooh! I don't think I knew about this setting. If you mean "Automatically expand snippets by keyword." (We use snippets to associate product catalog numbers with their descriptions, so we need the keyword left intact as often as expanded, e.g. "G240" is the keyword for "Gildan Ultra Cotton 6 oz. Long-Sleeve Tees") What with the old MVC danger of never-initialized things, I went in and enabled the auto-expansion, tried it, disabled the auto-expansion, and tried it again. Behavior was the same in each instance. [Currently on 3.1 build 718.] At this point I'm confident it's a problem in the handling in the Wacom drivers. They're trying to be clever with on-screen indicators of which modifier keys are pressed at any given time when the stylus or fingers are on the tablet. Their hardware has programmable keys, some of which default to Shift, Command, Option, and such. But I've individually remapped the keys in the Wacom software so none of these modifier keys are assigned to their hardware. Even when we do this, they seem to be grabbing the modifier status which I suspect is blocking your eminently reasonable release process. I've spent quite a bit of time trying different settings in the Wacom configuration and none will change the behavior. It leads me to conclude they're installing some kind of status monitor their software can subscribe to if it's needed, and that's the offending component. After all—these problems still happen when the Wacom hardware is disconnected and packed away in its dust cover.

I've been feeling guilty this past couple of weeks because I haven't yet answered Andrew's latest email about this. [We got kind of overwhelmed at work, so the testing has been pretty slow.] I've been testing the circumstances of this behavior with every keyboard-related utility I have—and that's a fair number. (I own a print shop.) The findings to date: No text replacement utilities, keyboard remapping utilities, or multilanguage/symbol keyboard input methods cause this problem. Only one thing seems to be at issue: Recent, if not only the most recent, versions of the Wacom Intuos drivers for OS X. Specifically version 6.3.17-5 and perhaps a few others which were previously released and are no longer distributed on the Wacom support site. One earlier version—6.3.17-5 is still distributed on the Wacom support site because it was the last version of the drivers to support the Intuos 3 tablets. It will also drive the latest Wacom Intuos line and it does not cause the problems described in this thread. If you rely on the latest version of the Wacom drivers, the workaround described above will still work fine, but the problem still exists in the combination of the Wacom drivers and the newest release of Alfred. (There have been two public releases of Alfred since I started testing these, and no releases so far of the Wacom driver set.)

Surely! It's on its way. (He says for thread completeness.) :-)

I began having this problem, too, when we received OS X 10.11.6 Beta 5. I had no luck finding the cause of this for a while, so I rolled back to 10.11.6 Beta 4 and the problem was resolved. But then this week, 10.11.6 final release came out and the problem returned. Rather than roll back with TimeMachine I was able to spend some time isolating it. I believe I have. The problem seems to be in the Hotkey module of the Workflows. I have a few workflows which are keyed to Command-Option-<Letter>. Whenever I'd trigger one, I would end up with a permanently-"pressed" Option key (which triggers extended characters in most Keyboard Input Methods). On closer inspection, one sees that the workflow Hotkey settings include a setting on what to do with the modifier keys that are part of the trigger. All the workflows which were corrupting the keyboard state had this setting in their Hotkey: [image disallowed] However a "simulated modifier key release" is accomplished, it seems to not be working as well for the Option key as it is for the Command key. (At least as far as the operating system is concerned.) Until the next user login, the keyboard ˙ʼ--ø˜-¥ ˘´¨ß´ƒ¨-ƒø® þ¥,ʼ˜© ´.þ´˜ð´ð ¸ˍ¯®¯¸þ´®ß. Workaround! But good news: Just go into all the problematic workflows and change the Hotkey passthrough behavior to "Pass through modifier keys (Fastest)" and everyone will live happily and functionally-ever-after. [image disallowed] I don't know when this began in Alfred, because it only began happening to me in the very latest beta and final release of El Capitan. It also only happened on my Macbook Pro Retina 2015 (internal keyboard on the USB bus) and not on the Mac Mini at the office (bluetooth-connected keyboard). It was happening with the macOS Sierra public beta 1 during the brief time I had it installed (only on the MBPr). I isolated the behavior and confirmed the workaround on Alfred 3.0.3 [694]. ps. I can't tell in the editor here whether the embedded images are going to display correctly. Just in case, here's a link to the first one, and here's a link to the second one. Hope this helps! Ross

Howdy, Folks! I think I might go along with this a smidgen, insofar as it might be splendid if workflows had the option to be triggered in a cron fashion. Perhaps if there were an alarm clock item in the "Trigger" menu of the workflow editor. For best happy action, it would be capable of setting in a recurring pattern. I suppose that does make a bit of an annoying need to create a view displaying all scheduled clock triggers in active workflows and a "show in workflow" action for each item in the list. Thanks! Ross

This is brilliant for more than one reason. I'm going to get loads of use out of this. And it looks like I'm going to get a whole new perspective on scripting, too. Thanks very much!

Good start here, but we need a couple of tweaks. I'm on 10.8.2, with updates, etc. I'm on this last August's MBP 13". The Airport is en1 on it (en0 is the hardline). I hard-coded it in mine for the time-being. I'm really new to Applescript, so I haven't worked out a good scheme to look it up reliably or I'd offer it here. The bluetooth toggle was doing fine at turning it on—but the thing about turning it off, the second "if" evaluation would always find the power off and turn it on. So if off, it was turning it on. If on, it was turning it off, then on. I replaced the two if blocks with "click A" and it's working well now.