troycurtisjr

I'm not on Monterey yet, so I can't troubleshoot what is going on. Unfortunately MacOS doesn't give us a great interface to this functionality, so everything is a little bit hacky. And since this doesn't use an official interface, it changes randomly on upgrades!

If anyone is able to dig in to figure out what needs to happen on Monterey, I can definitely add to the code. Otherwise, I'll give it a try once I upgrade which will probably be a bit. Maybe over Thanksgiving since my only Mac is my work laptop and I can't risk killing my environment for a few days 😉.

Thanks for catching that and testing! I've updated to 0.1.4 https://gitlab.com/troycurtisjr/do-not-disturb-limited/-/jobs/artifacts/v0.1.4/raw/do_not_disturb_limited_v0.1.4.alfredworkflow?job=package with the typo fix.

I've incorporated @paulw snippet to hopefully support Big Sur and previous releases. I can only test on Catalina currently, so if anyone on Big Sur would try out v0.1.3 I would really appreciate it! Let me know how it works out.

@paulw While it might work to make mods to that plist file to do the enable/disable, I assume it'd be roughly equivalent to modifying the similar plist file in Catalina and before. That means we'd need to kill the Notification Center process to force a re-read of the preference. However, the indicator would be out of sync, which is why I opted for the keyboard shortcut method, even though that requires more manual setup.

That's a great find @paulw
 

I think I am getting close to doing the update to big sur, probably not this weekend, maybe the next. 😉

I'll incorporate soon!

On second thought that doesn't really work. After the delay, I need to know what the current state is so that it doesn't get toggled if for some reason it was manually changed before the timeout expires. There has got to be some what to get it in Big Sur but it is going to take some investigation. If you want a quick hack, which will always toggle the state, then you can open the workflow, then open the "External Script" labeled `dndenabled` and replace the contents of the file with this:

#!/bin/bash

if [ "$desiredState" = "enabled" ]
then
  echo -n "disabled"
else
  echo -n "enabled"
fi

Ah rats! Ok I think I'll still change to that but unfortunately it means it won't know when dnd is currently enabled, but it should at least be able to actually enable it and auto disable later. I'll post here when I have an update available.

🎉 That's a great sign! Ok one more test, manually enable do not disturb (Option-Click the notification area is the easiest way IMO), and then run the command again. We are hoping that it returns `1` this time!

I'm still not on Big Sur and there doesn't appear to be a lot of specifics about this yet, so I'll need to ask you guys to try some things out that I might normally try on my own system.  It looks like I may have over specified the command to get the current status. Can you run this command in a terminal to see if it works?

defaults -currentHost read com.apple.notificationcenterui doNotDisturb

And I'll keep looking for other hints.

I'm glad to hear it has been working well previously! I'm not on Big Sur quite yet, so I haven't needed to work through any issues with it. Our IT has recommended holding off upgrading until they finish testing. I'll likely pick a weekend to do it as soon as they give the green light. If in the meantime anyone figures out what is happening, please post here so we can help each other out.

A few general thoughts to check. Did the keyboard shortcut get reset/cleared by chance? Perhaps the action is named something else in BigSur and needs to be set to something else?

To help with debugging, you can also open the Alfred preferences, go to the workflows panel, and select the Do Not Disturb workflow. Then you can click the little bug at the top left to enable debug mode. You should see a little window pop at the bottom.  Then try activating the workflow 

dnd 5

You should be able to see several bits of output spitting out. Take a look to see if there is any obvious error messages. I've attached an example screenshot (from Catalina though ) 

I just confirmed using TextEdit and Finder. I put Finder on the primary screen (the one with dock and menubar), and TextEdit on a secondary screen. I clicked on TextEdit, and confirmed it had focus (typing resulted in text entered into the document). Then I activated summoned Alfred and it opened on the primary screen.

Perhaps it is related to the fact that I have the "Displays have separate Spaces" disabled? I believe the default is that they do have separate spaces.  I know that I would also like a menu bar on all desktops, but I can't have both the menu bar everywhere and a shared space between the displays. So perhaps there is a similar issue with Alfred being able to detect the current active screen?

Hopefully this thread isn't so old as to be "Necro-posting", but I thought the context was useful and it isn't like you need yet another identical thread title!

I really want Alfred to open on the active screen, but the setting has never had an effect for me.  If I chose the "mouse screen" it works as expected, but I use keyboard navigation a lot so frequently the mouse is not in the screen I'm actually using. For me this has been persistent since my first use of Alfred more than 1.5 years ago.  So that is through Mojave and now Catalina.  I finally went looking for a solution, and have been surprised at all the people here talking about it working as expected. 

Are there any clues on what I could do in order to get it working as expected?

Alfred 4.0.8

macOS 10.15.2

On 5/14/2019 at 6:11 AM, deanishe said:

On 5/13/2019 at 10:10 PM, troycurtisjr said:

