Add a "default transportation mode" setting
deanishe opened this issue · comments
When no mode is specified, Google defaults to "car unless travelling overseas".
For those of us who rarely travel by car, it's mildly annoying to have to enter "bike" or "pt" every time.
Could you add a setting to specify a default mode of transport to be used if none is given?
OOOH entirely valid option, I am open to that! Noted!
@deanishe while this is a more holistic discussion, I would be curious as to if you think that those defaults could be set as workflow parameters, rather than external. I am in many different minds on how to handle and store configuration, as there is not a direct programmatic way to modify the workflow parameters (short of modifying the file on disk, as opposed to an API).
I am thinking this would be fine as a workflow parameter, but then it couldn't be updated with commands, it would be a manual process.
The other option is I use a config file like I do for the browsers and tabs workflow.
I would be curious to hear your thoughts and ideas (as I value your input) before I delve into putting something together for this.
I am thinking this would be fine as a workflow parameter
If I've understood you correctly, you mean editing the workflow's code.
I would advise against that fairly strongly, as any changes a user makes get overwritten by an update to the workflow. Alfred can preserve a user's Hotkey shortcuts, keywords and workflow variable values. Everything else in the workflow directory gets overwritten.
Personally, I store any configuration in one of two places. Either in the workflow variables sheet or a separate config file (my Python library has a simple settings and Keychain API that predates the workflow variable sheet).
The advantages of the former is that Alfred gives you a UI for editing the settings, you can update the settings from your workflow using, e.g. PlistBuddy, and the settings are synced between machines.
The disadvantages are that settings are synced across machines, and Alfred can take several seconds to notice that another program has changed info.plist, so any changes you make won't be picked up immediately.
Managing your own config file obviously gives you a lot more flexibility, but it's more work, too, at least if you want the user to have a UI for managing settings.
I tend to prefer the workflow variables sheet, all other things being equal (and Alfred should soon be getting an official API for setting those variables), but sometimes find myself using a combination of methods, depending on the data being stored.
For this workflow, I'd probably put everything in the workflow variables sheet (I'm not sure addresses need to be in the Keychain).
To handle the possibility that a user might want different fallback locations for different machines, I might make the workflow understand variables prefixed with the machine's hostname, so the workflow first looks for MACHINE_VARNAME and then for plain VARNAME.
Oh no, sorry I meant as a workflow variable so you are spot on with your thinking, I would avoid having code edits at all costs.
Hmm I will have to have a ponder on the best way to store the config. I do actually have some robust code I could re-use for storing config with Perl ponders.
I have been leaning towards the workflow environment variables also, it is good to know that I am not the only one who has been thinking a combination could be good.
Knowing that an API is on the way is good, so that would lead me to opt for the Workflow Environment Variables.
I have also been pondering the addresses, they definitely don't need to be in the keychain and have been saving a major overhaul on those for v2.0.0 (which, with all your ideas, I am starting to think might be a good next version as there could be some semi-drastic changes).
I like your idea of machine_varname and varname. I will have a ponder and a tinker! I appreciate your input and thoughts, you have a lot more workflows under your belt, so I thought you might have some great ideas.
All righty, this is now in 2.0.0_Alpha1.
Available for your viewing pleasure at https://web.tresorit.com/l#YF3ytbK9g9R7joJZ4m20xg
ALL RIGHTY! This has been completed and is ready to roll. V2.0.0 Release IMPENDING!!!
(I highly recommend as soon as I do a read of the README page :D #coolNewThingsInbound, though if you just switch to the develop branch you can see it all now!)