imgcat icon indicating copy to clipboard operation
imgcat copied to clipboard

Added support for custom image loaders

Open schoentoon opened this issue 4 years ago • 10 comments

Took a bit longer than I expected. I ended up going for a whole interface around it, which you can implement yourself in any way you'd like.

schoentoon avatar Oct 29 '20 01:10 schoentoon

@muesli since you are the first 3rd party consumer of this API could you review this PR to confirm it meets what your use case for glow?

trashhalo avatar Oct 29 '20 14:10 trashhalo

I think I would have just gone for an io.Reader. That's all we need to load data. The wrappers for http / file loaders around it can be tiny then and we remove a lot of duplicated code.

muesli avatar Nov 08 '20 18:11 muesli

Now that I look at it again I should probably have made the HttpImage accept a custom http.Client anyway. I mostly just figured that the file and http loaders were gonna be needed to keep the command line tool working anyway. So wouldn't make a huge difference whether it would be exposed in the library or just in the command line tool imo.

schoentoon avatar Nov 08 '20 18:11 schoentoon

Understood. I'll quickly whip up an example with a simple io.Reader approach for comparison.

muesli avatar Nov 08 '20 19:11 muesli

Here it is: #15

muesli avatar Nov 08 '20 19:11 muesli

Just as a heads up: I skipped the other improvements @schoentoon introduced. Nice work there, I'm all for them!

muesli avatar Nov 08 '20 19:11 muesli

@schoentoon You got some gnarly conflicts at the moment. For this to get merged. Changes I'd like to see:

  1. Obvi conflicts addressed
  2. Lib code moved back to root OR follow go standard layout

I have some bandwidth this weekend to push this forward if you are swamped.

trashhalo avatar Nov 12 '20 14:11 trashhalo

TIL /lib is non-standard. I'll move it to /pkg later today and address the conflicts.

schoentoon avatar Nov 12 '20 15:11 schoentoon

@schoentoon Yeah, it's all conventions, but I guess it makes sense to stick to the established ones. Sorry for causing the merge conflicts here, but I hope you can see why using the existing io.ReadCloser interface is sufficient in this case: it enables compatibility with an entire ecosystem of existing Go packages that all support this very interface (or the easily NilCloser wrapped io.Reader).

For this reason I think we should try not to introduce an ImageLoader interface here unless we got a really good reason for it.

muesli avatar Nov 18 '20 07:11 muesli

I would argue that being able to provide a image.Image directly (or a gif.GIF for that matter) would be nice to have as well. Take for example wanting to apply certain filters over an image somewhere within your program. You'll probably already have a image.Image in such a case. Not having to encode it to later on decode it again seems like a benefit to me.

schoentoon avatar Nov 18 '20 16:11 schoentoon