On Sat, 14 Jun 2014 12:42:00 +0200 Markus Wichmann <nullp...@gmx.net> wrote:
> So, having one program that reads some standardized input and displays > it on screen, while another program converts any given image file to > that standardized format may be more UNIX-like. But maybe a file is not > the right representation for that standardized format. So maybe the > converter would need to be a library instead of a program. This is a very nice idea. What any image-lib basically does for internal representation is to load the image as a bitmap. An image-viewer for bitmaps piped by a converter for the common formats would be a good idea. > So yes, I argue we should rather rewrite imlib, that is, try to > implement imlib's interface in a suckless way. Unless that is > impossible, then the "rewrite feh" idea is the only one left. imlib2 is more than reading images, it's also a full-fledges font-rendering-engine and image-compositor. I'd look at it this way: Do we really need this much stuff for a simple image viewer? Wouldn't it be better to just take the stuff we need (reading images and mapping it to a certain common standard format) and be fine with it? ;) Concerning the second question, we wouldn't be far away from what I already gave as an example. Loading png's, jpg's or raws by first loading it as a common format still involves their standard libraries. However, with the difference, that this loading-procedure would simplify things on the graphics-end. Cheers FRIGN -- FRIGN <d...@frign.de>