Icon Fonts about alfred-bundler

[deanishe]

The fonts are configured via JSON files (apart from system icons) that contain a list of the characters, anyway, and the bundlers can already verify CSS colours, so that should be simple enough to do.

That said, it's a problem that should become apparent during workflow development, and it'd require us to keep the bundler in sync with the icon server(s).

If I were going to change anything about the way icons are managed, it'd probably be to allow users to specify their own server(s). The software is on GitHub and it might reduce the number of requests we get to add font XYZ to the servers.

FWIW, I have a newer version of the server software that remembers your preview colour, lets you set a dark background for the preview, and has a search function (there are over 1000 icons on there). I haven't deployed it yet, as I still need to integrate the system icons in the search results.

[shawnrice]

Well, it seems that the fonts are decently stable on the icon server, and I don't think we're considering expanding the selection broadly anytime soon, so I don't think that would be a problem anytime soon.

Why allow users to specify their own servers? It seems better to just have them put in a pull request to support an icon font with us. Further, if an author implements their own server, and then the server fails (for whatever reason), we're the ones who will probably get the support request... not a fan of that.

New version sounds cool.

[deanishe]

we're considering expanding the selection broadly anytime soon

We're not, but we don't have any users yet…

I think it's a fair bet that there'll be more than one or two requests for new fonts in short order.

Why allow users to specify their own servers? It seems better to just have them put in a pull request to support an icon font with us

Because then we have to do it. Updating and restarting multiple servers (possibly creating the icon package first, though how to do this is documented). And it's perfectly possible that someone will want to use a font that we're not happy about hosting due to licensing issues or the fact that it doesn't work very well (I removed one font for this reason).

I think it's definitely a good idea to let users specify their own servers. That gives us the option of saying "not yet, but you can do it yourself" or "no, but you can do it yourself". Better answers than "not yet" and "no".

then the server fails (for whatever reason), we're the ones who will probably get the support request...

Possibly. But "not our fault" is a much easier answer to give than "no, we won't". In any case, workflow authors are usually the ones to field support requests for their own workflows.

I've not yet seen an issue on Alfred-Workflow that came from a workflow user, not the workflow author, and there are >40 workflows on Packal that use it…

[shawnrice]

What about "no, but you already have 1000 icons to choose from"? If the idea of the bundler re: icons is partly to help with re-use (and ease), then limiting them seems to be within the logic of the bundler. If they want icons that we don't offer, then they can just include them themselves... am I being too harsh here?

[deanishe]

Thing is, it's not an entirely straightforward thing to generate a PNG icon in size X with colour Y from a font file. So I think the chances are high that they'll ask us to stick the font on the server rather than figure out how to generate PNGs themselves.

And there are clear use cases for including other fonts: the fonts we have are all very general. There are more specific ones that cover, say, the weather or social networks or fuck knows what. These have no overlap with the 1000+ icons we already offer.

[shawnrice]

And there are clear use cases for including other fonts: the fonts we have are all very general. There are more specific ones that cover, say, the weather or social networks or fuck knows what. These have no overlap with the 1000+ icons we already offer.

Dammit. I hate it when you're right and it complicates things.

So, ixnay on the original idea. Should we account for custom servers in Taurus 1 or push that to Taurus 2?

[deanishe]

Dammit. I hate it when you're right, and it complicates things.

It's cos you're American. If you were German, the situations when I'm right would invariably make things simpler 😉

[shawnrice]

But you're English, posing as a German.

[deanishe]

I don't pose as a German! I more often get mistaken for a Turk.

To actually answer the question, would it really mean such big changes? We could just add a server argument to icon(). Or would that fuck up the bash version big time?

[shawnrice]

Or would that fuck up the bash version big time?

Maybe. I'd have to check how it behaves. Theoretically, it would be the same as just overriding the server arguments like we do with the custom JSON.

The only catch is that they would have to be running your server(-thingie).

[deanishe]

The only catch is that they would have to be running your server(-thingie).

Sure. Or a PHP/whatever clone. The API is fairly simple. The main thing is, we can point them in the direction of another solution, especially if we don't feel comfortable with the font's licensing/compatibility. I don't want to be hosting fonts where only half the characters work properly. We'll just have people moaning at us to fix something we can't.

If we can find a host (Heroku/Openstack/whatever) that can run the server on one of their free nodes, I'll add any necessary configuration files to the repo, so getting a server instance going should be a doddle.

It's already a piece of piss to get going provided your server supports that kind of app already, which such hosts usually do.

[shawnrice]

If we can find a host (Heroku/Openstack/whatever) that can run the server on one of their free nodes, I'll add any necessary configuration files to the repo, so getting a server instance going should be a doddle.

Could Heroku run this (almost) out of the box?

[deanishe]

I don't know, but I think so. The only thing I'd worry about not working is the email (in production mode, it emails any server errors to the admin(s)) instead of displaying a traceback in the webpage.

[shawnrice]

Is the traceback any worse than a regular 404 for the way we're using it?

[deanishe]

Tell you what, why don't you try to get it up and running on Heroku/OpenStack?

You're not a Python guy, so it'd give us a good idea of how easy/difficult it is, and what I need to do to make it easier to install.

[shawnrice]

...

I'd rather keep writing the Ruby bundler. Why don't you get it working, write up some very simple instructions, and then I can see if I can replicate them?

[deanishe]

Is the traceback any worse than a regular 404 for the way we're using it?

Tracebacks/emails only happen if there's a server error (i.e. Python threw an exception). 404s don't count. They're explicitly raised by the code and actually tell you what you did wrong in the text response (invalid colour, unknown font/character). Try it in your browser. I should really fix the Python bundler to grab the response text in case of a 404 to provide a more useful error message…

