GeezerVison

If we know one of them works, can we just switch to that instead of complaining to the user? If it's running on a remote server (e.g. in Jupyterhub), they may well never see this error message, just the kernel dying.

i don’t see a potential problem here:

1. the kernel dies immediately
2. the sysadmin currently setting up jupyterhub will see this
3. (s)he will fix the error

The sysadmin may not notice, and if it takes a few days for them to get round to it, the user will conclude that the R kernel doesn't work and either stop trying or come and complain to us.

This is another instance of our usual debate: do we work around a bug or misconfiguration elsewhere, or complain and try to get other people to fix it? In this case (where we have one device that works), I suspect it's not the users' fault that something is picking the wrong default, so why ask them to do manually what we can perfectly well do in our own code? Computers are supposed to be labour-saving devices. ;-)

If you don't like workarounds, then we can try to work out the underlying cause of the issue and get it fixed. If that sounds hard, that's why workarounds are common! Pushing it onto the users is not a substitute.

If it has neither capability and we can't create a png device at all, there's nothing (AFAIK) we can do, so then crashing with an error message seems appropriate.

if we can change the abort to a user-visible, non-suppressible warning without having a invasive change to our code, let’s do it! i also don’t want to make the check more than once, that wouldn’t make sense.

If it has neither capability and we can't create a png device at all, there's nothing (AFAIK) we can do, so then crashing with an error message seems appropriate.

OK, so we’re just talking about the case when xlib || cairo is TRUE. sure, we can display a warning and fix the option then!