Workflow Library for Python

[xilopaint]

Oh, I just didn't realize that I can't search into Workflow3 directly:

 

[xilopaint]

19 minutes ago, deanishe said:

There are two add_item() methods. Workflow.add_item() and Workflow3.add_item().

 

You're looking at the wrong one.

 

 

Would it be possible to make the search match both results when searching for add_item?

[deanishe]

Dash's behaviour when two methods have the same name is to show (2) next to the method name in its search results.

 

It's up to you to make sure you're looking at the right one.

 

You'll have to ask @bogdansrc if you want that changed.

 

[xilopaint]

5 minutes ago, deanishe said:

Dash's behaviour when two methods have the same name is to show (2) next to the method name in its search results.

 

It's up to you to make sure you're looking at the right one.

 

You'll have to ask @bogdansrc if you want that changed.

 

 

Now I see the workflow displays "api and 1 other" in the subtitle:

 

 

Would it possible to achieve this on the workflow side with some improvement? Maybe with a tab press in the item all the methods matching the search term could be displayed.

[deanishe]

On 19/09/2017 at 2:01 AM, xilopaint said:

Would it possible to achieve this on the workflow side with some improvement?

 

That's a question you should probably ask in the Dash thread.

[xilopaint]

Hey @deanishe. I am building a workflow for my personal use in which I will need to store strings (dozens of phone numbers and a few places) for later use. Considering the simplicity of the data it would be better achieved with Workflow.settings or I should use Workflow.store_data()?

As for Workflow.store_data(), is it possible to add new data in the same cpickle file? I have read in the docs that "datastore does NOT support mutliple threads", so it means the answer is no?

If it's not possible maybe I should use Settings API in order to avoid having a bunch of files in the data folder, right?

Edited October 6, 2017 by xilopaint

[deanishe]

Are dozens of phone numbers settings? If not, then don't use the settings API.

 

2 hours ago, xilopaint said:

is it possible to add new data in the same cpickle file?

 

What do you mean?

 

2 hours ago, xilopaint said:

avoid having a bunch of files in the data folder

 

Why would you write a "bunch of files"?

[xilopaint]

2 hours ago, deanishe said:

What do you mean?

 

Is there any way/method to append data to a datastore without having to retrieve the data with Workflow.stored_data() before?

Edited October 6, 2017 by xilopaint

[deanishe]

No.

 

Why is that even as issue? You said it was a matter of dozens of phone numbers, not megabytes of data.

 

[xilopaint]

It's not an issue. I was just trying to figure out if there was a cleaner way of appending data to a datastore than the one I was thinking about. Alfred-Workflow is such an awesome library that in many occasions I try to implement something in a way until I realise that there is an even simpler method of achieving my goal.

 

Sorry for bugging you with dumb questions. My English is too bad and my coding skills are even worse.

[deanishe]

Sorry. I was having a bad day yesterday.

 

If it’s only a dumb list of numbers, you can write them to a text file.

 

Then you can just write another line on the end.

 

But if you save the numbers as a set via the data API, then you don’t have to worry about duplicates.

 

When you do have so many data it’s not feasible to load them all every time, you likely want to use SQLite.

 

Edited October 7, 2017 by deanishe

[xilopaint]

No problem, you were not rude at all. Sometimes I just don't manage to make the question right because I don't understand entirely what my problem is.

At the end it was a bit more complicated than a simple list, so I created a workflow that generates a dict by user input and the data is stored in a single file using Workflow.store_data().

 

It was helpful to improve my knowledge on dict.

Edited June 29, 2019 by xilopaint

[deanishe]

Added the ability to save settings to info.plist via Alfred's new API in v1.33.

 

[deanishe]

Forgot to mention that Alfred 4 support was added in v1.37.

 

No new features as such, but the .alfred4workflow extension can now be used in releases to hide updates from Alfred 3 and earlier. APIs like Workflow.setvar() that talk to Alfred via AppleScript automatically use the appropriate mechanism for the version of Alfred they're running in.

[xilopaint]

16 minutes ago, deanishe said:

No new features as such, but the .alfred4workflow extension can now be used in releases to hide updates from Alfred 3 and earlier.

 

How does it work exactly? Should I rename the workflow file for .alfred4workflow so Alfred 2/3 users will not get updates for v4?

[deanishe]

Yes. It worked that way for Alfred 3, too.

 

It’s all in the docs.

[xilopaint]

2 minutes ago, deanishe said:

Yes. It worked that way for Alfred 3, too.

 

It’s all in the docs.

 

Now I'm curious to know if OneUpdater has also this feature.

[deanishe]

29 minutes ago, xilopaint said:

 

Now I'm curious to know if OneUpdater has also this feature.

 

You can prevent incompatible versions of the workflow from being installed with OneUpdater, yes. It doesn't care about file extensions, though, because it doesn't work the same way.

 

Using different file extensions is not an official or recommended way to specify compatibility: it's a hack we came up with specifically for GitHub releases. Alfred only supports the extensions because we were going to use them regardless, and Andrew wanted to prevent the problems that would cause.

[xilopaint]

2 minutes ago, deanishe said:

 

You can prevent incompatible versions of the workflow from being installed with OneUpdater, yes.

 

How?

[deanishe]

I don't know. I mean, I can think of a few ways you could do it, but you'll have to ask @vitor how it is actually going to work.

[vitor]

