[dev] Lightweight, non-bloated, fast image viewer?
Hi Guys, Hi Friends, I have slightly exagerated in the title of the message/thread. I would like to notice that we should have a lighter image viewer than feh, qiv and sxiv. The three are excellent image viewers. In my opinion, feh should be modified and cut down in terms of dependencies. qiv is also very nice, but similar. sxiv is lightweight and also uses imlib2 giblib, but I regret that it recommends to need libexif and libjs-jquery. Anyhow the three are good and lightweight. But in my opinion, we could think about adding a lighter application to be on the suckless page with the three current image viewer alternatives. Best regards, Pat
Re: [dev] Lightweight, non-bloated, fast image viewer?
Hi Pat, go ahead and write one. Thanks. On 06/14/2014 08:54 AM, patrick295767 patrick295767 wrote: Hi Guys, Hi Friends, I have slightly exagerated in the title of the message/thread. I would like to notice that we should have a lighter image viewer than feh, qiv and sxiv. The three are excellent image viewers. In my opinion, feh should be modified and cut down in terms of dependencies. qiv is also very nice, but similar. sxiv is lightweight and also uses imlib2 giblib, but I regret that it recommends to need libexif and libjs-jquery. Anyhow the three are good and lightweight. But in my opinion, we could think about adding a lighter application to be on the suckless page with the three current image viewer alternatives. Best regards, Pat
Re: [dev] Lightweight, non-bloated, fast image viewer?
On Sat, 14 Jun 2014 08:54:04 +0200 patrick295767 patrick295767 patrick295...@gmail.com wrote: Hey Pat, I don't know qiv and sxiv very well, so I'll just stay with feh here. In my opinion, feh should be modified and cut down in terms of dependencies. To be fair, the feh-developers did a remarkable job on their software and there are not many reasons not to call it suckless. Just like our project surf, feh suffers from the mainstream of suckness. As you may know, imlib has been occupied by Gnome, and Gnome-projects mostly suck. Moreover, feh is built on Xlibs, which isn't an issue now, but could be in the future. Now, here's the deal: I think the way to go with an image-viewer is to implement it in OpenGL ES without the imlib-layer. I am not a GL-guru, but there are tons of resources on the web on how to draw png[0], webp[1] and others to a GL-texture using the native libraries (libpng, libwebp, ...). And I found those links after a very short search. We can definitely profit here from the relevance of texture-formats in 3D-Graphics-development. Everything else (EXIF, meta, ...) would be another matter of discussion not really related to the more important render-stuff. I use exiftags if I need the information, so I don't see any need for that in an image-viewer, especially as we would want to do it as lightweight as possible. Let me know what you think. Cheers FRIGN [0]:http://blog.nobel-joergensen.com/2010/11/07/loading-a-png-as-texture-in-opengl-using-libpng/ [1]:https://groups.google.com/a/webmproject.org/forum/#!topic/webp-discuss/Gah-hB2jWpQ -- FRIGN d...@frign.de
Re: [dev] Lightweight, non-bloated, fast image viewer?
Your eyes.
Re: [dev] Lightweight, non-bloated, fast image viewer?
Hi all, Let us analyze the problem at hand: To display an image on screen, we need to - interpret the image file - display the content on screen 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. 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. Ciao, Markus
Re: [dev] Lightweight, non-bloated, fast image viewer?
page
Re: [dev] Lightweight, non-bloated, fast image viewer?
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
Re: [dev] Lightweight, non-bloated, fast image viewer?
On 14.06.14, patrick295767 patrick295767 wrote: sxiv is lightweight and also uses imlib2 giblib, but I regret that it recommends to need libexif and libjs-jquery. Just some corrections: sxiv's libexif and giflib dependencies are optional and can be turned off at compile time. It does not use giblib, don't know where you got this from, and libjs-jquery must be pulled in by (a badly built?) imlib2 package. Furthermore, it directly uses the old-school xlib API and ignores all the font-rendering stuff built into imlib2. Bert
Re: [dev] Lightweight, non-bloated, fast image viewer?
On June 14, 2014 8:52:39 AM EDT, FRIGN d...@frign.de wrote: 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? ;) Keep in mind that unless your images are always the same resolution as your screen, you're going to need to do things like resize as well.
[dev] suckless distro
Hi, I'm looking for a suckless distro. I really like crux [1], and I would like to know what are you using? Do you know any BSD equivalent? Regards, [1] : http://crux.nu/ -- ,--. : /` ) Thuban | `-'PubKey : http://yeuxdelibad.net/Divers/thuban.pub \_ KeyID : 0x54CD2F2F Envoyé à partir de mon serveur auto-hébergé signature.asc Description: Digital signature
Re: [dev] suckless distro
On Sat, Jun 14, 2014 at 05:40:17PM +0200, Thuban wrote: Hi, I'm looking for a suckless distro. I really like crux [1], and I would like to know what are you using? Some of us are working on morpheus[0]. Still quite heavy in development but we are getting there. There's also sabotage linux[1] which is pretty much usable at the moment. [0] http://morpheus.2f30.org/ [1] https://github.com/sabotage-linux/sabotage
Re: [dev] Lightweight, non-bloated, fast image viewer?
Dnia 2014-06-14, o godz. 14:52:39 FRIGN d...@frign.de napisał(a): 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. Pure suckless image viewer is indistinguishable from suckless drawing stack or suckless window server. That's how I see it. You can try to make simple image viewer or simple window server. You have to draw the line somewhere.
Re: [dev] Lightweight, non-bloated, fast image viewer?
Markus Wichmann 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. 9front has programs like that[1]. For Linux, netpbm does the same thing[2]. cat background.jpg | jpegtopnm | pnmtopng background.png If netpbm tools supported alpha, it would be great for games. No more packing around a libpng15.so. You could just fork(), execute pngtopnm on your image, then read the simple netpbm output. [1]: http://man.cat-v.org/9front/1/jpg [2]: http://netpbm.sourceforge.net/
Re: [dev] suckless distro
On Sat, 14 Jun 2014 17:40:17 +0200, Thuban thu...@yeuxdelibad.net wrote: Do you know any BSD equivalent? Not sure about the equivalent bit, but take a look at OpenBSD, there's nothing better at the moment.
[dev] [dvtm] [PATCH] Fix redraw bug when show_border() changes.
This bug presents best in certain layouts, like bstack. Demonstrate it
by starting a fresh dvtm instance (only one client open), switching to
bstack layout, then creating a new window. The old window is not
redrawn correctly now that its first line has a title bar. The dvtm
redraw command will temporarily fix the situation, but if you switch
to the old window and close it, the new window (now the only window)
is not redrawn -- the title bar is still showing. Again, the dvtm
redraw (C-g r) fixes this temporarily.
Hopefully, the patch below provides a more permanent fix.
-Mark
From d1c62b3b4ebecb66d08ee47cc521465d8d2c4fa3 Mon Sep 17 00:00:00 2001
From: Mark Edgar medgar...@gmail.com
Date: Sat, 14 Jun 2014 20:38:25 +0200
Subject: [PATCH] The Vt must redraw when show_border() changes.
---
vt.c | 8
1 file changed, 8 insertions(+)
diff --git a/vt.c b/vt.c
index 056e132..78f3571 100644
--- a/vt.c
+++ b/vt.c
@@ -163,6 +163,8 @@ struct Vt {
char rbuf[BUFSIZ];
char ebuf[BUFSIZ];
unsigned int rlen, elen;
+ /* last known start row, start column */
+ int srow, scol;
/* xterm style window title */
char title[256];
@@ -1457,6 +1459,12 @@ void vt_draw(Vt *t, WINDOW * win, int srow, int scol)
Row *sel_row_start, *sel_row_end;
int sel_col_start, sel_col_end;
+ if (srow != t-srow || scol != t-scol) {
+ vt_dirty(t);
+ t-srow = srow;
+ t-scol = scol;
+ }
+
copymode_get_selection_boundry(t, sel_row_start, sel_col_start, sel_row_end, sel_col_end, true);
for (int i = 0; i b-rows; i++) {
--
1.9.2
Re: [dev] [dvtm] [PATCH] Use ERR as the modifier for direct key bindings.
On Tue, Feb 11, 2014 at 3:38 PM, Marc André Tanner m...@brain-dump.org wrote: However some people would like to hide all borders even when there exist multiple windows. http://superuser.com/questions/706148/remove-vertical-split-bar-of-gnu-screen-vacating-the-space-instead-of-hiding-it/709427 I personally think this is too confusing. However moving the window decorations out of the layouts would probably help with that ... I came up with an idea to mitigate the confusion: vary the default background color of each window. With a dark theme, each window would have a slightly different colored dark background. Like with dvm, the first line (of the terminal) would be the title bar for the active window. The cursor should be an easily-distinguished color to help see which window is active. I'm not sure how easy this is to implement. -Mark
Re: [dev] suckless distro
On 06/14, Thuban wrote: Hi, I'm looking for a suckless distro. I really like crux [1], and I would like to know what are you using? Do you know any BSD equivalent? CRUX would get my vote too, largely because it's the most BSD-like mature Linux distro I've found. Very similar to Arch but much slimmer to begin with, and the package management system is pretty cool despite its limitations. As for the BSDs, from my observation the reasons people have for preferring any one to the rest are mutually exclusive. -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams
Re: [dev] suckless distro
Hey, i used Arch for some years but changed to Gentoo this week. It's not really BSD-equivalent by default but with some time you can do everything you want very easily. Moreover I like the USE-flag concept to compile just the things I really want and need. grayfox
RE: [dev] Lightweight, non-bloated, fast image viewer?
Hi, I wrote a simple image viewer about two weeks ago[1]. I changed my window manager to dwm several weeks ago, but I couldn't find a good image viewer, so I decided to write one. It's quite minimal, it can only display JPEG images, only supports fullscreen mode, there is no fancy resampling or caching, but it can display images and meets most of my use cases. [1] https://github.com/yjh0502/comic -Original Message- From: patrick295767 patrick295767 [mailto:patrick295...@gmail.com] Sent: Saturday, June 14, 2014 3:54 PM To: dev mail list Subject: [dev] Lightweight, non-bloated, fast image viewer? Hi Guys, Hi Friends, I have slightly exagerated in the title of the message/thread. I would like to notice that we should have a lighter image viewer than feh, qiv and sxiv. The three are excellent image viewers. In my opinion, feh should be modified and cut down in terms of dependencies. qiv is also very nice, but similar. sxiv is lightweight and also uses imlib2 giblib, but I regret that it recommends to need libexif and libjs-jquery. Anyhow the three are good and lightweight. But in my opinion, we could think about adding a lighter application to be on the suckless page with the three current image viewer alternatives. Best regards, Pat
