Supporting reading the image from stdin about swww HOT 15 CLOSED

Wait... I just forgot to restart swww after my upgrade. Sorry for the confusion!

from swww.

Thanks for the immediate fix!

from swww.

The current workaround is to first save it to a temp file, load swww img, and then removes the temp file

from swww.

This should be pretty doable, actually. Though it will create a problem where swww query won't know the name of the image (since it uses the file's name for that). So it would answer something like: currently displaying "stdin". Would that be fine?

from swww.

Perfectly fine!

from swww.

My apologies, I realized that this is actually harder than I initially thought. This is because what we send to the daemon is not the image file, but the image's filename. This means that, currently, in order to read a image, it needs to exist somewhere in the file system. I might be able to do something using temporary files, but, again, this is more complicated than what I had fist envisioned.

from swww.

Alright. The only limitation is that #62 will not animate any gifs you send in. I think I am going to keep it that way, since I don't really like the idea of piping giant gifs through stdin into the program.

from swww.

I decided to close like this for now, if anyone reading this would like to read animated gifs from stdin, please open another issue and I will get to it.

from swww.

org-cat test.png | swww img -o HDMI-A-1 -(error msg Error: "Failed to serialize request: io error: Broken pipe (os error 32)")
Why would this fail?
org-cat test.png | imv -
This however works.

from swww.

it shouldn't, specially not with that error.
Thanks for testing this!

Re-openning.

from swww.

Now, we have a problem: I can't seem to be able to reproduce this...

Can you maybe give some more details? Do you literally just swww init and then try doing that?

from swww.

this seem to be broken on the latest git.
org-cat /tmp/out.png | swww img - this doesn't work

from swww.

This is the faulty commit. I wonder if it's possible to make these kind of stuff in tests.

from swww.

Ah yes, this is because we are trying to canonicalize all paths, but '-' is not a valid path, is it?

from swww.

I am fixing it; added a new test too to make sure it doesn't happen again

from swww.