Presumably Alfred 3 will not try to open Workflows with the v4 extension, so the easiest way to do it would be to release the new versions with that extension. It would still download them, which is mildly bothersome, but otherwise it should be fine.

Also presumably when making a v4 of a Workflow, one stops releasing v3s of that same Workflow, so having the user delete the OneUpdater node also works. I mean, one of the selling points of OneUpdater is that you can rid of it easily! I like that as a signifier: the user will know there are new versions released that are incompatible with their Alfred version and can make an informed decision (“am I losing updates to my favourite Workflows by not upgrading Alfred?”). If they decide to not upgrade Alfred, deleting the update mechanism of a Workflow is a demonstration of intent.

I may still add a check in OneUpdater itself; haven’t decided. Initially I forgot, but now I’m not really seeing any major repercussions of not having done so, so I’m not sure it’s worth the effort.

[elsatch]

First of all, thanks for creating this plugin for Alfred!

 

I have followed the tutorials to create an extension to access my Youtube video data. Usually I need to retrieve title or description to reuse it somewhere else. I was planning to share it with in Packal so other people can use it too. I created this description of how it works:

 

Youtube Video Search

This workflow retreives details about your latest videos from Youtube. 

To set it up, you need to configure your Youtube ChannelID and API Key. To do so execute the following commands:
    - ytsetkey: Without parameters, it will take you to the Youtube API page to get your API key. If you supply your API Key as a parameter, it will be stored in your Keychain (and synced among devices).
    - ytsetchannel: Without parameters, it will take you to Youtube Advance Setting page to retrieve your channel ID. If you pass the channel ID as a parameter, it will be stored in the workflow settings. 

It has the following keywords defined:
    - ys (Youtube Search): retrieves the latest 50 posts from your Youtube account. When you press enter on the results, the video ID will be copied to your clipboard.
    - yo (Youtube Open): takes a video ID as a parameter and opens the Youtube video website for that video.
    - yd (Youtube Details): takes a video ID as a parameter and lists the video details. Pressing enter will copy the result to the clipboard.

If you ever need to reset this workflow parameters, you can do so using the Magic argument: ys workflow:delsettings.

Bugs: VideoIDs starting with hypens, breaks the yd call.

---------

So far everything is working but the Youtube Details keyword. It works if:

a) Running from the console and passing the parameter, returns correct results. 

b) Disabling cache in the code and passing static parameter, returns correct results.

 

If I try to make it run, it shows the correct message and reverts to default search in a second.

 

I have tried the debug option in Alfred and my hypothesis is:

a) Alfred evaluates yd as I finish typing d (after y)

b) It evaluates query as empty and passes that as a parameter to get_video_details

c) Query is sent to Youtube, but it lacks video_id, so it's incomplete.

d) It returns a JSON that is an empty list (JSON is {u'items': [], u'kind': u'youtube#videoListResponse', u'etag': u'"nlUZBA6NbTS7q9G8D1GljyfTIWI/Rk41fm-2TD0VG1yv0-bkUvcBi9s"', u'pageInfo': {u'resultsPerPage': 0, u'totalResults': 0}}

e) This empty list is cached

f) All following searchs are launched against cached data, returning empty responses.

 

Argument is set to "Argument Required"

 

Is there any way to have Alfred to wait until pressing Enter or Tab before launching the Script Filter?

 

 

 

 

 

Edited August 13, 2019 by elsatch

[elsatch]

After some additional trials, I have just discovered that Workflow cache doesn't work exactly as I expected.

 

My goal was to retrieve details from a Youtube video and store them in Workflow cache. As I would repeat my workflow several times, it would make the most sense to have them cached to prevent other queries to the API.

 

As an example, I would type in Alfred: yd ckN-uJn9hAI (This will get details from the video at http://youtu.be/ckN-uJn9hAI). I would load each of the details I use more often in Workflow args and send those back to Alfred. I would select one, press enter and that would copy to my clipboard.

 

As I retype again the same command, it would retrieve data from the cache and I could copy all the other details. If I wanted to get another video details, I could do yd otherVideoID, but it would still bring back the details from the first video. Given that wf.cache triggers new queries based on time, it would probably fail to bring back the updated details.

 

It seems that I will need to create a custom function for this usage, checking the query against previous stored keys and launching the API call just when necessary.

 

If there is any other alternative/better way to do this, I would appreciate any kind of advice. It's my first time creating Workflows :)

[deanishe]

2 hours ago, elsatch said:

Is there any way to have Alfred to wait until pressing Enter or Tab before launching the Script Filter?

 

No: Script Filters are specifically designed to work that way. You should use a Keyword instead.

 

2 hours ago, elsatch said:

All following searchs are launched against cached data, returning empty responses.

 

You should use a cache key that is dependent on the query. Either the query itself, if it's filesystem safe, or the MD5 hash of the query.

 

2 hours ago, elsatch said:

Bugs: VideoIDs starting with hypens, breaks the yd call.

 

This is usually because the library you're using to interpret command-line options is interpreting the ID as an option (because it begins with a hyphen). The usual solution is to use the argument -- to say "options are finished, anything that follows is an argument".

[deanishe]

3 minutes ago, elsatch said:

If there is any other alternative/better way to do this, I would appreciate any kind of advice. It's my first time creating Workflows

 

As noted above, different data should be cached under different keys. If you always use the key search-results, then you're always going to get the same data back regardless of the search query.

Here's an example of query-based caching.