Is there a URI scheme to open Alfred's Debugger?

[luckman212]

I was wondering if there was a URI scheme e.g. alfredpreferences://openDebugger that could be called from within a running workflow to open the debugger, for example to alert the user about some error that has occurred.

If there isn't such a thing, please consider this a feature request!

Edited September 22, 2023 by luckman212

[vitor]

The debugger is within the Alfred Preferences. To do that it would mean that on an error, the Preferences would suddenly open on the user’s screen with a small message on the bottom, which would be majorly confusing for a large swathe of users. It wouldn’t even work because by the time you opened the debugger, the error would have already happened. To do what you’re thinking, it would mean the debugger would have to be logging all the time.

 

If you want to show an error message to the user, there are more efficient and friendly ways. You can show a notification and/or play a sound or show a dialog which can even provide the user with options on what to do next, including e.g. one to gather information for them to provide to you to help you debug. The debugger output is for you, not to message users.

[luckman212]

Ok, I see your points. I'll rethink the best way to do this. I wanted a form of output that allows the user to copy a bit of text for pasting into a Terminal.

 

Plus I spent so much time making this silly thing 😊

 

 

I guess I could use the "Terminal Command" workflow object to open a new Terminal and display some text there.

Edited September 23, 2023 by luckman212

[vitor]

42 minutes ago, luckman212 said:

Plus I spent so much time making this silly thing 😊

 

Made me laugh!

 

49 minutes ago, luckman212 said:

I guess I could use the "Terminal Command" workflow object to open a new Terminal and display some text there.

 

You could also use Large Type or save that to a text file and present it with QuickLook (there’s an Automation Task for that).

But the Dialog Conditional still makes a lot of sense: it could explain the problem, then have one button that would open the terminal and another to cancel.

An even better approach would be to just bundle the library in the workflow by using pip with the --target option and setting PYTHONPATH. It should be done with /usr/bin/python3 so packages are built with the system python. But in this case I guess pyobjc may contain some unsigned binaries which will make that unfeasible?

 

By the way, I know you know about those objects and that I don’t really need to link you, but I’m also thinking of the people that’ll land on this thread later.

[luckman212]

Thanks again @vitor 

 

I struggled for a while with how to bundle the pyobjc dependency along with the workflow, e.g. in a ./lib directory. But, it seems that it's bound tightly to the exact Python version installed. Which could be 3.9, 3.10, 3.11... I gave up and just replaced the whole thing with a small Swift program to read the data I needed from the OS Pasteboard. This is probably faster too, and so no longer requires pyobjc at all 🎉

 

https://github.com/luckman212/alfred-get-deeplink-to-object

 

https://www.alfredforum.com/topic/18390-get-currently-edited-workflow-uri/?do=findComment&comment=108605

 

 

[vitor]

31 minutes ago, luckman212 said:

But, it seems that it's bound tightly to the exact Python version installed.

 

More specifically, it should be tied to the Python’s path. It just so happens that Homebrew’s python installations have the versions in the directories, which is why installing with /usr/bin/python3 is preferable.

 

46 minutes ago, luckman212 said:

replaced the whole thing with a small Swift program

 

Great! Though because it’s compiled but not signed, it won’t run on users machines without them allowing it. One thing you can do is instead put the code in a Run Script with /usr/bin/swift as the language which will compile and run it every time.

[luckman212]

Oh shoot. Well that sounds a lot slower. I have an active Developer ID so I can sign the binary and upload a new version. Will do that now...

 

Also, I think I tried installing using the Xcode Python3.9 that gets installed at /usr/bin/python3, something like

 

/usr/bin/python3 -m pip install --isolated --target=./lib pyobjc

 

but I seem to remember that failing too for some reason. I expect it's due to https://xkcd.com/1987/

 

So I will try to make the Swift method smoother.

Edited September 23, 2023 by luckman212

[vitor]

You’ll need to notarise it too. If you’ve never done so for a binary, I explained the process in another thread.

[luckman212]

That was indeed super helpful @vitor

 

I think I've done it. But if you wouldn't mind terribly, I'd appreciate if you could test v0.0.4 which should be codesigned + notarised.

 

https://github.com/luckman212/alfred-get-deeplink-to-object/releases/tag/0.0.4

 

[vitor]

Looks good. Another tip: /usr/sbin/spctl -vv --assess --type install /PATH/TO/BINARY will confirm that it worked. You’ll either see rejected or accepted and your information. If you get the latter, you’re good.

 

If you want to script that you don’t even need the -vv, it’ll give an exit code of 0 if it’s good and non-zero if not.