On Sat, 14 Jun 2014 12:42:00 +0200
Markus Wichmann <nullplan_AT_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 <dev_AT_frign.de>
Received on Sat Jun 14 2014 - 14:52:39 CEST