[shawnrice]

I should really fix the Python bundler to grab the response text in case of a 404 to provide a more useful error message…

But then, for us, it would behave just like a 404, and so our error handling would be the same. Hence: they mess up the setup, they just get 404's and embarrassing fallback icons.

[deanishe]

I haven't implemented fallback icons in the Python bundler yet. If the server returns an error, icon() raises an exception. I would only implement a fallback icon if there's a problem connecting to the server.

Currently, however, the underlying Python HTTP library raises an exception on 404 with no chance to get the response body. It takes a fair bit of fucking around to make Python's HTTP libs behave sensibly.

[shawnrice]

I thought we decided that we'd always return the default.png or default.icns on failure to load an icon?

For the Bash, PHP, and Ruby ones, I'm sending an error to the log and the console reporting a failure and then returning the embarrassing 'default'. Seems like the way to go.

[deanishe]

Yeah, we did, but I decided in hindsight that it's a bad idea in Python terms. Normal behaviour is to raise a ValueError if you specify a duff argument, so that's what I went with. I will implement the default icon, but only if the servers are unreachable.

[shawnrice]

Why not return the default when the server returns a 404?

[shawnrice]

Or when someone tries to load a system icon that doesn't exist (probably will happen more on the system when trying to get an icon from a different version of osx)

[deanishe]

Because letting errors pass silently is not the Python way (see item 10 of the Zen of Python).

If a user passes you a bad argument, you tell them explicitly (with an Exception).

It's only PHP where that isn't the normal thing to do.

[shawnrice]

Quick question then: within the context of "Python for Alfred" is screaming the error but giving an alternative an okay way to do things? I mean, there is a difference between Python and Python for Alfred as there is between PHP and PHP for Alfred... (maybe this is the Rhetorician in me thinking on developing this tool for our particular audience: workflow authors).

[deanishe]

within the context of "Python for Alfred" is screaming the error but giving an alternative an okay way to do things?

No. Screaming the error means raising an exception. No fucker looks at the logfile unless things are failing.

If a workflow author is using icon XYZ, they should be notified in an un-ignorable way that there is no icon XYZ. That's an error that shouldn't reach actual users.

Hiding workflow authors' errors from them does nobody any favours.

I know PHP has a culture of chugging on through errors, but that's very much a PHP-only thing. Normal languages do the sensible thing and point out when you've fucked up.

IMO, there's no reason to show the default icon unless there's a problem connecting to the server (i.e. not a problem with the workflow itself).

[shawnrice]

I think that the hegemonic dominance of PHP (on the web) has "dumbed down" PHP. I mean hegemonic in that I read recently like 80% of the Internet or something (that's a lot), but those sheer numbers mean that there are more bad PHP developers than bad anything else developers, which probably contributes to that climate.

Here is a very valid question: what's the level of proficiency that you've observed re: Python workflows in Alfred? In other words, what level of "saving the workflow author" should we default to? PHP level or Python level? (I'm asking that question pragmatically not ideologically).

[deanishe]

that there are more bad PHP developers than bad anything else developers, which probably contributes to that climate

True dat. PHP also makes it very simple for almost anyone to create a dynamic website. You can't just do that with "naked" Python/Ruby (you remember the hassle trying to use Python's built-in CGI server in the Packal updater workflow). You basically have to use a framework and they typically protect you against CSFR and XSS and SQL injection, and have secure sessions and cookies and password hashing, too. So you've got all those things, even if you've never heard of them. PHP does not do a good job in that regard simply because using a framework is entirely optional.

what's the level of proficiency that you've observed re: Python workflows in Alfred?

It varies greatly. I think a lot of the authors using PHP have used PHP before. A fair number of those using Python have never programmed before (it's often said to be the best language to start programming with). And then there are others who are good programmers, but haven't used Python before.

what level of "saving the workflow author" should we default to?

I'd draw the line at accepting input that's technically wrong but can be corrected without changing the user's intention. So, it's fine to convert an int to a string, a Unicode string to an encoded string, uppercase to lowercase etc. if that's what's required for the code to work, but it's not okay to silently accept invalid input and hand back data that you know for certain is not what the user wanted.

Handing back the default image when something is wrong with the Internet connection/server is a different matter: that's not hiding users' own mistakes from them, that's protecting them from transient errors that are out of their control and which they can't realistically do a whole lot about.

[shawnrice]

So, I have it on my todo list to remove the fallback behavior for the PHP, Bash, and Ruby bundlers.

But the question here is, are we going to code support for workflow authors to plug in their own servers? It'll need some backend changes to how the PHP and Ruby bundlers work (mostly profoundly de-coupling the Icon classes from the Bundler classes... I think).

Let's just get a yay or nay.

[deanishe]

I can definitely see us getting requests to add other fonts.

WRT implementation, I guess it depends where you're setting the server URLs. If they're in a global, it should be easy enough to override.

However, I for one, am quite happy just saying "no" to requests for new fonts.

[shawnrice]

I'm happy saying "no" as well, unless they're really cool, expand the select, and, ultimately, we want them in there.

The servers are class based variables, but that's not the problem. The problem is that they're read right before they're used, so the user has no time to alter them.

I guess that I could throw in a hookable function that would allow them to "register" a server into PHP. I just need to figure out how to do that with Ruby.

Bash, based on its current design, is harder.

[deanishe]

The problem is that they're read right before they're used, so the user has no time to alter them

Couldn't they be redefined before the icon() function is called?

Still, let's just forget about it for now.

[shawnrice]

Yeah, the hookable function would be the way that it would be redefined. But, I'm good with forgetting about it. So, closing this issue.