So using the async queues really cleaned up the code, and each function can effectively be written as a standard linear function, which makes it quite easy to follow IMO.

 

I don't really follow you here. There isn't any concurrency in the script, is there? So what's the difference to regular synchronous code?

You are right there there is not much concurrency here. None of the I/O I'm doing (or currently expect to do) with the websocket would be expected to take very long. However, there is potentially some overlapping I/O going on here. The way the GPMDP websocket API works is that there is a near constant stream of data (presuming a track is actively playing, basically it is the "current time" message), and arbitrarily interleaved in that stream is the response or responses to calls that you might make. The overlapping I/O happening *could* be during the async send and the ongoing async receives going on. Again, I'm not claiming in this simple use case there is a huge gain. After all if I was writing this in sync code, I would just have a common read function that would read messages and discard the ones I wasn't currently interested in, waiting for the desired response before returning it. I am also planning on making use a few of the automatic messages sent over, namely the playlists. So those can be read and queued off until I care about them, and interacting with them would be the same whether they were already present when I go to look for them, or whether I needed to "await" a bit for them to come in.

Lastly, I'm planning on pulling down the various bits of album art into a local cache to use as the icon, and that would be nice to run "concurrently". Now I'm all set to just add those pieces in! But first, I'm getting the basics all working so I can control more of my computer using Alfred!

So I kinda figured it out, though it doesn't really make a lot of sense to me. Perhaps you can understand what is going on better.

While recreating the issue in a simpler workflow to share with you I stumbled on what finally made it work: supplying a value for "arg". This seems odd since the documentation says it is an optional parameter, and in my DND workflow it doesn't have an "arg" and works OK.

Here is a minimal workflow that duplicates the issue for me: https://drive.google.com/open?id=1HFlPoMTTU4X83I2T0fVuq2TUUvqc8H2G

It behaves the same way in that it does not respond to selecting the only filter option. If the second echo in the script filter is uncommented and the first is commented out, then it works as expected. By adding an "arg" value, I was able to successfully get my GPMDP to work which is great! But I'd like to better understand why.

As for the async usage the reason is two fold:

1. The websockets library I ran across first for Python (https://websockets.readthedocs.io/en/stable/) uses the coroutine support as it is built on top of the standard asyncio library.

2. I wanted to learn something a bit new 😉

I've spent most of my development career writing event driven code, which I like, but I've never had an opportunity to do it with real language support for coroutines. You get something similar with javascript, but it seems a bit different. I have found I quite like it as opposed to decomposing my processing into discreet processing blocks with a means to save state in between. This also works really well for the GPMDP API in particular, as there is a LOT coming across the wire that my script doesn't care about, but I need to pick out the pieces I do need (from the right "namespace"). So using the async queues really cleaned up the code, and each function can effectively be written as a standard linear function, which makes it quite easy to follow IMO.

Thanks for the nudge to simplify down to the basics, I should have used the basic troubleshooting technique from the beginning! 😛

I'm having trouble getting the output of my "Script Filter" to execute. I've successfully used this before, but I am out of ideas about what is going on with this one.

My "Script Filter" runs successfully, and in this case it gets the results of a search performed by GPMDP. I go down to the desired selection, hit enter and nothing happens. Alfred and my search list stay displayed, and nothing indicates I have done anything, except that occasionally when I choose something down the list a bit, Alfred will move that selection to the top. I've run the command with the debug on, and there doesn't appear to be any output from the "Script Filter". Everything seems right with my json output, and I've stripped it way down trying to figure out the issue. This is the current output:

Quote

[2019-05-12 18:16:27][input.scriptfilter] {"items": [{"title": "Meshuggah", "valid": true}]}

I've tried a few simple outputs (besides my desired "Run Script" output), but nothing changes. Using the keyword trigger in the same workflow operates correctly.

I'm hoping you guys have ran into similar scenarios, my searches didn't turn up anything.

I've pushed up my in-progress code https://gitlab.com/troycurtisjr/alfred-control-gpmdp.

I was afraid of this. I've been playing around with another workflow for interacting with the Google Play Music Desktop Player, and I'm using Python 3 because the websocket library I picked up uses the coroutine support in Py3, which is really nice to have. I was really wondering about how such a workflow could be reasonably distributed, and it seems as painful as I assumed it might be.

Oh well, maybe I'll get lucky and by the time I get it to something presentable, Py3 will be available natively 😬

That is a great tip Vitor! I'm still pretty new to macOS but I'm gathering `defaults` is where a lot of the action is.

For workflows with setup, would that typically be another subcomand ("dnd init"), or some kind of dialog on the first run?

My first (exported) workflow:

Do Not Disturb, Limited - Toggle the macOS Do Not Disturb feature, optionally for a specified length of time.

I was really inspired by CalmNotifications but I always forgot to toggle it back. Plus, I really wanted the indicator to reflect the current status, which didn't happen when the "set a plist value and kill NotificationCenter" method is used.

Releases | Source