Ability to specify default conversion target

[vitalybe]

For example, for me I would like to have all currency converted by default, if no other target specified, to USD. For weight, I would like to see everything in grams, etc, etc.

[kfdm]

I've also recently wanted something similar to this. I kinda want to give this a shot, but recently I haven't had a whole lot of free time. @deanishe , if I did give this a shot, any suggestions on how you would like it to work or how you would prefer to have it structured.

[deanishe]

I think it's an awesome idea! It'd definitely be a big step forward for the workflow.

The only problem I have with it is the effort involved 😉

So, the goal is for the user to be able to specify a bunch of their favourite units, right? So, they can favourite, say, USD and EUR, and if they enter 100gbp, instead of seeing "No destination unit specified", they'll immediately see the conversion rates for USD and EUR.

Is that right?

Currencies are fairly easy to do because the workflow itself knows which currencies are available. That isn't true of any other kind of unit. (That's the reason you can view the list of currencies in the settings, but no other units.)

It just parses the query and feeds it into pint. I'm not sure how easy/difficult it is to get a list of units/valid conversions from pint. Especially as its notion of a unit is vaguer than might be useful here (e.g. mph is defined as a unit of [length]/[time]).

You may just have to let the user save a whole list of units, e.g.:

• kph
• m/s
• eur
• gbp
• usd
• litre
• cc
• pint
• …

And then try to convert any valid query to each quantity in turn, only displaying the results for the conversions that don't throw errors.

Thus, if the user enters 2 cup, they'll see the conversions for litre, cc and pint (all the others would raise exceptions).

[kfdm]

I haven't thought much about the UI for how it works, more of just how I imagined it working for myself. You could define a dictionary of units that you wanted auto converted. For example

auto['degF'] = 'degC'
auto['degC'] = 'degF'
auto['mi'] = 'km'
auto['km'] = 'mi'
auto['usd'] = 'jpy'

etc

Then when the workflow parses, if the unit isn't selected yet, example conv 80 degF then it would use the lookup table in auto, to submit the string to the underlying pint library. conv 80 degF degC

if lookup in auto:
   # Append auto converstion to the end of our query
   query = query += auto[lookup]
else:
   # pass the default query to pint
   query

Very ugly psudo code since I don't have the actual code open right now, but that was my rough idea about how it might work.

[vitalybe]

Regarding currencies, as you said it should be easy enough. For other pint measurements I played with Pint's API a bit, and here is one way it could work (looking at the code here)

User input: 5 ton in gram

# returns "[mass]"
base_dimensionality = str(from_unit.dimensionality)

Alfred: Do you want to automatically convert "mass" units in the future to "gram"?
User input: Yes

auto_conversations[base_dimensionality] = to_unit

User input: 5 ton

base_dimensionality = str(from_unit.dimensionality)
if base_dimensionality in auto_conversations:
    to_unit = auto_conversations[base_dimensionality]

This will allow the user to avoid pre-defining all the units and allow him to define everything only if he needs it.

Thoughts?

[deanishe]

So you're thinking you could specify, say, km = [ft, furlongs, miles, nautical_miles] as "favourites", and then whenever you enter XX km, the conversions for feet, furlongs, miles and nautical miles would appear automatically without a destination unit.

Is that right?

[vitalybe]

@deanishe Err... Whom are you replying to? 😄

[deanishe]

😄 I was replying to @kfdm.

@vitalybe: If it's possible to do it that way (per-dimensionality favourites), I think that'd be the best solution.

Perhaps hitting CMD+ENTER on a conversion result would save that unit as a favourite for that dimensionality?

[kfdm]

Ahh, I hadn't even thought of CMD+Enter (Ctrl+Enter, etc) as a way to control the favorites list, but that seems like it could be a good way to handle it. @deanishe what are your feelings for trying to continue to support Alfred 2 or is requiring Alfred 3 safe? Without looking at the code, I don't think it would be too difficult to still support Alfred 2, but I seem to recall some changes around how the modifier keys worked with filter lists that could make it easier to implement if only Alfred 3 is supported.

[deanishe]

I think CMD+ENTER in the conversion results list to add/remove favourite units would be a good UX, and relatively simple to implement.

Regarding Alfred 3: I don't think any of its new features are a compelling fit for this workflow. Additionally, there's a fundamental issue with the Alfred-Workflow update mechanism that would lead to it installing Alfred-3-only workflows in Alfred 2, thus breaking them.

[deanishe]

Added in v3.0

Use ⌘↩ on a conversion result to add/remove that unit as a default for the current dimensionality.

If no destination unit is given, the workflow will show conversions to all of the corresponding defaults.