Merge all IDEs workflows into one workflow and have check which ones you would like to use?

[yahav01]

Is it possible to merge all IDEs workflows into one workflow and have check which ones you would like to use?

[artemy]

Hi @JamesKpP!
That's one of the ideas I've been wanting to investigate, but I haven't yet gotten to actually do it.
I'll try to find some time in September and will let you know

[gaufde]

Would it also be possible to add support for PhpStorm in the process of unifying the workflows?

[artemy]

@gaufde I evaluated a few options of unifying the workflows, but I couldn't find a solution that I liked.
I can add PhpStorm support the current way, if you like

[gaufde]

@gaufde I evaluated a few options of unifying the workflows, but I couldn't find a solution that I liked.

I'm curious, what makes this difficult? Is retrieving the recent files from the applications, or is figuring out what applications are available, or something else altogether?

I can add PhpStorm support the current way, if you like

That would be great!

[artemy]

I'm curious, what makes this difficult? Is retrieving the recent files from the applications, or is figuring out what applications are available, or something else altogether?

No, it's entirely about the UX and the possibilities of Alfred.
I would prefer that it would be possible to disable (or enable) supported apps during the workflow installation, but there's no way to do this currently, at least not without overcomplicating the mechanics of how this is put together. This makes merging all the apps into a single workflow not a convenient option in my opinion.

Maybe @vitorgalvao has a good idea for this

[artemy]

That would be great!

@gaufde I've released PhpStorm support in v2.4, please enjoy https://github.com/artemy/alfred-jetbrains-projects/releases/tag/v2.4
And thanks for the suggestion!

[gaufde]

@gaufde I've released PhpStorm support in v2.4, please enjoy https://github.com/artemy/alfred-jetbrains-projects/releases/tag/v2.4
And thanks for the suggestion!

Thanks a lot! I'll give it a shot :).

I would prefer that it would be possible to disable (or enable) supported apps during the workflow installation, but there's no way to do this currently, at least not without overcomplicating the mechanics of how this is put together. This makes merging all the apps into a single workflow not a convenient option in my opinion.

Would the workflow configuration panel not solve that issue? My experience has been that I can configure workflows in the process of installing them:

Unless I'm misunderstanding, I think some check boxes would provide the end-user experience you want:

at least not without overcomplicating the mechanics of how this is put together.

In terms of this part, I have less experience (I'm new to developing Alfred workflows). It looks to me like you have already separated app-specific configuration details out of your code with products.json. Is part of the problem that you only want app-specific keywords to exist if the app is checked in the configuration? Or does the complication come from some other design goal you have?

[artemy]

Is part of the problem that you only want app-specific keywords to exist if the app is checked in the configuration? Or does the complication come from some other design goal you have?

Yes, it's very easy to customize the configuration panel since Alfred 5, but it is not quite simple to "disable" Script Filter based on the configuration (or at all for that matter).

Actually I went to check and noticed that since Alfred 5.5 variable resolution in Input object keywords is implemented, so I will look into this again.
My idea is to let the users disable the app they don't need by making the keyword empty (which effectively will disable the respective Script Filter)

[gaufde]

Actually I went to check and noticed that since Alfred 5.5 variable resolution in Input object keywords is implemented, so I will look into this again.

Haha, I was playing around with this a bit as well! The checkboxes are booleans, so those variables wouldn't work very well as direct inputs. I started to think about ways to map the combination of checkboxes to script filter keywords, but quickly realized that "disabling" a script filter isn't possible.

My idea is to let the users disable the app they don't need by making the keyword empty (which effectively will disable the respective Script Filter)

That makes a lot of sense! And it is a lot more simple than the path I started down. Do you care if the different inputs are imported "activated" or "deactivated" by default? Since, I'm seeing that if a default value is configured for a variable (even if it isn't required by the validation), then it will be challenging to "unset" that value. The workflow would probably have to define a non-whitespace character to use to represent empty and then do some trickery that I haven't figured out to make sure that non-whitespace character doesn't end up getting used to trigger the workflow (which I'm not even sure is possible).