Re: [dev] [sxiv] doesn't want to be compiled
On 08.10.17, Laslo Hunhold wrote: > On Sun, 8 Oct 2017 10:43:27 +0200 > Bert Münnich <be...@posteo.de> wrote: > > Dear Bert, > > > Maybe it's better to write a new minimal BSD Makefile using > > bsd.prog.mk instead of tailoring sxiv's GNU Makefile to make it work > > with BSD make. > > just read the POSIX spec[0] on make and stop thinking within the bounds > of BSD or GNU make. > It's hard to make it right, but I went through great efforts to make > the farbfeld makefile[1] truly portable. Another good resource and > closer to your needs is the, also portable, slstatus makefile[2]. > > We need to stop falling for the fallacy that "portable" means "works > with BSDmake and GNUmake". Truly portable means consistent with the > POSIX spec. I can only repeat the paragraph that directly preceded the one you've quoted: > I rather use a portable make than bother to write a portable Makefile. > Also, out-of-source builds are much harder if only using POSIX make > syntax. I have spent a considerable amount of time with both POSIX make and GNU make and deliberately made the choice to use the latter. Before switching to GNU make I had a portable Makefile and users kept asking me to use '+=' and '?=' macro assignment operators for the standard macros like 'CC' and 'CFLAGS'. Also, when using POSIX one can still encounter users whose systems do not support the latest draft. Correct me if I am wrong, but POSIX supports 'include' only since the 2016 version. And since switching to GNU make I really got the hang of automatic dependency generation and out-of-source builds. For me it all boils down to rather having a build process that the authors can enjoy instead of limiting themselves to the most basic features. Bert
Re: Re: [dev] [sxiv] doesn't want to be compiled
On 07.10.17, Cág wrote: > I've tried it, the output complains about missing object files: > --- > cc: autoreload_inotify.o: No such file or directory > cc: commands.o: No such file or directory > cc: image.o: No such file or directory > cc: main.o: No such file or directory > cc: options.o: No such file or directory > cc: thumbs.o: No such file or directory > cc: util.o: No such file or directory > cc: window.o: No such file or directory > *** Error 1 in /home/caoc/code/suckless/sxiv (Makefile:30 'sxiv': cc > -L/usr/X11R6/lib -L/usr/local/lib -o sxiv autoreload_inotify.o command...) > --- Your '.c.o' suffix rule is not executed because the suffix list gets cleared at the end of the Makefile. You either have to delete the '.SUFFIXES:' rule or add another one with '.c' and '.o'. > On a side note: I suppose you are the author, any plans to make the Makefile > portable? Yes, I am. Unfortunately for you, I have no such plans. I rather use a portable make than bother to write a portable Makefile. Also, out-of-source builds are much harder if only using POSIX make syntax. Maybe it's better to write a new minimal BSD Makefile using bsd.prog.mk instead of tailoring sxiv's GNU Makefile to make it work with BSD make. Bert
Re: [dev] [sxiv] Discussion
On 09.08.16, Cág wrote: > How about adding a wallpaper feature? Is it a complex solution? You can add a call to the wallpaper program of your choice to the external key-handler. Bert
Re: [dev] [sxiv] Discussion
On 09.08.16, FRIGN wrote: > haha yeah. Fun fact: feh now supports farbfeld :) Try it out! Thanks to the farbfeld loader in imlib2. sxiv uses that, too. Bert
Re: [dev] [sxiv] Discussion
On 09.08.16, Silvan Jegen wrote: > If the conversion tools are already written (I wasn't sure this was > the case already) then all that's left to simplify sxiv would be to > make it speak only farbfeld and then to wrap it up in a shell script > (?) that converts all arguments to temporary farbfeld files and passes > them to sxiv. There's already lel[0] that does just this. But sxiv is not only an image viewer. I heavily use it to organize my image library, e.g. visually selecting files to import from a huge collection of freshly taken photos or performing simple editing tasks like rotating--lossless in case of JPEG--and tagging images with the external key-handler. Using temporary farbfeld files as input would not make this easier. Bert [0] http://git.2f30.org/lel/
Re: [dev] [sxiv] Discussion
On 09.08.16, FRIGN wrote: > don't take it personally, Bert, but I don't think your project sxiv[0] > belongs to the suckless git-repository. > [...] > Do we really need a project the size of dwm to display images? > [...] > What do you think? I was asked for sxiv becoming an official suckless project. I had nothing against that move. And I have nothing against reversing it. Bert
Re: [dev] [dwm] Fullscreen clients not resized on X display resolution change
On 12.10.15, Chris Down wrote:
> I took a quick look at the code, but I didn't see any obvious reason
> for this. I will look a bit further and supply a patch if I work it
> out, but if anyone else has any ideas I'd be glad to hear them.
The attached patch fixes the problem.
Enjoy,
Bert
diff --git a/dwm.c b/dwm.c
index 169adcb..020d418 100644
--- a/dwm.c
+++ b/dwm.c
@@ -554,6 +554,7 @@ configure(Client *c) {
void
configurenotify(XEvent *e) {
+ Client *c;
Monitor *m;
XConfigureEvent *ev = >xconfigure;
Bool dirty;
@@ -566,8 +567,12 @@ configurenotify(XEvent *e) {
if(updategeom() || dirty) {
drw_resize(drw, sw, bh);
updatebars();
- for(m = mons; m; m = m->next)
+ for(m = mons; m; m = m->next) {
+ for(c = m->clients; c; c = c->next)
+ if(c->isfullscreen)
+ resizeclient(c, m->mx, m->my,
m->mw, m->mh);
XMoveResizeWindow(dpy, m->barwin, m->wx, m->by,
m->ww, bh);
+ }
focus(NULL);
arrange(NULL);
}
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] [dwm] Looking for a focusonclick that with MODKEY+Button3
On Wed, Dec 12, 2012 at 7:32 AM, Eric Pruitt eric.pru...@gmail.com wrote: Do you know where this patch came from? I like to keep attribution and source information for my patches, but I have been unable to locate where this patch came from. I wrote it after this message from Alexander Polakov was posted on the mailing list: http://lists.suckless.org/dev/1109/9318.html Bert
Re: [dev] [dwm] Looking for a focusonclick that with MODKEY+Button3
On Sat, Dec 8, 2012 at 7:55 PM, Eric Pruitt eric.pru...@gmail.com wrote: Is there a focusonclick patch that anyone is aware of that still works with things like Right Click + Alt? Because of the change from Async to Sync in grabbuttons in the focusonclick patch, I am unable to use certain mouse shortcuts. The attached patch works for me. Bert dwm-6.0-clickfocus.diff Description: Binary data
Re: [dev] [dwm] question regarding floating clients being always on top
On 20.02.12, Uli Armbruster wrote:
By default, floating clients are always on top of tiled clients. I'd
like to change this behavior to make it possible to use floating and
tiled clients together (either having the same tag or if multiple tags
are selected) so the currently selected client is on top, no matter if
it's floating or tiled.
So, where can I find this in the source code?
The first attached patch does the trick, but only when using the
keyboard mappings (mod-[jk], focusstack).
The second one adds the behaviour for sloppy focus.
Bert
diff -rup dwm-6.0-orig/dwm.c dwm-6.0/dwm.c
--- dwm-6.0-orig/dwm.c 2011-12-19 22:22:25.0 +0100
+++ dwm-6.0/dwm.c 2012-02-23 20:48:28.0 +0100
@@ -1420,13 +1420,12 @@ restack(Monitor *m) {
drawbar(m);
if(!m-sel)
return;
- if(m-sel-isfloating || !m-lt[m-sellt]-arrange)
- XRaiseWindow(dpy, m-sel-win);
+ XRaiseWindow(dpy, m-sel-win);
if(m-lt[m-sellt]-arrange) {
wc.stack_mode = Below;
wc.sibling = m-barwin;
for(c = m-stack; c; c = c-snext)
- if(!c-isfloating ISVISIBLE(c)) {
+ if(c != m-sel !c-isfloating ISVISIBLE(c)) {
XConfigureWindow(dpy, c-win,
CWSibling|CWStackMode, wc);
wc.sibling = c-win;
}
diff -rup dwm-6.0-orig/dwm.c dwm-6.0/dwm.c
--- dwm-6.0-orig/dwm.c 2011-12-19 22:22:25.0 +0100
+++ dwm-6.0/dwm.c 2012-02-23 21:00:26.0 +0100
@@ -456,6 +456,7 @@ buttonpress(XEvent *e) {
}
else if((c = wintoclient(ev-window))) {
focus(c);
+ restack(selmon);
click = ClkClientWin;
}
for(i = 0; i LENGTH(buttons); i++)
@@ -829,6 +830,7 @@ enternotify(XEvent *e) {
else if(!c || c == selmon-sel)
return;
focus(c);
+ restack(selmon);
}
void
Re: [dev] stest review
On 10.02.12, Connor Lane Smith wrote:
On 9 February 2012 19:20, Anselm R Garbe garb...@gmail.com wrote:
Can we please remove the getopt() dependency?
If someone writes an ARGBEGIN-style flag parser with clustering,
that's fine. Seems a bit of a waste considering getopt is POSIX, but
never mind.
There you go...
Bert
#ifndef _ARG_H_
#define _ARG_H_
extern const char *_argv0;
#define SET(x) ((x)=0)
#define USED(x) ((void)(x))
#define ARGBEGIN \
for (_argv0=*argv++, argc--; \
argv[0] argv[0][0]=='-' argv[0][1]; \
argv++, argc--) \
{ \
char _argc, *_args, *_argt; \
_args = argv[0][1]; \
if (_args[0]=='-' !_args[1]) {\
argc--;\
argv++;\
break; \
}\
_argc=0; \
while (*_args) \
{\
_argc = *_args++; \
switch (_argc) \
{
#define ARGEND \
} \
} SET(_argt); USED(_argt); USED(_argc); USED(_args); \
} USED(argc); USED(argv);
#define ARGF() \
(_argt=_args, _args=,\
(*_argt ? _argt : (argv[1] ? (argc--, *++argv) : 0)))
#define EARGF(x) \
(_argt=_args, _args=,\
(*_argt ? _argt : (argv[1] ? (argc--, *++argv) : ((x), abort(), 0
#define ARGC() _argc
#endif /* _ARG_H_ */
Re: [dev] Some 2wm questions
On 01.11.11, Connor Lane Smith wrote:
2wm is very old and completely unsupported, so I doubt there are
patches like this. It would be awesome if there were a dwm 'stereo
patch', though.
I've tried 2wm some time ago, liked the concept but got fed up with its
old code base. So I wrote a small dwm - 2wm (d2wm) conversion patch.
The patch simply changes toggle{tag,view}, so that they move the current
client to the other tag / change the view to the other tag.
Some additional lines in the patch overwrite the tagnames with the
number of clients attached to the tag.
The patch also changes some mouse and keybindings in config.def.h, most
importantly Mod-{Shift-}Space for toggle{view,tag}, so that one can
directly try it out.
Bert
diff -rup dwm-5.9-orig/config.def.h dwm-5.9/config.def.h
--- dwm-5.9-orig/config.def.h 2011-11-01 08:50:33.0 +0100
+++ dwm-5.9/config.def.h2011-11-01 08:58:00.0 +0100
@@ -14,7 +14,7 @@ static const Bool showbar = Tr
static const Bool topbar= True; /* False means bottom bar */
/* tagging */
-static const char *tags[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
+static const char *tags[] = { 1, 2 };
static const Rule rules[] = {
/* class instancetitle tags mask isfloating
monitor */
@@ -35,11 +35,6 @@ static const Layout layouts[] = {
/* key definitions */
#define MODKEY Mod1Mask
-#define TAGKEYS(KEY,TAG) \
- { MODKEY, KEY, view, {.ui = 1
TAG} }, \
- { MODKEY|ControlMask, KEY, toggleview, {.ui = 1
TAG} }, \
- { MODKEY|ShiftMask, KEY, tag,{.ui = 1
TAG} }, \
- { MODKEY|ControlMask|ShiftMask, KEY, toggletag, {.ui = 1
TAG} },
/* helper for spawning shell commands in the pre dwm-5.0 fashion */
#define SHCMD(cmd) { .v = (const char*[]){ /bin/sh, -c, cmd, NULL } }
@@ -62,24 +57,14 @@ static Key keys[] = {
{ MODKEY|ShiftMask, XK_c, killclient, {0} },
{ MODKEY, XK_t, setlayout, {.v =
layouts[0]} },
{ MODKEY, XK_f, setlayout, {.v =
layouts[1]} },
+ { MODKEY|ShiftMask, XK_f, togglefloating, {0} },
{ MODKEY, XK_m, setlayout, {.v =
layouts[2]} },
- { MODKEY, XK_space, setlayout, {0} },
- { MODKEY|ShiftMask, XK_space, togglefloating, {0} },
- { MODKEY, XK_0, view, {.ui = ~0 }
},
- { MODKEY|ShiftMask, XK_0, tag,{.ui = ~0 }
},
+ { MODKEY, XK_space, toggleview, {0} },
+ { MODKEY|ShiftMask, XK_space, toggletag, {0} },
{ MODKEY, XK_comma, focusmon, {.i = -1 } },
{ MODKEY, XK_period, focusmon, {.i = +1 } },
{ MODKEY|ShiftMask, XK_comma, tagmon, {.i = -1 } },
{ MODKEY|ShiftMask, XK_period, tagmon, {.i = +1 } },
- TAGKEYS(XK_1, 0)
- TAGKEYS(XK_2, 1)
- TAGKEYS(XK_3, 2)
- TAGKEYS(XK_4, 3)
- TAGKEYS(XK_5, 4)
- TAGKEYS(XK_6, 5)
- TAGKEYS(XK_7, 6)
- TAGKEYS(XK_8, 7)
- TAGKEYS(XK_9, 8)
{ MODKEY|ShiftMask, XK_q, quit, {0} },
};
@@ -94,9 +79,7 @@ static Button buttons[] = {
{ ClkClientWin, MODKEY, Button1,movemouse,
{0} },
{ ClkClientWin, MODKEY, Button2,togglefloating,
{0} },
{ ClkClientWin, MODKEY, Button3,resizemouse,
{0} },
- { ClkTagBar,0, Button1,view,
{0} },
- { ClkTagBar,0, Button3,toggleview,
{0} },
- { ClkTagBar,MODKEY, Button1,tag,
{0} },
- { ClkTagBar,MODKEY, Button3,toggletag,
{0} },
+ { ClkTagBar,0, Button1,toggleview,
{0} },
+ { ClkTagBar,0, Button3,toggletag,
{0} },
};
diff -rup dwm-5.9-orig/dwm.c dwm-5.9/dwm.c
--- dwm-5.9-orig/dwm.c 2011-11-01 08:50:33.0 +0100
+++ dwm-5.9/dwm.c 2011-11-01 08:54:09.0 +0100
@@ -247,7 +247,7 @@ static void zoom(const Arg *arg);
/* variables */
static const char broken[] = broken;
Re: [dev] Some 2wm questions
On 01.11.11, Connor Lane Smith wrote:
On 1 November 2011 08:25, Bert Münnich be.muenn...@googlemail.com wrote:
I've tried 2wm some time ago, liked the concept but got fed up with its
old code base. So I wrote a small dwm - 2wm (d2wm) conversion patch.
Thanks for this.
The patch simply changes toggle{tag,view}, so that they move the current
client to the other tag / change the view to the other tag.
I notice this patch doesn't have an attach (M-a) to accompany detach
(M-d). Is this a bug or a feature?
It's a feature. I've used attach only very rarely. Instead, I switch to
the other tag temporarily, use detach (toggletag) on the clients I want
to detach and switch back.
Bert
Re: [dev] [dwm] Setting Initial Geometry for Floating Windows
On 17.08.11, Bastien Dejean wrote:
Is there any patch to make dwm handles a ruled based user specified
initial geometry for floating windows?
I've just hacked together a working patch for dwm 5.9.
It adds a member named geometry to the Rule struct, enabling you to
add a typical X geometry string (WIDTHxHEIGHT+X+Y) to any rule in your
config.h.
See the rules array in config.def.h after applying the patch to see an
example.
Please note, that this patch is not well tested and that it is kind of
anti-dwm. I wrote it because I was bored.
Bert
diff -rup dwm-5.9-orig/config.def.h dwm-5.9/config.def.h
--- dwm-5.9-orig/config.def.h 2011-07-10 22:24:25.0 +0200
+++ dwm-5.9/config.def.h2011-08-17 17:15:47.0 +0200
@@ -17,9 +17,10 @@ static const Bool topbar= Tr
static const char *tags[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
static const Rule rules[] = {
- /* class instancetitle tags mask isfloating
monitor */
- { Gimp, NULL, NULL, 0,True,-1 },
- { Firefox, NULL, NULL, 1 8, False, -1 },
+ /* class instancetitle tags mask isfloating
geometrymonitor */
+ { Gimp, NULL, NULL, 0,True,NULL,
-1 },
+ { Firefox, NULL, NULL, 1 8, False, NULL,
-1 },
+ { XCalc,NULL, NULL, 0,True,
225x333+200+100, -1 },
};
/* layout(s) */
diff -rup dwm-5.9-orig/dwm.c dwm-5.9/dwm.c
--- dwm-5.9-orig/dwm.c 2011-07-10 22:24:25.0 +0200
+++ dwm-5.9/dwm.c 2011-08-17 17:19:07.0 +0200
@@ -148,6 +148,7 @@ typedef struct {
const char *title;
unsigned int tags;
Bool isfloating;
+ const char *geometry;
int monitor;
} Rule;
@@ -290,6 +291,8 @@ applyrules(Client *c) {
const Rule *r;
Monitor *m;
XClassHint ch = { 0 };
+ int geomask, x, y;
+ unsigned int w, h;
/* rule matching */
c-isfloating = c-tags = 0;
@@ -307,6 +310,19 @@ applyrules(Client *c) {
for(m = mons; m m-num != r-monitor; m =
m-next);
if(m)
c-mon = m;
+ if(r-geometry) {
+ c-isfloating = True;
+ /* long version, so that it's possible
to add some checks */
+ geomask = XParseGeometry(r-geometry,
x, y, w, h);
+ if(geomask WidthValue)
+ c-w = w;
+ if(geomask HeightValue)
+ c-h = h;
+ if(geomask XValue)
+ c-x = x;
+ if(geomask YValue)
+ c-y = y;
+ }
}
}
if(ch.res_class)
@@ -1104,6 +1120,12 @@ manage(Window w, XWindowAttributes *wa)
die(fatal: could not malloc() %u bytes\n, sizeof(Client));
c-win = w;
updatetitle(c);
+ /* geometry */
+ c-x = c-oldx = wa-x;
+ c-y = c-oldy = wa-y;
+ c-w = c-oldw = wa-width;
+ c-h = c-oldh = wa-height;
+ c-oldbw = wa-border_width;
if(XGetTransientForHint(dpy, w, trans) (t = wintoclient(trans))) {
c-mon = t-mon;
c-tags = t-tags;
@@ -1112,12 +1134,6 @@ manage(Window w, XWindowAttributes *wa)
c-mon = selmon;
applyrules(c);
}
- /* geometry */
- c-x = c-oldx = wa-x;
- c-y = c-oldy = wa-y;
- c-w = c-oldw = wa-width;
- c-h = c-oldh = wa-height;
- c-oldbw = wa-border_width;
if(c-w == c-mon-mw c-h == c-mon-mh) {
c-isfloating = True;
c-x = c-mon-mx;
Re: [dev] [st] alternate screen switching
On 08.06.11, Aurélien Aptel wrote: On Wed, Jun 1, 2011 at 9:59 AM, Bert Münnich be...@gmx.com wrote: I would also like to look into the scrollback buffer goal. How do you want to achieve an unlimited scrollback buffer? Writing every line to a file and printing its content instead of the current buffer when scrolling back? What are the cons to just having a fixed amount of lines (simply a bigger Line *line), memmoving them when input arrives and normally displaying only the row-1 last ones? It could be done that way, yes. Personally, I don't need the scollback buffer but from what I've gathered there are more people who want it than people who don't. It's even written here http://st.suckless.org/goals It would be great if st could export an interface to it so things like URL selecting/launching in browser could be done via scripts. Something like a plan9 file hierarchy. I would like to hear someone else thoughts about that. I'm not sure about the exporting thing. If there's one thing I've learned from writing url-select [1], it's that a lot of URLs get line wrapped inside curses-based applications (e.g. mcabber, irssi, weechat, vim, newsbeuter, mutt) and there's nothing you can do about getting them right at the terminal level. I handle all URLs using a simple dmenu- based script [2] from within the applications, because they see the actual text and not the curses-representation of it. People get often enoyed by long multi-line URLs they can't select/open easily. And the simpler one-line ones could be easily selected inside rxvt-unicode by simply double-clicking them. IMO a decent double- and triple-click text selection handling is much more important than URL matching. 1: https://github.com/muennich/urxvt-perls 2: https://raw.github.com/muennich/dotfiles/master/bin/durlview
Re: [dev] [st] alternate screen switching
On 08.06.11, Aurélien Aptel wrote:
On Wed, Jun 1, 2011 at 9:59 AM, Bert Münnich be...@gmx.com wrote:
Hi,
attached is a patch, that adds support for the deprecated '\E[?47h' and
'\E[?47l' control sequences, which are used when $TERM == xterm-color.
I've also added {rm,sm}cup entries to st.info, so that switching between
normal and alternate screen now works when $TERM == st[-256color].
Thanks.
What's the difference between 1047 and 47? st now use the same code
for both, but it can be changed.
47 is deprecated and doesn't clear the screen when switching. It's still
often used in terminfos instead of the newer 104X, which made me believe
it would be a good idea to include it.
Re: [dev] [st] revised mouse handling/reporting
On 08.06.11, Aurélien Aptel wrote: On Fri, Jun 3, 2011 at 12:41 PM, Bert Münnich be...@gmx.com wrote: rxvt-unicode is a lot more simpler. It behaves in the same way as my patch: simply reversing the default fg and bg colors. All the others fg and bg colors remain untouched. ok A nice example to see the difference is alsamixer, which uses a black bg on the whole screen. My patched st and rxvt-unicode display it as black in normal and reverse mode, whereas xterm flips the background to white Your patch still doesn't make st behave like urxvt. See first screenshot attached. I'm using a light background, so I didn't notice these differences--I guess I have to test things a bit more in the future... The problem is that st has no way to tell the default bg from black (if your default bg is black). See second screenshot attached. So there's no easy way of implementing the reverse video mode? I couldn't find a decent text, which describes what exactly has to be done in reverse video mode. The only thing I've found was the mention of using light on dark by default and dark on light when in reverse video. But apart from it not working in the same way as xterm and urxvt, I think that my patch actually works kind of in the expected way. I've used it from time to time in the past few days and couldn't find a showstopper (again not really looking closely, only on light default bg). So we can use it for the moment or forget about it altogether, I'm fine with it. I don't know, what we could easily do to make it work in another way. --Bert
Re: [dev] [st] revised mouse handling/reporting
On 03.06.11, Aurélien Aptel wrote: On Thu, Jun 2, 2011 at 2:28 PM, pancake panc...@youterm.com wrote: I wonder if those patches are going to be commited.. I find them right. But it's about the third patch in a week without any reply.. I've already committed some of them them locally, not finished yet. The reverse video one doesn't behave like xterm on my machine. You're right, xterm does a lot more than just reversing the default fg and bg colors. It checks the fg and bg colors and also switches colors 'near' them, i.e. if the bg color is white, then color '\e[37m' is also changed to black (the normal fg color). I think that this behaviour is problematic, because color '\e[37m' is often used as light gray instead of white. rxvt-unicode is a lot more simpler. It behaves in the same way as my patch: simply reversing the default fg and bg colors. All the others fg and bg colors remain untouched. A nice example to see the difference is alsamixer, which uses a black bg on the whole screen. My patched st and rxvt-unicode display it as black in normal and reverse mode, whereas xterm flips the background to white when in reverse mode (if the normal bg is white). I prefer the behaviour of rxvt-unicode, because it's simpler and because I think, that an application, which requests a black bg, should get it in either mode. Another question is wether to change the border. rxvt-unicode doesn't change it when in reverse video mode (so does my patch), but xterm does. This can easily be fixed, though.
[dev] [st] patch for reverse video (DECSCNM)
Hello again,
attached is a patch to support the DECSCNM reverse video mode.
I've compared my patched st to xterm and rxvt-unicode and couldn't find
a difference.
Bert
--- a/st.c 2011-06-01 15:29:53.0 +0200
+++ b/st.c 2011-06-01 15:25:10.0 +0200
@@ -64,7 +64,7 @@ enum { CURSOR_UP, CURSOR_DOWN, CURSOR_LE
enum { CURSOR_DEFAULT = 0, CURSOR_HIDE = 1, CURSOR_WRAPNEXT = 2 };
enum { GLYPH_SET=1, GLYPH_DIRTY=2 };
enum { MODE_WRAP=1, MODE_INSERT=2, MODE_APPKEYPAD=4, MODE_ALTSCREEN=8,
- MODE_CRLF=16, MODE_MOUSE=32 };
+ MODE_CRLF=16, MODE_MOUSE=32, MODE_REVERSE=64 };
enum { ESC_START=1, ESC_CSI=2, ESC_OSC=4, ESC_TITLE=8, ESC_ALTCHARSET=16 };
enum { WIN_VISIBLE=1, WIN_REDRAW=2, WIN_FOCUSED=4 };
@@ -1103,7 +1103,11 @@ csihandle(void) {
case 1:
term.mode = ~MODE_APPKEYPAD;
break;
- case 5: /* TODO: DECSCNM -- Remove reverse video */
+ case 5: /* DECSCNM -- Remove reverse video */
+ if(IS_SET(MODE_REVERSE)) {
+ term.mode = ~MODE_REVERSE;
+ draw();
+ }
break;
case 7:
term.mode = ~MODE_WRAP;
@@ -1167,7 +1171,10 @@ csihandle(void) {
term.mode |= MODE_APPKEYPAD;
break;
case 5: /* DECSCNM -- Reverve video */
- /* TODO: set REVERSE on the whole screen (f) */
+ if(!IS_SET(MODE_REVERSE)) {
+ term.mode |= MODE_REVERSE;
+ draw();
+ }
break;
case 7:
term.mode |= MODE_WRAP;
@@ -1508,7 +1515,7 @@ xloadcols(void) {
void
xclear(int x1, int y1, int x2, int y2) {
- XSetForeground(xw.dpy, dc.gc, dc.col[DefaultBG]);
+ XSetForeground(xw.dpy, dc.gc, dc.col[term.mode MODE_REVERSE ?
DefaultFG : DefaultBG]);
XFillRectangle(xw.dpy, xw.buf, dc.gc,
x1 * xw.cw, y1 * xw.ch,
(x2-x1+1) * xw.cw, (y2-y1+1) * xw.ch);
@@ -1640,14 +1647,14 @@ xinit(void) {
void
xdraws(char *s, Glyph base, int x, int y, int charlen, int bytelen) {
- unsigned long xfg, xbg;
+ unsigned long xfg, xbg, temp;
int winx = x*xw.cw, winy = y*xw.ch + dc.font.ascent, width =
charlen*xw.cw;
int i;
+ xfg = dc.col[term.mode MODE_REVERSE base.fg == DefaultFG ?
DefaultBG : base.fg];
+ xbg = dc.col[term.mode MODE_REVERSE base.bg == DefaultBG ?
DefaultFG : base.bg];
if(base.mode ATTR_REVERSE)
- xfg = dc.col[base.bg], xbg = dc.col[base.fg];
- else
- xfg = dc.col[base.fg], xbg = dc.col[base.bg];
+ temp = xfg, xfg = xbg, xbg = temp;
XSetBackground(xw.dpy, dc.gc, xbg);
XSetForeground(xw.dpy, dc.gc, xfg);
@@ -1692,6 +1699,8 @@ xdrawcursor(void) {
/* draw the new one */
if(!(term.c.state CURSOR_HIDE) (xw.state WIN_FOCUSED)) {
sl = utf8size(g.c);
+ if(term.mode MODE_REVERSE)
+ g.mode |= ATTR_REVERSE, g.fg = DefaultCS, g.bg =
DefaultFG;
xdraws(g.c, g, term.c.x, term.c.y, 1, sl);
oldx = term.c.x, oldy = term.c.y;
}
[dev] [dmenu] Patch to only allow choosing and returning one of the given entries
Hi folks,
I keep a file containing a list of gui applications to pipe into dmenu,
so that I could only start those applications that do make sense in the
graphical environment.
However, since vanilla dmenu allows to insert any arbitrary text, this
isn't fool-proof, I could still type dd hit Return and fork a running
program that never stops until I kill it (please don't tell me, that
this is a human problem and should not yield to patch dmenu).
The attached simplechoice patch adds the command line switch '-c', which
causes dmenu to only allow selecting one of the given entries. It does
still work as normal, i.e. typing text results in filtering out the
not-matching entries.
It's also useful in other cases, for example to select a bookmark to
open in surf. So it might be useful to others, which is why I'm mailing
it to the list...
Bert
diff -rup dmenu-4.2.1-orig/dmenu.1 dmenu-4.2.1/dmenu.1
--- dmenu-4.2.1-orig/dmenu.12010-11-20 10:24:33.0 +0100
+++ dmenu-4.2.1/dmenu.1 2011-01-01 16:20:12.0 +0100
@@ -4,6 +4,7 @@ dmenu \- dynamic menu
.SH SYNOPSIS
.B dmenu
.RB [ \-b ]
+.RB [ \-c ]
.RB [ \-i ]
.RB [ \-l
.IR lines ]
@@ -47,6 +48,9 @@ is a program used by dmenu_run to find a
.B \-b
dmenu appears at the bottom of the screen.
.TP
+.B \-c
+dmenu only allows selecting one of the given menu items.
+.TP
.B \-i
dmenu matches menu items case insensitively.
.TP
diff -rup dmenu-4.2.1-orig/dmenu.c dmenu-4.2.1/dmenu.c
--- dmenu-4.2.1-orig/dmenu.c2011-01-01 15:08:49.0 +0100
+++ dmenu-4.2.1/dmenu.c 2011-01-02 13:40:11.0 +0100
@@ -55,6 +55,7 @@ static unsigned long normcol[ColLast];
static unsigned long selcol[ColLast];
static Atom utf8;
static Bool topbar = True;
+static Bool choice = False;
static DC *dc;
static Item *items = NULL;
static Item *matches, *sel;
@@ -76,6 +77,8 @@ main(int argc, char *argv[]) {
}
else if(!strcmp(argv[i], -b))
topbar = False;
+ else if(!strcmp(argv[i], -c))
+ choice = True;
else if(!strcmp(argv[i], -i))
fstrncmp = strncasecmp;
else if(i == argc-1)
@@ -152,12 +155,19 @@ drawmenu(void) {
drawtext(dc, prompt, selcol);
dc-x = dc-w;
}
- dc-w = (lines 0 || !matches) ? mw - dc-x : inputw;
- drawtext(dc, text, normcol);
- if((curpos = textnw(dc, text, cursor) + dc-h/2 - 2) dc-w)
- drawrect(dc, curpos, 2, 1, dc-h - 4, True, FG(dc, normcol));
+ if(!choice) {
+ dc-w = (lines 0 || !matches) ? mw - dc-x : inputw;
+ drawtext(dc, text, normcol);
+ if((curpos = textnw(dc, text, cursor) + dc-h/2 - 2) dc-w)
+ drawrect(dc, curpos, 2, 1, dc-h - 4, True, FG(dc,
normcol));
+ }
if(lines 0) {
+ if(choice) {
+ if(prompt)
+ dc-x += 8;
+ dc-y = -dc-h;
+ }
dc-w = mw - dc-x;
for(item = curr; item != next; item = item-right) {
dc-y += dc-h;
@@ -255,6 +265,8 @@ keypress(XKeyEvent *ev) {
ksym = XK_Return;
break;
case XK_k: /* delete right */
+ if(choice)
+ return;
text[cursor] = '\0';
match();
break;
@@ -268,6 +280,8 @@ keypress(XKeyEvent *ev) {
insert(NULL, 0 - cursor);
break;
case XK_w: /* delete word */
+ if(choice)
+ return;
while(cursor 0 text[nextrune(-1)] == ' ')
insert(NULL, nextrune(-1) - cursor);
while(cursor 0 text[nextrune(-1)] != ' ')
@@ -292,7 +306,7 @@ keypress(XKeyEvent *ev) {
insert(NULL, nextrune(-1) - cursor);
break;
case XK_End:
- if(cursor len) {
+ if(!choice cursor len) {
cursor = len;
break;
}
@@ -306,7 +320,7 @@ keypress(XKeyEvent *ev) {
case XK_Escape:
exit(EXIT_FAILURE);
case XK_Home:
- if(sel == matches) {
+ if(!choice sel == matches) {
cursor = 0;
break;
}
@@ -314,7 +328,7 @@ keypress(XKeyEvent *ev) {
calcoffsets();
break;
case XK_Left:
- if(cursor 0 (!sel || !sel-left || lines 0)) {
+ if(!choice cursor 0 (!sel || !sel-left || lines 0)) {
cursor = nextrune(-1);
break;
}
@@ -340,11
Re: [dev] [dwm] combining 'moveresize' with 'pertag'
On Fri, Oct 22, 2010 at 04:37:31PM +0200, Claudio M. Alessi wrote: I have no idea why the pertag patch moves the Monitor struct after the config.h inclusion but I feel it's wrong. You should move the config.h at the end of all structures definitions in order to ``allow nested code to access above variables''. This way, everything will works properly out of the box. That's all. Because it depends on LENGTH(tags) for some array members, and therefore needs config.h to be included before the Monitor struct definition...
Re: [dev] Initialize layouts
Correct me if I'm wrong, but isn't m-lts[0] for the zero-tag, i.e.
the one which gets activated by pressing Alt-0 and displays all tags?
On Fri, Oct 22, 2010 at 04:52:56PM +0200, Scott wrote:
I have got dwm configured with the push,cycle,resize and pertag
patches, but now I'd like every single tag to have it's own default
layout. I've tried to following, but it doesn't work correct.
/* init layouts */
for(m = mons; m; m = m-next) {
for(i=0; i LENGTH(tags) + 1; i++) {
m-lts[i] = initlayouts[i] initlayouts[i] LENGTH(layouts) ?
layouts$
}
}
But for some reason this doesn't work. I want the second and third tag
(Browser, and Chat) to use layout two by default, but in order to
achieve this I have to configure it as the following:
static const int initlayouts[] = { 0, 0, 2, 2, 0, 0 };
that doesn't really make sense since this is my tag config:
static const char *tags[] = { Dev, Browsing, Chat, Multimedia,
Virtualization, Misc };
config.h: http://pastie.org/private/gszqqcftgbnhd2vij3a9g
dwm.c: http://pastie.org/private/oy4f5hyhnrhqqkv2fq56a #1560
[dev] [dmenu] enhanced filecompletion patch
Hi, After reading this list for quite some time and with the upcoming release of the next stable version of dmenu around, I've decided to share a small but hopefully useful extension. I've expanded the filecompletion patch made by Jeremy Jay (http://lists.suckless.org/dwm/0901/7355.html). I've tried to make it behave like most shells did. The new features are: - complete the longest common prefix after first tab press - cycle through possible completions with subsequent tab presses, shift-tab for reverse direction - automatically add a slash to directory names - file globbing support ([]*?) - escape special shell characters - support for multiple filenames, not just one Here it is: http://www2.informatik.hu-berlin.de/~muennich/dmenu/dmenu-4.1.1-filecompletion-bm.diff Please notice that this patch also slightly changes dmenu_run in order to support multiple files. The old version did not honor escaped spaces. Enjoy or move on, Bert
